Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 140 Next »

Unknown macro: {composition-setup}

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 Design

Sakai 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 Process

The 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:

  1. Research - through meetings and interviews with stakeholders, auditing existing work and competition in the domain of the product and interviewing and observing users, the design team learns the scope of the project, organizational goals, technical constraints and user needs.
  2. Modeling - by analyzing user interview and observation data, the design team constructs personas and other models to share the details of how target users think, act and behave based on their goals and needs.
  3. Requirements Definition - based on personas and other detailed models of user needs, the design team constructs context scenarios to describe ideal user experiences with an envisioned product. The scenarios go through iterations of being evaluated against user needs, organizational goals and technical constraints, finally arriving at a clear, prioritized list of product capabilities.
  4. Design Framework - by applying principles and patterns of interaction design to the data and functional elements of the product's requirements, the design team creates design sketches and behavior descriptions defining the interaction framework for the product.
  5. Design Refinement - by taking the design framework and continuing to refine it based on scenario walkthroughs with greater focus on detail and implementation, the design team arrives at a detailed design complete with data, functional and visual elements.
  6. Development Support - as the design is handed over to the development team, the design team needs to remain available and involved in answering the development team's questions, dealing with unanticipated issues and adjusting the design and timeline as needed.

Research

1 Scope

Define 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 Audit

Review 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:
  • Citations Helper to search scholarly resources accessible through the library's metasearch engine and build Citation Lists within the Resources tool.
    • Usage statistics?
    • User feedback?
    • How well has Citations Helper achieved its goals?
  • Research Guides authoring prototype to create research guides that can contain multiple content items including citations and Citation Lists (leveraging the Citations Helper).
    • Usage statistics?
    • User feedback?
    • How well has Research Guides achieved its goals?
Other related products on the market
  • Ex Libris Primo is a new product that "provides users with a one-stop solution that streamlines the entire search process from discovery to delivery, enabling users to quickly locate and obtain accurate, high-quality information." (from Ex Libris Primo's overview webpage)
    • What are the strengths and weaknesses of Primo?
    • What is the viability of adoption of Primo at today's academic libraries?
Moodle, Blackboard or other major CLE Library Integration?
Sakai 3 directions

Current 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

  • Why Build Sakai 3?
    • Changing expectations: Google docs/apps, Social Networking, Web 2.0 and the success of project sites means that Sakai is being used beyond courses
    • New technologies: Standards-based, open source projects like JCR (Jackrabbit) and Open Social (Shindig) as well as the rise in client-side programing (JavaScript/AJAX)
  • Benefits:
    • Increased end-user satisfaction
      • Flexibility for site owners
      • Best of class user experience
    • Stability, quality & scalability
      • Smaller code base, shared with other OS projects
      • Transaction-level clustering
    • Fewer local customizations
      • More knowledge of existing use cases
    • Simpler development environment
      • Java and JavaScript
  • Technical Focus Areas:
    • Content Authoring
      • Simple page creation (wiki-like)
      • WYSIWG Editing
      • Template-based authoring
      • Versioning
      • Interactive Widgets that can be placed anywhere on any page
    • Content Tagging and Management
      • Everything is taggable, searchable, linkable, portable content
      • Unified content repository, not tied to sites
    • Academic Networking
      • Social networking designed specifically for the academy
      • Content-based: "Who is reading the same articles?"
      • Activity-based: "Who has taken the same classes?"
    • Breaking the Site Boundary
      • Users, user groups and sites are managed separately
    • Academic Workflows, not (just) Tools
      • Academic workflows often cross tool boundaries
        • Anything can be graded!
        • Anything can be discussed!
      • Example: Instructor puts into syllabus an assignment to create a discussion post that will be graded.
        • 4 tools for both instructors and students!

3 Stakeholder Interviews

Understand 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):

  • Individual product visions - The design team is tasked with harmonizing potentially differing perspectives on the overall product vision to arrive at one, clear product vision that all stakeholders can believe in.
  • Budget and schedule - The design team needs to understand these to be able to judge what can and cannot be accomplished in the event that user research indicates a different scope is required.
  • Technical constraints and opportunities - The design team needs to have a solid understanding of the technology underlying the design to make the best use of it to serve organizational and user needs.
  • Business drivers - The design team needs to understand what is driving the need for the product so that the product serves both the organization and the user.
  • Stakeholders' perception of the user - The design team is tasked with harmonizing stakeholder perceptions of the user and what is found in user research to design a product that meets stakeholder goals as well as user needs.

{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 vision

A 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 Goals

The product needs to:

  • Increase awareness and usage of library services and resources.
  • Leverage existing library services and resources, but also propose new integrations and interfaces that will better serve the end user.
  • Allow users to seamlessly capture relevant content from the web and other scholarly content management systems (i.e. EndNote).
  • Be open, reusable and extensible. Open standards need to be used so that the product is easily reusable and extendible by various institutions.
Technical Constraints and Opportunities

Note 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:

  • Take advantage of the current direction of Sakai 3.
  • Leverage existing library systems, but also propose new integrations and interfaces that will better serve the end user.
Open Questions

How does the product intend to be marketed? Launched? Introduced to first-time users?

4 User Interviews & Observations

Understand 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 context of how the product (or analogous system, if no current product exists) fits into their lives or workflow: when, why, and how the product is or will be used.
  • Domain knowledge from a user perspective: What do users need to know to do their jobs?
  • Current tasks and activities: both those the current product is required to accomplish and those it doesn't support
  • Goals and motivations for using the product
  • Mental model: how users think about their jobs and activities, as well as what expectations users have about the product
  • Problems and frustrations with current products (or an analogous system if no current product exists)

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):

  • Interview where the interaction happens
  • Avoid a fixed set of questions
  • Focus on goals first, tasks second
  • Avoid making the user a designer
  • Avoid discussions of technology
  • Encourage storytelling
  • Ask for a show and tell
  • Avoid leading questions

{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:

  • Time spent online
  • Time spent as faculty/level of faculty
  • Comfort level with placing course materials online
  • Comfort level with technology in general (i.e. willingness to try/learn new systems)
  • Teaching primarily large or small courses
  • Teaching primarily undergraduate or graduate courses
  • Preferred research methods and materials
  • Commitment to teaching motivated by passion or by duty

Four faculty members were interviewed:

User ID

Age

Standing

Department

Time Spent Online (hrs/week)

F01

48

Assistant Professor, total of 2 years as faculty

Linguistics

16-20

F02

70

Professor, total of 42 years as faculty

Psychology

21-25

F03

52

Associate Professor, total of 21 years as faculty

Art History

16-20

F04

42

Assistant Professor, total of 14 years as faculty

Musicology

16-20

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.

  • F01: I'm an intermediate user. I'm comfortable with new learning and research technology, but do not always understand its value for me or enhancing my in-class experience.
  • F02: I'm a late adopter. It takes me a long time to learn new technologies and then they change. Once a user, however, I'm enthusiastic and encourage others to convert.
  • F03: I feel stuck. Students are demanding more online materials, but the more I put up, the fewer students I see in class. Those who do come are on their laptops emailing or on Facebook.
  • F04: I'm a tech enthusiast. CTools is good at lessening my administrative burden, but certain tools do not give me the functionality or usage data I am looking for, so I've commissioned a few of my own online learning tools.

Modeling

5 Personas

Develop 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):

  1. Identify behavioral variables
  2. Map interview subjects to behavioral variables
  3. Identify significant behavior patterns
  4. Synthesize characteristics and relevant goals
  5. Check for redundancy and completeness
  6. Expand description of attributes and behaviors
  7. Designate persona types

{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 variables

After 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:

  • Time spent as faculty
  • Comfort level with placing course materials online
  • Comfort level with technology in general (i.e. willingness to try/learn new systems)
  • Skill level with technology in general
  • Satisfaction level with CTools
  • Level of reliance on help resources (colleagues, in-system support, staffed support, workshops, etc.)
  • Level of interest in automatic recommendations from colleagues
  • Level of interest in automatic student resource usage data
  • Teaching primarily small or large courses
  • Commitment to teaching motivated by duty/requirement or passion
  • Common research methods and materials
2 Map interview subjects to behavioral variables

All 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 patterns

Two main general behavior patterns emerge from the behavioral variable mapping and other data from the interviews:

  • Pattern 1: The younger, more tech-savvy, more comfortable with online teaching material
  • Pattern 2: The older, less tech-savvy, somewhat uncomfortable with online teaching material

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 goals

In 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):

  • own office or at home
  • use almost daily and very heavily at the start and end of the semester
  • online and using in tandem with a number of other Internet services including: Google, Google Images, Google Video, Google Scholar, Library Search Services (journal articles: SearchTools, catalog: Mirlyn, etc), Online scholarly databases, Citation Management Software

Pattern 2 (older faculty member):

  • at own office or at home
  • use occasionally, but heavily at the start and end of the semester
  • online and using in tandem with a number of other Internet services including: Google, Google Images, Google Video, Google Scholar, Library Search Services (journal articles: SearchTools, catalog: Mirlyn, etc), Online scholarly databases, Citation Management Software
  • consulting physical books or journal articles shelved or filed within office for information

Typical Sakai + Library/scholarly content use

Pattern 1 (younger faculty member):

  • Use library's journal article search to locate a reading to put in my syllabus. Search Google Video and Google Images for some videos and images to add to my lectures.

Pattern 2 (older faculty member):

  • Set up e-reserves with the library by completing a physical form. Once notified reserves are set up, the user is provided with a link and places that link in the Resources tool. Students now have a link to all e-reserve material for this course, managed and hosted by the library.

Current solutions and frustrations

Pattern 1 (younger faculty member):

  • Sakai automatically manages who is in my class - nice!
  • Sakai helps in sending messages to my whole class.
  • Sakai helps in uploading and sharing course materials, but getting content from a previous class or uploading a bunch at once can be clunky.
  • I'm not sure whether students are actually using the content I am taking the time to place online.
  • I rarely use in-system help and prefer to go to workshops when I have the time.
  • I need to manually enter citation information I find through the library's journal article search into my syllabus or lecture slides.
  • I'm not sure why I would use tools outside of the basic, standard set because I'm not sure how it will add value to my teaching.
  • I'm not able to easily search the library's great image and slide collection.
  • Using Google, it can take a long time to find images and videos to make my lectures more engaging.
  • It is difficult for me to find library content previously used or recommended by my colleagues studying and teaching the same things as me.

Pattern 2 (older faculty member):

  • Sakai automatically manages who is in my class - nice!
  • Sakai helps in sending messages to my whole class.
  • Sakai helps in uploading and sharing course materials, but getting content from a previous class or uploading a bunch at once can be clunky.
  • I'm not sure whether students are actually using the content I am taking the time to place online.
  • I rarely use in-system help and prefer to go to workshops when I have the time.
  • It takes me a long time to remember where things in Sakai are and how to perform certain tasks (such as adding a new resource in Resources).
  • I'm worried placing more material online will reduce attendance and participation in class.
  • The library's e-reserves system is wonderful because all the readings for my class are online for students to access, it is easy to set up and I can easily pick and choose which articles to include from my previously assigned readings.
  • I know of the really good databases in my area and am adept at using them, but I lack skills in finding or using databases in other areas. I would like to use them sometimes, but am not sure how to approach learning how.

Relevant relationships with others

Pattern 1 (younger faculty member):

  • I know of other faculty members who are probably using the same licensed library content as me.
  • I know of other faculty members who are probably using different Sakai tools from me to engage their students in innovative ways.

Pattern 2 (older faculty member):

  • I have contacts at the library that provide me with specific support.
  • I know of other faculty members who are better able to manage online content and tools.

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...

  • Create an engaging learning experience for my students
  • Have a strong understanding of the best tools available for my research and my teaching
  • Know what learning tools and content my students find useful and what they don't
  • Know what learning tools and content my colleagues find useful and what they don't
  • Limit my time on administrative tasks
  • Find content for my courses quickly
  • Feel little need to ask for help in using systems

Pattern 2 (older faculty member): I want to...

  • Make sure students show up to my classes
  • Be able to understand, learn and use new systems faster
  • Better remember how to do routine system tasks
5 Check for redundancy and completeness

Though 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 behaviors

This 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."


Photo Credit: stock.xchng

  • Assistant Professor of Linguistics at the University of Michigan for 9 years
  • 43 years old

Goals:

  • Create an engaging learning experience for my students
  • Use the best content and tools available for my research and my teaching
  • Find the best content and tools for my courses quickly
  • Limit my time on administrative tasks
  • Feel little need to ask for help while using systems

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!"

  • Professor of Sociology at the University of Michigan
  • Been at UM for 20 years
  • Taught at a few other universities prior to UM for 18 years for a total of 38 years as a professor
  • 69 years old

Goals:

  • Make sure students show up to my classes
  • Understand, learn and use new systems faster
  • Better remember how to do routine system tasks

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 types

Allison McCallum: Primary persona
The primary persona represents the target persona for the design of a specific system, feature or interface. In the case of this project, Allison is the primary persona for the design vision.

Randolph Nicholls: Secondary persona
The secondary persona is mostly satisfied with the primary persona's needs for a specific system, feature or interface, but has a few of their own specific needs. These needs should be designed for without disrupting the experience of the primary persona.

6 Other Models

Mental 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:

  • mental model diagrams of how users think about their work,
  • workflow diagrams that describe how work is actually done,
  • communication models that show all the different people, groups or systems a user needs to interact with, or
  • physical diagrams of the environment within which users work and the physical artifacts they use.

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
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, individual library websites, citations are all separate entities). For example, F04 only knows about the research guide for musicology and related materials because it is part of the School of Music library website. When speaking about cross-disciplinary work, he wonders if other departments have research guides. Indeed, there are a number of research guides available on a variety of topics that are aggregated and findable at the main UM Library website.

Requirements Definition

The Requirements Definition part of the goal-directed design process consists of the following five steps (taken directly from About Face 3.0, p. 116):

  1. Creating problem and vision statements
  2. Brainstorming
  3. Identifying persona expectations
  4. Constructing context scenarios
  5. Identifying requirements

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 Scenarios

Stories 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 Statements

This 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 Brainstorming

This 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 Expectations

This 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):

  • Attitudes, experiences, aspirations and other social, cultural, environmental, and cognitive factors that influence the persona's expectations
    • She's well-traveled: excited by new experiences.
    • She's pressed for time: looking for value quickly.
    • She wants to be well-liked by her students: looking to understand what they want and need.
    • She is at a university that highly values both research and teaching: looking for ways to support and integrate both (officially, UM's split for faculty is 50% teaching, 40% research, 10% admin, according to F04).
    • She is at a top-notch research institution: expecting to have access to world's best scholarly content. Expecting to be judged as a top-notch scholar.
    • She is relatively tech-savvy: expecting a modern interface.
  • General expectations and desires the persona may have about the experience of using the product
    • Expects it to save her time.
    • Expects to have fewer help questions.
    • Expects to explore and learn advanced features faster.
  • Behaviors the persona will expect or desire from the product
    • Expects it to provide her with feedback on resources and services her students use and appreciate.
    • Expects it to help her understand the value of content and tools faster.
    • Expects it to help her search for and find scholarly and course materials, including multimedia, faster.
    • Expects it to help her streamline the process of managing citation data.
  • How the persona thinks about basic elements or units of data
    • The library is one place that contains access to a number of different types of content (books, journal articles, reserves, etc.); a variety of different systems do not necessarily govern these content items.
4 Constructing Context Scenarios

This 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.

  1. It is early August and Allison is setting up the syllabus for a new upper-level undergraduate course, LING 376: Sociolinguistics, that she will be teaching in the Fall. She has taught a similar course before, LING 476, and is basing her Sakai 3 LING 376 site syllabus off of the LING 476 syllabus.
  2. Because the scope of LING 376 is a little bit different from the scope of LING 476, Allison wants to change some of the readings required for LING 376. As she reads down her syllabus, she realizes that one of the papers students are required to read early in the course needs to be less technical. She deletes the existing citation and opens the Library Resources widget to embed library content in her syllabus.
  3. Allison knows just the article she wants to place into her syllabus - she's used it for another class before. She starts typing in a keyword, "Ethiopia," from the full title: "Language in Ethiopia: Implications of a survey for sociolinguistic theory and method". As she types, the contents in the Library Resources narrow down. Allison only needed to type a few characters and the article she was looking for appeared. She notices the rating of this paper is much lower than she expected.
  4. Allison has been away from teaching for most of the summer, focusing instead on catching up with research and finishing a paper that is to be published before school begins. She realizes that students have had a chance to rate the Ethiopia article after it was used in various classes, not just her own, last semester. She investigates and finds ratings, reviews and discussion from students and faculty alike. The general feedback from students is that the article is dated. One of her senior faculty, Professor Arvind Kumar, even joined in on the discussion. He concurred that the article was a little dated and recommended instead another, more recent paper on the same topic called, "The internal classification of the Agaw languages." Allison had read this article some time ago and quickly read the abstract and scanned the article linked to from Professor Kumar's discussion post. She decided that this paper was indeed more relevant to her class and added it to her syllabus.
  5. As Allison added this new paper to her syllabus, she had options for allowing her students to rate the article as well as allowing her students to view and participate in the discussion about the article. Since this was a relatively new paper, Allison was quite interested in what her students thought of it and allowed them to rate and comment on the article.
  6. Allison spent about 15 more minutes updating the syllabus, kept most of the other readings from the LING 476 course, removing some and adding a few more through the Library Resources widget. She ran into a book chapter she had gotten scanned by the library's document delivery service years ago which was no longer available due to copyright restrictions. Before the Sakai 3 Library Resources widget existed, this would be something she would not have easily known about and would have been stuck needing to ask for help when the resource stopped working as expected. Fortunately, the Library Resources widget recommended a new electronic version of the book the UM Library now has access to since the old chapter is no longer available.
  7. Allison also ran into an article she could not find using the Library Resources widget. After entering the title of the linguistics article, she was prompted with options for searching for it at the library through recommended linguistics databases and journals. One of the recommended databases was one she was very familiar with and she found her article of interest there in no time. Because she was now on a website away from Sakai, she knew she could use her 'Import to Sakai 3' bookmarklet to quickly add the new article to her Sakai 3 Library Resources. As Allison went back to editing her syllabus, she saw the newly added article when opening the Library Resources widget.
  8. As Allison went back and forth between editing her syllabus and the Library Resources widget, she noticed library resources that were recently popular in Linguistics highlighted in the Library Resources widget. These were interesting to glance at and Allison knew she would want to come back and explore more deeply when she was working on putting together materials for a course that has never been taught before. For her current LING 376 course, however, she knew just what she wanted.
  9. Allison had an image in mind that she wanted to add to the top of the syllabus. She had no idea where to find the image, but had seen Professor Kumar use it before and knew it would really complement the course description. Allison searched for the image in the Library Resources widget and found it was there as it had indeed been used by Professor Kumar in his LING 425: Language and Society course. She learned the image was from the UM Image Services, Art & Art History collection - an available digital image repository she was previously unaware of. When she added the image into her syllabus, the proper source information was brought along with it.
  10. Allison had just one last item to add to the syllabus: a textbook she found the other day at Amazon, but did not have time to save. She followed a bookmark in a new tab to Amazon. She did the same search she did the other day and perused the results. She located the textbook she was looking for and used an 'Import to Sakai 3' bookmarklet to associate the article with her LING 376 course and add it to her Library Resources in Sakai 3. She tabbed over to the Sakai 3 tab and the new textbook was highlighted in the Library Resources widget because it was just added. She was told that the UM Library had this book physically at the Undergraduate Library and that she could follow a link to put it on reserve. She was also told the book was available through the UM Library as an e-book that could be used by her entire class (which was fewer than 50 students). She knew her students would love this option (the entire book cost $125!) and she added the e-book to her syllabus. Again, as it was a new book, Allison enabled ratings and comments on it and would make brief mid-semester and end-of-semester assignments to encourage students to comment on the book so she could assess its value to them.

8 Requirements

Describe 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:

  • Call (action) a person (object) directly from an appointment (context).

{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:

  • Find library resources used by any Library Resources user (self, colleagues, librarians, students).
  • Find library resources available from the library.
  • View recommended search sources in the event that a library resource is not found in Library Resources.
  • View student and instructor ratings and discussion on library resources.
  • Enable or disable ratings and comments on any library resource.
  • View alternative versions (electronic, physical, etc.) of library resources according to library licensing and copyright restrictions.
  • View popular library resources that are relevant to the Sakai 3 context.
  • Add library resources to Library Resources from anywhere on the web.
  • Define library resources widely: articles, journals, databases, images, video, textbooks, etc.

Design Framework

The 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):

  1. Define form factor, posture, and input methods
  2. Define functional and data elements
  3. Determine functional groups and hierarchy
  4. Sketch the interaction framework
  5. Construct key path scenarios
  6. Check designs with validation scenarios

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 Elements

Define 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:

  • Find library resources used by any Library Resources user (self, colleagues, librarians, students).
    • Find: search box and automatic prioritization and filtering of responses based on context (i.e. in LING classes, LING resources are likely more relevant)
    • library resources: classified/tagged and rated + discussed articles, journals, books, databases, images, videos, research guides
    • users: UM authorized users, classified by their status/role (faculty, librarian, student)
  • Find library resources available from the library.
    • the library: seen as essentially the same as library resources - classified/tagged and rated + discussed articles, journals, books, databases, images, videos, research guides
  • View recommended search sources in the event that a library resource is not found in Library Resources.
    • View: search results space with support for recommended search sources
    • recommended search sources: librarian + faculty + student recommended journals, databases, etc. matching search query. Catalog and 'Ask a Librarian' at the bottom of the list.
  • View student and instructor ratings and discussion on library resources.
    • View: each library resource potentially has an associated rating and review and discussion thread.
    • rating and review: overview rating = average five star rating; detailed ratings broken up by role (student, instructor, librarian); review can be related to a review discussion post
    • discussion: a general thread of messages posted by UM authorized users with comments about the reading
  • Enable or disable ratings and comments on any library resource.
    • Enable or disable: When embedding content from Library Resources into content authoring, option to turn on/off ratings and option to turn on/off comments
  • View alternative versions (electronic, physical, etc.) of library resources according to library licensing and copyright restrictions.
    • View: each library resource record displays alternative versions, if available (automatically checking library licensing/copyright restrictions)
    • alternative versions: iconography/links for available other options leading
  • View popular library resources that are relevant to the Sakai 3 context.
    • View: shared space in "main area" to display relevant library resources
    • library resources that are relevant: automatically filtered, context-specific popular (as rated by students + faculty + librarians) resources
  • Add library resources to Sakai 3 Library Resources from anywhere on the web.
    • Sakai 3 Import to Library Resources bookmarklet - automatically reads citation information from the web page and presents an authenticated dialog box to add content to Sakai 3 Library Resources. Standard tagging, classification and comments options are available.

10 Framework

Define 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 & Validation

Describe 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 Refinement

12 Detailed Design

Refine 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 Support

13 Design Modification

Accommodate 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:

  • scope is broad and makes a lot of assumptions about tech: what is realistic in the near future?
  • do faculty mind sharing library resources?
  • what do faculty think about ratings and reviews on their learning materials (very averse, always on, under their control, etc.)?
  • haven't considered the Citations Helper survey data - may help in understanding more about the process for searching library resources.
  • what is faculty use of 'other' web services (i.e. Amazon, Facebook, etc)?

How to Get Involved

There 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 schedule

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.

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 behavior

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.

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 archetypes

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.

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.

Others

There 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.

  • No labels