‑ User-Centered Design

Too often, systems are designed with a focus on business goals, fancy features, and the technological capabilities of hardware or software tools. The UX designers get told to design something.

Just designing something typically leads to unintuitive interfaces with astronomical implementation costs and low adoption. If we are “doing UX” it is required to be in continuous contact with the actual users we are designing for. There are only a few cases when it is okay to design something without knowing about the users’ needs and behaviors first. Yours is most likely not one of them. The design should be a balance between business goals, user needs and technological capability.

The user’s needs in focus

If you could do only 2 things in your product design process, you should do user research and prototyping. This is what user-centered design is all about. If you could do only 1, do user research! Prototyping is for visualizing the product before it is being built, because it is way easier to understand how something will work if you can try it out, with or without users, preferably with.

The ISO 13407 - Human centred design processes for interactive systems is a framework to use for achieving quality in use of a product through user interaction. The framework is based on iterative design with lots of user input and thus one can perform different activities for each iteration to solve the current design problem in that iteration.

The ISO standard lists 6 key principles to ensure that a design is user-centered.

  • The best design is based upon an explicit understanding of users, tasks and environments.
  • Users are involved throughout design and development.
  • The design is driven and refined by user-centered evaluation.
  • The process is iterative.
  • The design addresses the whole user experience.
  • The design team includes multidisciplinary skills and perspectives.

Saying that the process is iterative means that the whole cycle (green in the picture below) as well as the parts of it (yellow) are done in a repetitive pattern, going back to review, correct and build on what was done before. The process can be explained in four stages.

User-centered design

Context

This phase equals the empathy stage in design thinking. The first method to use here could be an observation of the users using a current system. This would give you an understanding of what the users are doing. Then, a set of contextual interviews to understand why something is done and the users situation as a whole could be a good idea. To get a broader base to work from, you could send out a survey to a larger group to measure the needs. On the result of that, you might want to iterate the contextual interviews to pose even more specific questions.

Hence, we’ve done this step in four iterations, to really understand the context of use. Of course, this phase could overlap the other three if needed.

Requirements

In this phase we define what the need is that we want to create a solution for. This phase would take business goals and technical feasibility into consideration, perhaps through stakeholder interviews, workshops and specifying the usability goals.

Solutions

This phase matches both the ideate and prototype stages of design thinking. This is where you do interaction design, a way of working that is in itself very iterative, going back and forth through different design ideas. This can be done through the design studio methodology or simply by building wireframes and prototypes in a tool.

Validation

This phase is the test stage of design thinking. We do validation and verification. We validate that the user needs are met in our solutions by doing usability tests of different kinds, both on prototypes at different stages of the design process and on actual implementation. In the verification part, we focus on evaluation of early prototypes in order to define the requirements for the system as well as evaluation of the system to check that business requirements have been met. Of course we also test to improve the current design.

Low and high fidelity

A normal approach to user-centered design through prototypes is to do the first cycle with sketches or simple (and ugly) prototypes. This is not actually to save time, in truth sketches can take longer time to produce than a Photoshop mockup. It is done to present to the users as something that is not really done. The low fidelity of the sketches will make it easier for the users to give feedback on the interaction design, on the user flow in the product. Higher fidelity will make them focus on the details.

The second cycle could be a more formal presentation (without graphical design), that can tell you more about the location and sizes of texts and buttons. The third cycle could be the actual implementation or a pixel-perfect Photoshop mockup, to understand if the users would respond positively to the style.

More cycles can be done. You might want to iterate the low fidelity cycle several times to really get a good interaction design, since this is more important to the overall user experience than the colors of the interface.

The bottom line

I do not advocate always doing these phases after one another, like a waterfall. But if you are not doing anything structured today, this is where you should start. When this process is mastered, doing it more efficient and effective is preferable.