Library & Sakai 3 User-Centered Design Proposal

Added by Gaurav Cedric Bhatnagar, last edited by Gaurav Cedric Bhatnagar on Nov 18, 2009  (view change)
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 3.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.

Example

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.

Example

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.

Example

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

Example

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

Example

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.

Example

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.

Example

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

Example

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.

Example

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.

Example

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.

Example

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.

Example

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.

Example

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.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.