cloak.memory.duration = 7
cloak.toggle.type = text
cloak.toggle.open = Show
cloak.toggle.close = Hide
Under Construction
This page served as a design process proposal towards the beginning of the Library & Sakai 3 Integration project. It needs to be updated to reflect recent changes. To see current developments, please see the process section of the Library & Sakai 3 integration project home page.
This document summarizes and demonstrates a user-centered design process for Library and Sakai 3 integration and how institutions can get involved in the process. The kinds of deliverables and results that can be expected from the use of this process are demonstrated through examples of preliminary user-centered design work completed.
A note on examples
Each design phase has a " Show Example " link that describes preliminary design work done by an interaction designer at the University of Michigan. The examples are of preliminary, exploratory work to help demonstrate the design process, describe how institutions can get involved and to generate design material (organizational goals, personas, context scenarios, mockups, etc.) for discussing the scope of a longer-term design effort.
Contents | The Need for User-Centered DesignSakai 3 is not an incremental improvement over Sakai 2 - it is a fundamental shift to better suit the needs and expectations of today's web users. To take full advantage of the new tools and technologies available within Sakai 3, institutional libraries must take a step back and understand the goals and needs of campus communities in finding, using and sharing licensed scholarly material. With an increasingly complex and ever-changing information landscape, user expectations and behaviors change quickly. Users are left using systems that do not successfully support and engage them in achieving their goals at work, school or home. With an increased understanding of user goals, behaviors, aptitudes and attitudes as the foundation for the design of software comes a more productive and enjoyable experience for users along with reduced support calls, reduced training time and reduced errors. In comparison to Sakai 2, Sakai 3 will be based on entirely different, next generation technologies. Library users, from faculty to undergrads, are surrounded by easy to use, effective technologies such as Google and Wikipedia that allow them to find what they are looking for amongst immensely large volumes of information. Recommendations from friends, colleagues and e-communities allow them to further filter the deluge of information to get what they need. As Sakai 3 rises to meet the challenges of these evolving expectations and behaviors, the Library has an opportunity to take advantage of this Web 2.0 environment to better engage the campus community with licensed scholarly resources. Because technologies and behaviors are shifting, it will be important for us as designers to develop a strong understanding of library users and their goals (as opposed to just tasks and workflows) to design truly effective and enjoyable software. Users are currently accustomed to Sakai 2 and existing library services that may lack Web 2.0 functionality. With Sakai 3 on the way and the abundance of Web 2.0 tools out there, how do we decide what best serves our users' needs? Regardless of how users get their work done, their goals change slowly. A student's goals likely relate to mastering their interests, being perceived as a good student and getting a good job as opposed to using cutting-edge learning technologies. Today, they may use Google and Wikipedia to start research projects. Fifty years ago, they may have headed to the library, perused the card catalog and browsed for hours. In both situations, their overarching goals were likely the same. Though this is changing, much of the current design work for Sakai is in the form of use cases and usage scenarios. These are a great starting point for designing software that users can use and enjoy, but a great deal of contextual information about why users would want to use particular features and what specific needs these use cases are serving are missing. When these questions are not answered up-front in the design phase, they may get answered down the road by developers and managers who may not be well-equipped to answer on behalf of the end user and are under enormous time and resource constraints because development has already begun. Alternatively, these questions may never get answered and users are presented with tools whose value are not clear to them and provide them with frustrating experiences. At the core of the following design process is a rich understanding of user goals, behaviors, aptitudes and attitudes. These are visualized and shared in the form of personas and context scenarios. Personas and context scenarios elucidate users, their goals and needs as well as provide a way for designers, developers, managers and partners to discuss, evaluate and prioritize design ideas and requirements by focusing on users instead of technology. The Design ProcessThe proposed design process outlined here is based on Alan Cooper's About Face 4.0: The Essentials of Interaction Design. The overarching purpose of this process is to design interactive products that satisfy user needs by addressing their goals, behaviors, attitudes and aptitudes. Although the focus of the process is on users, interaction designers also need to consider organizational goals driving the development of the product and technical constraints governing what is feasible. Because the focus of user research in this design process is user goals instead of just tasks and workflows, the process is also called goal-directed design. The design process is completely separate from development and happens at the start of a project, before development begins. The process is broken up into six major parts:
Research1 ScopeDefine project goals and schedule Get Involved! Join in on the Sakai 3 and Library Integration Web Meetings to share your (and hear others') goals, needs and ideas for integrating library services and resources with Sakai 3. Learn about more ways to get involved. In this phase, stakeholders make decisions about the overarching goals for the project as well as the time and resources available to achieve these goals. Stakeholders also decide on an overall design and development process to use and set milestones accordingly. {toggle-cloak:id=Scope Example} Example Unknown macro: {cloak}
Based on discussion with the organizers of the project, the goal of this project is to follow a user-centered design process to develop and share a vision of what is possible in the realm of integrating library services and resources with Sakai 3. We have one half-time interaction designer and a little bit more than two weeks. Results need to be presented at the Sakai 3 + Library Web Meeting on 23 June 2009. We will follow the About Face 3.0 interaction design process and have time for about five user interviews to be completed by 12 June. The remainder of the time will be spent analyzing interviews, modeling personas and context scenarios, defining requirements, sketching out a design, evaluating the design against personas and context scenarios and documenting the entire process to be shared with those interested in library & Sakai 3 integration. 2 AuditReview existing work and products In this phase, the design team surveys the area or market the product will enter. Examining any currently existing versions of the product as well as competitors or highly related products provides the design team with an appreciation for the state of the art, strengths and weaknesses of existing products and ideas for what to ask stakeholders and users during interviews. The design team uses methods including comparative evaluation and heuristic evaluation to compare products. {toggle-cloak:id=Audit Example} Example Unknown macro: {cloak}
Given the short timeframe on this project and the focus on user interviews, the Audit phase did not consist of formal comparisons, but did focus on identifying existing similar work, related products on the market and the directions of Sakai 3. There are also some open questions included here for further exploration in a larger design process. Existing library integration with Sakai includes:
Other related products on the market
Moodle, Blackboard or other major CLE Library Integration?Sakai 3 directionsCurrent Sakai 3 interaction design wireframes with functionality, look and feel can be found at the [3akai Wireframe Screenshots page]. All of the below material is either borrowed or adapted from a webinar presentation by Michael Korcuska on participating in Sakai 3
3 Stakeholder InterviewsUnderstand product vision and constraints In this phase, the design team focuses on understanding organizational goals and technical constraints to arrive at a clear product vision that all product stakeholders believe in. Though the focus of the design team is understanding and satisfying users, a product cannot be developed without understanding the organization's purpose in designing the product in the first place and being realistic about what is technically feasible within the given timeframe. The design team interviews stakeholders (those with authority and/or responsibility for the product being designed) to gather the following type of information (adapted from About Face 3.0, p. 53):
{toggle-cloak:id=Stakeholder Example} Example Unknown macro: {cloak}
Given the short timeframe for this project, stakeholder interviews were not able to be scheduled. Based on talks with Sakaibrary project co-leads and reviewing notes from previous Sakai 3 + Library Web Meetings decisions were made to focus first on a user-centered design around faculty. Open questions are included here for further exploration in a larger design process. Product visionA visual representation (sketch, wireframe or mock-up) of a Sakai 3 Library product that serves the needs of faculty and provides the Sakaibrary group and partners a starting point for brainstorming and discussing a longer-term design effort. Organizational GoalsThe product needs to:
Technical Constraints and OpportunitiesNote on technical constraints: given the short timeframe for this project, early phase of the longer-term design effort and the fundamental shift in technology taking place (both in Sakai 3 and library systems), technical constraints will not be given strong consideration with a focus instead on a product vision based on user needs. The product needs to:
Open QuestionsHow does the product intend to be marketed? Launched? Introduced to first-time users?
4 User Interviews & ObservationsUnderstand user goals, needs and behavior Get Involved! There are a vast number of different users that both the library and Sakai serve. Help build a deeper understanding of these various users by conducting user interviews and observations on your campus. More details. A deep understanding of the users of a product is at the core of the design effort. The focus is to learn the goals, needs, behaviors, aptitudes and attitudes of the user so the end product serves to get the user's work done while allowing them to feel truly supported by the product (as opposed to feeling forced to use it or feeling they have to work against it). This learning also lends itself to significantly improve marketing the product, introducing it to first-time users and crafting help documentation. Because these interviews are in-depth and encompass a great deal about the user, their background and their context, they are often referred to as ethnographic interviews. The design team should select interviewees carefully, making sure to get a diverse sample that represents the target market for the product. The design team can make these decisions by identifying behavioral, demographic, domain expertise, technical expertise and environmental variables that cover the range of different people that may use the product. In the context of social website development, for example, there may be users whose behavior may range from very private, wanting to share minimal personal details or fabricating them, to very public, ready to share everything about themselves. These variables are the basis of developing personas and there may be more that are discovered when actually interviewing users. The design team interviews users and potential users to learn (taken directly from About Face 3.0, p. 56):
The design team should use the following basic methods of ethnographic interviewing to get the best qualitative data possible (taken directly from About Face 3.0, p. 65):
{toggle-cloak:id=User Example} Example Unknown macro: {cloak}
Given the preliminary nature of this project before the scope of the longer-term design effort has been established, interviews were planned to be exploratory in nature to uncover common themes and trends in faculty goals, behaviors and needs as well as design opportunities. The focus of each interview was to learn why and how faculty currently find, use and share scholarly resources for teaching, learning or research. To select a range of interviewees that would be as representative as possible, we solicited faculty that were at a training session on both library and CTools (UM's local Sakai instance) services. This ensured that the faculty we spoke with had at least some familiarity with digital library services as well as Sakai. The following behavioral and demographic variables were also considered in choosing interviewees and to gather information on during interviews:
Four faculty members were interviewed:
Each interview was 30 to 60 minutes long. There was one interaction designer running the interview and taking notes on a laptop. Ideally, two interaction designers should conduct interviews - one to run the interview and one to take detailed notes. After each interview, the interaction designer went through the notes cleaning them up by making them more readable (to be able to share with others) and adding in details that could not be captured earlier. This process also gave the designer a chance to reflect on the interview and identify emerging themes and new behavioral variables. To help the designer remember the overall impression of the individual interview, short summary statements were developed describing those characteristics of the user that were particularly salient.
Modeling
5 PersonasDevelop detailed user archetypes Get Involved! If you are able to conduct user interviews and observations on your campus, you have the data you need to build personas or inform personas being developed at other institutions. More details. In this phase, the design team takes what they have learned about users through interviews and observation and develops, "detailed, composite user archetypes that represent distinct groupings of behaviors, attitudes, aptitudes, goals and motivations" (About Face 3.0, p. 21). These personas serve as a way for designers, developers, managers and other stakeholders to imagine the end user as a real person whom they are trying to serve. Personas, therefore, must be based on direct research and carefully crafted to properly represent the range of goals and behaviors that target users have. Personas should be prioritized so that they can serve as a tool to prioritize design ideas and requirements. The design team use the following steps to construct personas (taken directly from About Face 3.0, p. 97-98):
{toggle-cloak:id=Personas Example} Example Unknown macro: {cloak}
This section documents following the above seven steps in constructing personas for this project. We arrived at two personas which you can jump to directly. 1 Identify behavioral variablesAfter interviewing, some of the initial behavioral variables we came up with before interviewing did not seem to apply while new ones were discovered. For example, 'Time spent online,' did not seem to apply because all faculty were spending a lot of time online. New behavioral variables were added in relation to technical aptitude and interest in recommendations from other colleagues and usage data from students. The updated behavioral variables are as follows:
2 Map interview subjects to behavioral variablesAll but one behavioral variable could be represented using a continuum that we could place each user along. The image below is the outcome of this activity (click to open full-size image in a new window). 3 Identify significant behavior patternsTwo main general behavior patterns emerge from the behavioral variable mapping and other data from the interviews:
Findings Following is a detailed summary of what was found when analyzing the interview data and behavioral variable mapping. Data that provides a basis for the 'Comfort level with technology in general' variable comes primarily from interviewees' description of the different systems they use, how often they use them, how quickly they are able to learn new technologies and their overall satisfaction or frustration with these systems. It takes the older behavior pattern much longer to trust and learn new technologies, and, by the time they learn them and feel comfortable, the introduction of an upgraded system with new rules to learn can be frustrating. This distrust or misunderstanding of new technologies may relate back to the overarching needs expressed by all interviewees: to limit their time on administrative tasks and focus on research and teaching. In general, all interviewees are relatively satisfied with CTools primarily because it reduces their administrative burden in communicating with their students, managing student records and sharing resources with students. The less interviewees can quickly and clearly see the value of a new product in streamlining their work (either presented in marketing material or, more importantly, when they use the product for the first time) the more hesitant they are to invest time in learning how to use the product. This point is true across all interviewees: though F02 and F03 are older and require significant time in learning new technologies, F03 comments on not using many CTools tools because she just does not know how they will improve her teaching or in-class experience and F04 has gone so far as to develop his own online learning tools completely separate from CTools because CTools tools did not meet his needs. Another important finding in regards to comfort in placing materials online and satisfaction with CTools relates to an overarching goal of all interviewees and potentially all faculty. As teachers, interviewees want students to show up to their classes, be engaged and leave with a deeper understanding and appreciation for their subject matter as well as tools and skills to independently study and further the state of the art. Interviewees are at a university that places high value on teaching and work within a system where feedback on their teaching impacts their career through raises, standing along the tenure-track and their perceived effectiveness as faculty. By placing more course materials online, faculty run the risk of seeing fewer students in class, as F03 has experienced first hand and, as a result, refuses to post her lecture slides online. The proliferation of laptops in class (which coincide with student demand for more online material) provide opposing opportunities for students to engage more actively in class (through detailed, organized and searchable notes, for example), or disengage more actively in class (through Facebook, chatting, or games, for example). F02 finds distraction more common in the larger, undergraduate required courses where students are there because they have to be rather than on their own accord. As an energetic and enthusiastic lecturer, he claims these courses are "boring" to teach. Both F01 and F04 have an interest in making their lectures more engaging by including more images and videos. Unfortunately, it can take a very long time to find good ones and they may only consume three minutes of class. When running into problems with CTools or library systems, interviewees have a differing level of reliance on help resources. All interviewees attended a workshop on the new library reserves system and how to manage their new electronic reserves through CTools, so they are all somewhat comfortable with asking for help. Within the system, however, attitudes differ. F01 claims that because there are workshops, she should not ask questions when she has them. Because it is difficult to make it to all the workshops, she ends up not asking for help often and routinely does not experiment with features she does not understand, instead doing things manually. F02 claims he, "just fiddles around some more on [his] own," because technical help documentation is so tough to read. F04 is similar to both F01 and F02 in that he experiments on his own, but drops his exploration after a certain amount of time and does not ask for help often within the system. F03 relies on help a lot in the form of her own detailed notes on how she learned how to perform certain tasks. All interviewees expressed the need for some automated feedback on what online learning materials students were actually using. F03 has made announcements about un-required articles that may be of interest of students. F02 has used the News tool to embed news sources from across the web in his CTools sites. These faculty, who are not generally tech-savvy, went out on a limb to try something new with CTools and had very little idea whether their effort was worthwhile. They mentioned asking about these special resources in class, but the response was not reliable. Both F01 and F04 expressed the same need in more general terms. If they were able to quickly see what students were using and what they were not, they could cut down time in deciding where to focus course improvements while increasing the relevance of their courses for students. Similar to having usage statistics on student behavior, F01, F02 and F04 expressed interest in the collective wisdom of their colleagues at varying levels for different purposes to help them navigate digital learning tools and scholarly content. F01 is interested in making her lectures more engaging and knows there are a number of CTools tools available to her. She has no problem understanding them technically, but is not sure what she can do with them to make class more engaging and wonders how other faculty are using them in their courses. Both F02 and F04 are involved in cross-disciplinary work. They know the top databases and resources and how to navigate them for their own areas of expertise, but lack this expertise in other domains. When confronted with doing research in other domains or adding lecture content from other domains, both F02 and F04 look to colleagues in other departments for hints. For example, F04 teaches a musicology class on Jazz, but knows there are English Literature or African American Studies courses that are also discussing Jazz from a totally different, but very informative perspective that can add value to his Jazz class. F04 also mentions the difficulty new faculty have in navigating the vast amount of services and resources the UM Library has to offer and how veteran or retired faculty can cite their most used or recommended resources to alleviate this disconnect. Interviewee motivations for teaching reveal interesting ways in which CTools and digital scholarly resources are perceived. F02 states that he enjoys lecturing because he is excited about the subject matter and he wants to share that interest with others. F03 mentions junior faculty that did not make tenure because they were very passionate about teaching and making "fancy PowerPoints". They were highly regarded faculty, but lost time on what F03 believes is their main focus on scholarship and publishing. Those interviewees that are more on the passion side of the teaching motivation spectrum tend to look at CTools and digital resources and wonder how they can best use them to better represent their subject matter and better engage students in appreciating subject matter. Those interviewees that are more on the duty side of the teaching motivation spectrum tend to look at CTools and digital resources and wonder how they can best use them to save time and carry on with their research. This spectrum can be somewhat misleading, however, because the two sides are not mutually exclusive. A faculty member can both have a passion for teaching as well as a sense of duty about being a strong teacher and researcher. A better focus for follow-up interviews may be to better understand if faculty spend more time on research versus teaching and why. Finally, common research methods and materials for interviewees were discovered. All interviewees rely on the library's e-reserves service to have readings from books to journal articles available for students online. What was interesting to observe was the range of different ways interviewees found materials and how they thought about the library. Both F01 and F02 primarily use journal articles and described finding them "through the library." F01 actually starts at the library's catalog, Mirlyn (Ex Libris Aleph), and follows a link over to the metasearch engine, SearchTools (Ex Libris MetaLib), without noticing that she jumped between two completely separate systems. She even refers to what she uses as Mirlyn Power Search, even though 'Power Search' is a SearchTools feature, not a Mirlyn feature. F02 has bookmarked a number of the major psychology databases, such as PsychINFO. Although his bookmark to PsychINFO takes him directly to the PsychINFO native homepage through the UM Library proxy, he describes the journal as at the library. Because he found the link to the database at the library website and has some knowledge about the licenses the library has to allow him to search there, the database seems a part of the library. F03 and F04 have similar mental models about the library as a one-stop-shop for all things related to scholarly materials. Unfortunately, the library is not structured in this way and is rather a conglomeration of a number of different shops (i.e. catalog, articles and databases, e-journals, research guides, citations are all separate entities). There is a mental model diagram of this discrepancy in the Other Models phase Example. F04 finds Google (and YouTube) to be the best place to go to find the multimedia-rich content he is looking for. He knows, however, that once copyright starts impinging on his use of these "free" services, the library will be the place he turns to for finding this kind of material, hopefully just as quickly as he finds it through Google. 4 Synthesize characteristics and relevant goalsIn this step, we try to distill what we have learned about the behavioral patterns into a list of characteristics in the areas of: potential use environment, typical product use, current solutions and frustrations and relevant relationships with others. To top it off, we consider what we have learned about the goals of each behavioral pattern. Potential use environment Pattern 1 (younger faculty member):
Pattern 2 (older faculty member):
Typical Sakai + Library/scholarly content use Pattern 1 (younger faculty member):
Pattern 2 (older faculty member):
Current solutions and frustrations Pattern 1 (younger faculty member):
Pattern 2 (older faculty member):
Relevant relationships with others Pattern 1 (younger faculty member):
Pattern 2 (older faculty member):
Goals With these goals, we are trying to shift overlapping goals to Pattern 1 (the primary persona). Pattern 1 (younger faculty member): I want to...
Pattern 2 (older faculty member): I want to...
5 Check for redundancy and completenessThough there is some overlapping between pattern 1 and pattern 2, these two personae vary on a number of significant behaviors.
6 Expand description of attributes and behaviorsThis is where our personas come to life. Below we have created two personas for each of our behavioral patterns. Pattern 1 has been transformed into Allison McCallum. Pattern 2 has been transformed into Randolph Nicholls.
Allison McCallum"I want to make my courses more engaging for my students and want do it faster than I currently can."
Goals:
Allison is an Ann Arbor local who studied at the University of Michigan and has made her way around the world studying aboriginal languages. She's been teaching at UM for almost a decade now and is always trying to find new ways of taking advantage of the various and always-changing research and teaching tools available to her. Keeping up with technology while balancing students' increasing demands for online material and her own research goals has proven challenging. Allison is relatively tech-savvy, not usually having trouble with information systems she uses, though she does have a feeling there are a lot of features she does not take advantage of. She has trouble with seeing the value in the many tools that are now available to her. She knows that other professors are using the CTools Poll tool, for example, but has no idea why or how it would make for a better learning experience. Allison also wonders whether the content and tools she is already using are really effective. She added a new journal article to her course this semester and has a feeling that not many students appreciated it. She thought it was great not only because of the content but because it was easily accessible online through the UM Library. Asking students in class whether they found it useful, she did not get much useful feedback. Allison does know that good images and videos really engage students and get learning across very well. She often finds herself spending hours on Google searching for an image or video for a lecture. She knows the UM Library has some great image collections, but she is not sure how or where to find or search them. She would love it if there were a way to find good multimedia content faster. Overall, Allison appreciates UM's CTools environment because it really cuts down her administrative burden. She likes the UM Library's services because she's able to create her own custom database sets and search them easily. Because she's not much of an explorer when it comes to technology, she feels there may be some advanced features she doesn't know how to use and ends up doing a lot of manual copying and pasting when dealing with citations she finds through UM's journal article search and needs to use in her syllabus or lecture slides. Randolph Nicholls"Technology must and will continue to change. Just don't forget to make it easy for us to transition to new systems!"
Goals:
Randolph has gone to school on the west coast, on the east coast and has been a professor in the midwest for two decades. A self-proclaimed late adopter, Randolph is not up to date on the latest technological trends. It takes him a fair amount of time to understand how a new technology will add value to his work and significant effort to learn new interfaces. After eventually picking up a new technology and learning how to use it, he is enthusiastic about it and encourages others to join in. Many times, once he's comfortable with a system, a new one comes along which forces him to go through the process of unlearning and relearning all over again. Randolph also struggles with the perceived drop in student attendance and engagement in class with an increase in placing materials online. He could place attendance rules on his students, but feels as though this treats them like children. Randolph really enjoys teaching and wants to make sure his students take away something valuable from class and that's difficult to do if they don't show up! 7 Designate persona typesAllison McCallum: Primary persona Randolph Nicholls: Secondary persona
6 Other ModelsMental models, workflows, communication, environment In this phase, the design team takes what they have learned about users through interviews and observation and develops models besides personas that will help elucidate other important factors within the domain of the design. These models can include:
Which models end up being useful depend on the context of the product, the domain, what data is necessary and available and which concepts are most important to share with the design and development teams. {toggle-cloak:id=Models Example} Example Unknown macro: {cloak}
Interviewees tend to think about the library as the place where they get all their library stuff - books, articles, reserves, etc. Although there is some understanding of these systems being separate, the way that users talk about and actually use library resources and services suggests blurry distinctions between services. As a result, certain library resources and services can go unnoticed, are not easily understood or are seen as overly complex and frustrating. Evidence Requirements DefinitionThe Requirements Definition part of the goal-directed design process consists of the following five steps (taken directly from About Face 3.0, p. 116):
Though these steps are presented chronologically, they are iterative in nature. When trying to articulate requirements, there may be new light shed on the problem and vision statements, persona expectations or context scenarios. This should prompt the design team to revisit those steps of the process that are affected. 7 Context ScenariosStories about ideal user experiences In this phase, the design team creates a problem and vision statement for the product, brainstorms any preexisting notions regarding design ideas, identifies persona expectations and constructs context scenarios. Context scenarios are high-level narratives of how the product can best address the needs of personas. Through persona-based narratives of ideal user experiences, the design team can imagine a new and greatly improved experience for end users. Because context scenarios are stories about real users (personas), they can be used to share, discuss and prioritize requirements amongst designers, developers, managers and other stakeholders with a focus on user needs. {toggle-cloak:id=Scenarios Example} Example Unknown macro: {cloak}
1 Problem and Vision StatementsThis is where the design team revisits organizational goals for the project and concisely formulates the problem facing the organization and the purpose for the new product. Problem Statement Library resources and services are being underutilized and perceived as difficult to use because faculty do not have adequate tools to find, search, manage and share licensed scholarly content within the context of their courses and research projects that would help them meet their goal of being successful and effective scholars and teachers. Vision Statement The new design for Sakai 3 and library integration will help faculty achieve their goal of being successful and effective scholars and teachers by giving them the ability to find, search, manage and share licensed scholarly content within the context of their courses and research projects with greater ease and efficiency. This will improve the perception of using library resources and services and increase overall utilization. 2 BrainstormingThis is where the design team tries to let go of any preconceived notions about what the end product should be like, based on the significant time spent in stakeholder, technical and user research. It is a chance to get as many wacky ideas out there and filed away for until later in the process. Given the exploratory nature and short timeframe of this project, this part was skipped as there were not too many specific design ideas brewing. 3 Identifying Persona ExpectationsThis is where the design team considers the personas' mental models and makes sure that the envisioned interfaces for the product match them. Given the short timeframe for this project, we are considering only the primary persona (the following parameters taken directly from About Face 3.0, p.118):
4 Constructing Context ScenariosThis is where design begins. As the design team constructs context scenarios, they describe a detailed, high-level story focusing on how the product can best help the personas achieve their goals. The following context scenario is for Allison McCallum, Assistant Professor of Sociology at UM, whose goals are to create an engaging learning experience for her students, find and use the best content and tools available for her teaching and research and feel little need to ask for help while using Sakai.
8 RequirementsDescribe necessary capabilities of product In this phase, the design team analyzes the context scenario(s) to extract the personas' needs or requirements. Requirements can be thought of as consisting of objects, actions and contexts and are not identical to features or tasks. For example, in the domain of designing smartphone software, a requirement may be:
{toggle-cloak:id=Requirements Example} Example Unknown macro: {cloak}
Based on analysis of the above [context scenario example], following are the requirements for the product:
Design FrameworkThe Design Framework defines the overall structure of the user experience. It includes how functional elements are laid out on screen, interactive behaviors, underlying organization principles, visual vocabulary as well as brand identity. Defining the interaction framework happens with the following six steps (taken directly from About Face 3.0, p. 127):
Though these steps are presented in sequence, the middle few steps (3-5) may be swapped and there will surely be a back-and-forth once validation begins. 9 ElementsDefine manifestations of information & functionality In this phase, the design team takes the requirements and breaks them down into the functional and data elements that represent functionality and data in the user interface. Requirements were defined from the user's perspective whereas functional and data elements are described in terms of user interface representations. {toggle-cloak:id=Elements Example} Example Unknown macro: {cloak}
Below is a listing of the functional and data elements necessary for our requirements:
10 FrameworkDefine overall structure of the user experience In this phase, the design team creates a visual representation of the overall user experience based on interaction design principles and patterns. This process starts with sketches of high-level framework elements and progresses to representations with increasing detail and fidelity after iterations of running through walkthroughs (key path scenarios) and validation scenarios. {toggle-cloak:id=Framework Example} Example Unknown macro: {cloak}
Coming soon ... 11 Walkthroughs & ValidationDescribe how personas interact with the product In this phase, the design team tests the design framework by putting themselves in the shoes of the personas and walking through scenarios, evaluating how well the existing design framework supports user needs. Based on iterations of these walkthroughs and validation scenarios, the design framework becomes more and more concrete. {toggle-cloak:id=Walkthroughs Example} Example Unknown macro: {cloak}
Coming soon... Design Refinement12 Detailed DesignRefine and specify details In this phase, the design team translates the design framework into its final, concrete form. This involves continued use of interaction design principles and patterns as well as consulting with the development team to ensure the final form of the design is something they can use and build while meeting design requirements. {toggle-cloak:id=Design Example} Example Unknown macro: {cloak}
Coming soon... Development Support13 Design ModificationAccommodate new constraints and timeline In this phase, the design team supports the development team after handing off the detailed design. Developers will need help in understanding the design in different contexts and unexpected constraints or new discoveries can create a need for designers to step in and work with developers to modify the design while continuing to support design requirements. {toggle-cloak:id=Modification Example} Example Unknown macro: {cloak}
Questions raised by the design:
How to Get InvolvedThere are a number of specific phases of the design that we need your help on listed below. In general, ways you can contact us with questions, concerns, feedback or interests in getting involved are:
Scope: Define project goals and scheduleJoin in on the Sakai 3 and Library Integration Web Meetings to share your (and hear others') goals, needs and ideas for integrating library services and resources with Sakai 3. The more institutions that participate, the wider set of needs we will be able to understand, prioritize and include in design work. If you are unable to make it to the Web Meetings, please feel free to comment on this page, email us with your needs and ideas or participate on the discussions started on the sakai-ux and sakai-user email lists. User Interviews and Observations: Understand user goals, needs and behaviorThere are a vast number of different users that both the library and Sakai serve. Help build a deeper understanding of these various users by conducting user interviews and observations on your campus. The goals and process for user interviews and observations we are currently following are those described in the User Interviews & Observations section of this document, based on Alan Cooper's About Face 3.0. Ideally, you will be able to provide the time of an interaction designer (or two - for stronger notes!) to discuss details of the process, identify interviewees, schedule interviews, conduct interviews, process notes and then share notes back with the community. When sharing notes, personally identifiable information about interviewees is absolutely not necessary. The interaction design time needed depends on how many interviewees are selected and scheduled and the interaction designer's experience with user interviews and observations. If you cannot support all these activities, but have an interest in conducting interviews on your campus, we can work with you to determine a way for you to participate while getting the important user data that informs the core of the design effort. Because this work involves direct interviews and observations of human subjects, there may be Institutional Review Board (IRB) policies that need to be considered. In most cases we have found so far, because interviews are entirely voluntary, are strictly confidential (identifiable details are not shared with anyone outside the design team or institution), are all with persons 18 or above and there are no plans to publish the results, user interviews and observations can be conducted without IRB approval, but you may want to check with your own institution's IRB office to confirm this. Personas: Develop detailed user archetypesIf you are able to conduct user interviews and observations on your campus, you have the data you need to build personas or inform personas being developed at other institutions. The goals and process for persona development we are currently following are those described in the Personas section of this document, based on Alan Cooper's About Face 3.0. Ideally, you will be able to provide the time of an interaction designer (or two - for stronger personas!) to discuss details of the process, analyze interview data and follow the process to construct personas. The interaction design time needed depends on how much interview data there is, how many personas are to be developed and the interaction designer's experience with constructing personas. If you cannot support all these activities, but have an interest in constructing personas from your interview data, we can work with you to determine a way for you to participate while building the important user archetypes that inform the core of the design effort. OthersThere are many opportunities besides those listed above for you to get involved. Depending on your resources, skills and interests, you may also be able to participate in building context scenarios, defining and prioritizing requirements, developing a design framework through paper prototyping, wireframes or mockups or evaluating the design with persona walkthroughs. Feel free to contact us in any way listed above. |