User Oriented Product Design

Original author: Gov.uk
  • Transfer


Note perev .: As part of our blog on Habré, we decided to start publishing a series of translations of materials prepared by the creators of the British Gov UK portal. The Gov UK team is famous for describing the entire course of its work in great detail - therefore, its materials can be useful from a practical point of view (of course, not only for creating large-scale government services), because everything that the creators of the project write about has been put into practice. We decided to start a series of translations with a block devoted to flexible design methodologies, and its important part - the creation of the so-called user-centered design.

Examine your users at every stage of project development. Do this continuously during each stage - user research - not what happens only at the beginning and at the end of any stage of the work.

If you research your audience continuously, this will allow you to:

  • Concentrate primarily on the needs of the user;
  • Help the team design exactly those products that best meet the needs of the user;
  • Help the team develop products iteratively, taking into account user feedback.

Designers and researchers are equally important


Each team should include a designer and a “researcher” who work together and are actively interested in designing and searching for custom insights. It is not about the researcher to “test” the work of the designer - this means that they must work together and thereby:

  • share all the knowledge received from users so that any decision made regarding the product is based on the conclusions drawn from the results of a study of real users;
  • the researcher’s efforts to provide the team with a large amount of information and user reviews collected on a regular basis - this will help the team work iteratively, prioritize tasks at each iteration and create the highest quality product;
  • continuously conduct experiments that can show whether the selected design principles provide an understandable and attractive product for users.

Make sure that your team has a person responsible for research who is constantly in contact with the team. This person can be engaged in other tasks (work as a designer, copywriter, etc.), but should be responsible for conducting activities within the framework of user research every 2 weeks.

Conducting research during iterative design work


Do not work on product design without receiving feedback from end users for more than 2 weeks. Each two-week iteration will include three stages:

  • development of
  • assessment
  • learning and gaining new knowledge [about users]



1. Development


Use open source frameworks [the creators of the Gov UK portal for the needs of teams working on projects of a similar type, recommend their own GDS repository ], because:

  • So you can quickly prototype design concepts;
  • A working prototype will allow you to get more insights from users compared to the paper version.

Keep in mind that you will design and develop many prototypes for testing, and most of them will go to waste. This gives the team the freedom to explore several different concepts at once and get a better understanding of what will be optimal for the end user. Allow enough time for such experiments, especially in the early stages of the project.

[Note perev .: we decided to find out how difficult it is to create a team culture within which employees will adequately perceive the need to create many prototypes, the vast majority of which will not go to the final work, from professionals who have faced similar tasks in practice.]

Comments egorushkin ( Sergey Egorushkin, Internet entrepreneur):
I liked the phrase once: "The employee must be able to smile before you hire him." I think this is from the same series. Breaking the attitude is not a thankful job; I always preferred to hire “my own” people in spirit.

Comments Hryusha ( Platon Dneprovsky , UIDG Director ):
The question is - because of what a large number of prototypes are created that have not gone to work. If this is due to constant changes in the requirements or the desire of the customer (external or internal) to “play around with fonts” - this will certainly reduce motivation.

If all these prototypes are a consistent movement towards improving the system (created, discussed / tested, finalized), on the contrary, everyone will see the result of this movement, and it will only be more interesting.

People are not idiots, and quickly enough they realize the meaninglessness of work. General advice - everyone should understand why this or that work is being done. If it is meaningful and leads to improvements - then everything is OK.

At these stages of the project’s existence, the prototypes are likely to look incomplete, and their design will require further refinement. Follow the rules to test prototypes every 2 weeks instead of trying to bring design to completion or create an externally “finished” product.

Try to ensure that work on each prototype is completed at least one day before the start of testing, as this:

  • Allows you to allocate time for minor modifications and improvements;
  • Reduces the risk of technical failures during the study.

2. Evaluation


There are many ways to do “experiments” to help you answer questions about your product, its design, and end users. Your researcher will help you choose the best methods to answer each of these questions. With it, you are likely to come to use a large number of different techniques as part of the project.

But, whatever your project, remember to test it on end users every two weeks.

[Note perev .: such tests are especially important, inter alia, because often according to their results the team comes to conflicting, at first glance, conclusions. For example, a seemingly prettier, more interesting (according to the team) design turned out to be less attractive to users in practice.]

Comments Hryusha (Platon Dneprovsky , Head of UIDG ):
Very often this happens. I even formulated the idea for myself that I consider the team / designer to be truly professional if he is ready to create interfaces that he personally does not like, but are effective for Central Asia. Otherwise, all this is taste. Another thing is that your own taste and experience can help in a quick search or evaluation of solutions.

Accordingly, the answer: we always choose a more efficient / working option, and not the prettiest one.

Comments egorushkin ( Sergey Egorushkin , Internet entrepreneur):
With a nice new design, many have already received a drop in sales. The first factor is unusual, it takes time to adapt. The second - the resource already has a whole theory and, in short, the design should fall into the user's emotional background. Dramatically and radically changing a design for the better is just as bad as dramatically and drastically worsening it.

It’s just that Russians in their attitude to design and usability are somewhat less emotional than, for example, Europeans, therefore in Russia they sell well “medium” websites in design.

2.1 Testing with user involvement once every two weeks

[in the terminology of Gov UK developers “Testing Tuesday” - “Tuesday tests”]

As part of these sessions, you will be able to:

  • Attract people to interact with the interface you are working on (usability testing);
  • Investigate all the specific issues for which you would like to receive information using more detailed interviews (a personal interview that can give a deep understanding of the needs and behavior of the user).

Conduct “research” sessions involving users every 2 weeks on the same day. By conducting such testing at predetermined dates, at regular time intervals, you will provide your team with the opportunity to free up time in advance to observe the session.

[Note transl .: we decided to ask whether similar practices are used in smaller projects, and how they vary depending on the volume / type of tasks.]

Comments Hryusha ( Platon Dneprovsky , UIDG Director ):
So far, we (as an external agency) do not always accompany the product during its life cycle, or at least its noticeable part. More often this is work on one release. In this case, we test 1-2 times: either before release, or before and then after some time (if you need skills from users).

In those projects where we live with the service for a long time, the frequency of the test should be determined by the frequency of changes. Why stupidly test the same thing? But if the project is large, then different scenarios are tested, and here the frequency depends on the capabilities and plans, at least every day. But rather, these are precisely the planned 2-4-week activities for which you are preparing the necessary functions and plans for testing them.

Try to plan about 5 personal interviews for this day, each lasting 1 hour (attract another “backup” user to the event in case someone is late or does not meet the requirements for a potential test participant).

Conduct sessions either:

  • In your own office;
  • In a research laboratory (if necessary, it can be removed).

Start resolving issues of booking a room and attracting test participants at the initial stages of a project’s life, taking into account the large number of such sessions as part of creating an alpha and beta version of the product.

Before the session

To prepare for the session, you need to:

  • Identify research questions: what do you plan to learn from the results of the testing round?
  • Generate hypotheses regarding your design, for example: changing the text on the button will encourage people to read certain material more carefully.
  • Determine what will testify to the confirmation / refutation of the hypothesis, for example: you think that the hypothesis is true, since the time to read the material has increased.
  • Highlight the characteristics of users with whom you want to test according to the following parameters: age, location, compliance with the task, other factors.
  • Begin the selection of candidates at least a week before the test (the GDS - Government Digital Service - secretariat of the UK Cabinet of Ministers recommends searching for candidates through specialized recruiting agencies).
  • Prepare an interview guide that describes how communication with a potential user should be conducted and what results should be obtained during the conversation.
  • Prepare an agreement allowing you to record a session.
  • Send out the daily routine to all team members and urge them to attend the sessions.
  • Provide streaming video from the testing venue in real time through such services as, for example, GoToMeeting, so that those team members who cannot personally attend the session can observe the process.

Before the sessions, prepare the prototypes and make sure that:

  • They can be shown to users;
  • They are fully prepared for testing;
  • They can be accessed and can be used from the room in which the study is conducted (the necessary settings for access restriction systems are set, the screen resolution of the computer allows you to work with the prototype, compatible browsers are used for work).

During the session

During the course of each testing session involving the user:

  • Make sure the session is recorded on video.
  • Make sure that the video from the session is available in real time for external observers (team members).
  • Keep in mind the hypotheses being investigated so as not to miss important topics when communicating with the user.
  • Use sticky-edge post-it leaflets to capture observations during a session:
    • For this, it is best to use yellow leaves that hold well on vertical surfaces;
    • Record each observation on a separate sheet;
    • Write with a marker in capital letters (it will be easier to read notes made in a hurry later);
    • If you are not sure how important the observation is, write it down anyway.
  • Prepare a written transcript of the session (either during or after the session).

After a day of testing, you need to set aside time for analysis before making decisions on changing the prototype. The analysis step is described in detail below.

2.2 Partisan research

You can use the time between two formal testing sessions to conduct partisan tests and receive feedback on the improved design options directly from potential users.

Partisan testing, as a rule, is as follows: you take your prototype to a coffee shop or other public place and are looking for volunteers who can give you quick feedback. Partisan testing does not always allow you to engage your target audience, but it can provide you with a quick review in between more formal prototype testing sessions.

2.3 Other research methods

There are many other methods that you can use to supplement your qualitative research in an interview format, and which will help to find the answer to a number of specific questions or to confirm / refute the conclusions made on the basis of the main tests for a wider audience. A list of such techniques, as well as guidance on how and when to best apply them, is here .

3. Getting new knowledge


Now it's time to find out what you can learn from the results of testing with the involvement of users and subsequent research. It is best to use the accumulated information to help you:

  • Data analysis;
  • Exchange of analysis results;
  • Communication.

3.1 Data Analysis

It is important to correctly instruct the team on the actions that will be taken after testing, because during the research process you will observe a lot of people and their sometimes completely different reactions to your prototype.

Although a detailed analysis of the sessions takes a lot of time, having completed it, you:

  • Get a clear idea of ​​what you have learned;
  • Find out what conclusions you need to make regarding the current prototype;
  • You will be sure that important observations have not been lost.

Sorting by affinity

To conduct it correctly, you need:

  • Collect all notes made on self-adhesive sheets during prototype testing sessions and stick them on the wall.
  • Group observations by topic.
  • To conclude: to determine a certain statement that combines all the observations of one group, and write it on a separate piece of paper above the group.
  • Try to relate the findings to hypotheses and decide if you have enough information to make a statement about the truth / falsehood of the hypothesis.
  • Further, the hypothesis must be subjected to subsequent quantitative / qualitative testing.

At this step, you aim to create a complete list of insights (these can be the results of observations directly and conclusions on them), so do not immediately try to design solutions. The analysis process should take several hours.

Work with any member of the team who observed the prototype testing process with the involvement of users to analyze the observations, as this will help you:

  • Identify all general principles for observation;
  • Find confirmation of what the team observed during the tests;
  • Form a consensus on the findings.



Actions

Decide what you will do about each conclusion you get (and whether at all). And when you find confirmation / refutation of the hypothesis, make sure that it is documented in the video, and the team is aware of it.

If the findings require further action, determine what is required to turn them into the next iteration of product design. Write these actions on orange self-adhesive leaflets and attach them to the wall next to the pins.

Prioritization

When you have decided what actions to take, use the prioritization method (such as cumulative voting , for example ) to decide how you will distribute the effort in the next iteration.

3.2 Exchange of analysis results

Put information about the conclusions drawn from the test results and the actions that need to be taken where the project team will be able to access this information, since it is likely that you will return to the received data in order to:

  • Remember what ideas you came up with;
  • Track how a specific topic or option develops during the iterative design of the prototype.

You can document the results of your research so that others can access them in various ways, in particular, you can:

  • Create a document with the right of collective access to it;
  • Start blogging
  • Create so-called story wall (using services like Trello );
  • Catalog your research.

It is also useful to keep records of exactly what was tested with the involvement of users: for example, if you created not a paper but a “working” prototype, save a separate folder in the repository for each iteration. Saving screenshots of the prototype may also be useful.

GDS experts want to create a special format for sharing research findings between government projects. While GDS does its best to create such a format, keep your findings in an accessible form for information exchange, so that you can share and study them in the future. Whenever possible, conclusions should be expressed as clearly as possible so that their interpretation does not require additional interpretation.

Enter information about all the actions in the story wall, so that the whole team sees who is working on what.

Video

Use video to demonstrate research findings and keep videos from sessions safe - ideally where team members can find and view them. If you use a public service (such as Vimeo) to store video, make sure that your recordings are well protected.

3.3 Communication

You need to discuss the project and the progress of working on it with others. This can be done with:

  • Demonstrations of the project / presentation of regular updates;
  • Continuous publication of project design updates;
  • Retrospection.

Project demonstration A

group of designers and user researchers should do exactly the same as the developers themselves, that is, present changes to the project based on the results of each iteration. This will make sure that the whole team has an understanding that:

  • Research and design design does not stand still;
  • Based on the results of the study, conclusions were drawn that should be familiarized with;
  • Based on the results of the study, actions are being taken to change the design of the project.

In the framework of such presentations, team members get the opportunity to learn all the important points that they could have missed without getting into the prototype testing session, and can also ask questions. Depending on how the team works, you can embed your presentation in a general report or present the results of your work separately.

Consider the interests of more distant stakeholders.

In addition to your direct project team, there may be other people interested in the results of your work. To start active communication and / or work with them, you can:

  • Smooth them over to showcase your project;
  • Share on them part of the documents;
  • Publish project information to a blog;
  • На регулярной основе рассылать информацию обобновлениях проекта по почте, используя скриншоты прототипа для демонстрации того, что именно тестировалось в рамках исследовательских сессий.

Publish the latest design information for your prototype.

Make sure your team always has access to the latest version of the prototype, but at the same time provide it with adequate protection. Team members may need to check something or use a prototype to discuss the project with their own stakeholders in the project results.

Retrospection
It is important to reflect project progress regularly. Allocate time for a retrospective assessment of the project, in which the team that is working on user research and design will be able to openly discuss the process and make suggestions for changing it. Designate those responsible for tasks and action lines so that the suggestions made are implemented.

Also popular now: