Work in Progress

Best Practices

Clear definition of problem being solved

It is important that we understand the problem before defining a solution.  Articulating the problem helps work through what is known about the problem and where there are gaps in knowledge.  The problem definition should be a living document that is revisited and updated often as the problem becomes better understood. 

A problem statement can express the value of a project and define the scope or focus of a project.  An example problem statement might look like this:The problem of... (problem description)

Affects... (the people impacted by this problem)

The impact of which is... (how are the people effected by the problem)

A successful solution would provide... (the benefits of a proposed solution)

Design goals articulated

Design goals help us stay focused on what we've determined to be most important in a project.  They can serve as a quality check by making sure the designs meet  the intended goals.  These are typically at a high level and can be thought of as driving principles for a particular project.  These can be thought of as related to if not the same as the benefits described in the problem statement.  The design goals are likely fuzzy at the beginning of the project. The goals should be revisited and iterated on early and often.

Observe & talk to real users

There is no better way to learn about users goals and needs around a system or activity than observing them in their work.  "Users are perfectly capable of expressing their latent needs.  They just can't do it verbally.  That's why we do ethnography and empathic research." Rich Sheridan, Menlo Innovations.

Driven by user goals

We want to no only understand what users do but also why they do it.  By understanding user goals, we can design for their true needs rather than just replicate what they do now.  We want to understand where it makes sense to leverage technology and not -- how technology can help them in their work.

Designing for personas

Personas .... 

Designing for scenarios

We want to design for real use.  Use cases are great for fleshing out requirements and understanding the extent of activities the system needs to support.  Scenarios help us understand the details of how we can better support users in meeting their goals.   Scenarios -- stories about users activities as they happen in context and relate to other activities -- define the way a user needs to complete an activity or string of activities, what information they already know and need to know, what mental models and expectations they already have in the space and how their context affects the way they get work done (e.g. frequent interruptions tell us the system needs to help users keeps track of where they are in a process).

The ideal is to start with scenarios free of implementation details.  "Context scenarios" focus on the persona mental models, goals and activities.  In "About Face 2.0", Cooper & Reimann, they also refer to these as "Day-in-the-Life Scenarios".  The address questions like (Goodwin, 2002):

• What is the setting in which the product is used?
• Will is be used for extended amounts of time?
• Is the persona frequently interrupted?
• Are there multiple user on a single workstation/device?
• What other products is it used with?
• How much complexity is permissible, based on persona skill and frequency of use?
• What primary activities does the persona need to accomplish to meet their goals?
• What is the expected end result of using the product?

Early and frequent "check-ins" with development

Designers work closely with the development team.  Technical feasibility checks  should be integrated into the iterative design process.  There are trade-offs as getting development involved too early has been known to put technical constraints on innovative design thinking too early.   Being open and talking about these trade-offs are critical.  If technical red flags go off during a feasibility check talking about design intent can be quite productive -- "OK, implementing this design will take 6 months of development time so can we think about how else we can design the system to meet the same intent with less technical implications?"

The entire team should be involved in iterative design reviews to help keep everyone on the same page and get feedback from various team member perspectives.

Early and frequent feedback from larger community

Competitive analysis

Leverage what others have done in a similar problem space.  We all know there are many applications out there that don't work well for users but there are also many good examples of how to support users in  

User testing (usability & accessibility)

Use of design patterns where appropriate and creation of new ones where applicable

CSS

Accessible semantic mark-up

Other?

Other effective design practices

Goal-directed design (yes, OK, my personal bias comes in )

User research

•     Contextual Inquiry
•     Interviews
•     Observation

User and behavioral Modeling

•     Scenarios
•     Use Cases
•     Activity diagrams

Task analysis

Stakeholder "show & tells"

Other?

Resources

• UX Resources from UX Toolkit
• User-Centered Design [pdf] - Allison Bloodworth & Ian Crew
• Selling User Needs Assessment - Allison Bloodworth, Daphne Ogle & Ian Crew
• Berkeley's User-Centered Design Process - Daphne Ogle & Judy Stern