User-Designed Product Design

Note translation: 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 state portal Gov UK. The Gov UK team is famous for describing the entire course of its work in great detail - so its materials can be useful from a practical point of view (of course, not only for creating large-scale state services), because everything that the project creators write about has been implemented in practice. We decided to start a series of translations from the block dedicated 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 explore your audience continuously, it will allow you to:

• Focus primarily on the needs of the user;
• To help the team design exactly those products that best meet the user's needs;
• Helping the team develop products iteratively, taking into account user feedback.

Designers and researchers are equally important.

Each team must include a designer and a “researcher”, working together and actively interested in designing and searching for user insights. The point is not that the researcher "tested" the designer's work - this means that they must work together and thus:

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

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

Conducting research during the 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
• assessment
• learning and getting 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 program prototypes of 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 junk. This gives the team the freedom to explore several different concepts at once and get a better understanding of what is best for the end user. Allocate enough time for such experiments, especially in the early stages of the project.

[Approx. 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: “An employee should be able to smile before you hire him.” I think this is from the same series. Breaking an attitude is not a rewarding business, I have always preferred to hire "my" people in the spirit.

Hryusha ( Platon Dneprovsky , head of UIDG ) comments on :

Here 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 customer’s desire (external or internal) to play with fonts, this will certainly reduce motivation.

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

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

At these stages of the project's existence, prototypes are likely to look unfinished, and their design will require further refinement. Adhere to the rule to test prototypes every 2 weeks instead of trying to complete the design work or create an externally “finished” product.

Try to complete the work on each prototype at least one day before the start of testing, as this:

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

2. Evaluation

There are many ways to conduct "experiments" that will 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 will probably come to use a large number of different techniques as part of the project.

But whatever your project, do not forget to test it on end users every two weeks.

[Approx. Perev .: Such tests are especially important, among other things, because the team often leads to contradictory, at first glance, conclusions. For example, it would seem that a more attractive, interesting (according to the team) design turned out to be less attractive to users in practice.]

Hryusha ( Platon Dneprovsky , head of UIDG ) comments on :

Very often this happens. I even formulated for myself the idea that I consider the team / designer to be truly professional if he is ready to create interfaces that he personally doesn’t like, but are effective for Central Asia. Otherwise, all this is taste. Another thing is that your own taste and experience can help in quickly finding or evaluating solutions.

Accordingly, the answer is: always choose the most efficient / working option, and not the cutest 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. Secondly, the resource already has a whole theory and, in short, the design should fall into the user's emotional background. Drastically and radically changing a design for the better is as bad as drastically and drastically deteriorating it.

It’s just that Russians, in their attitude to design and usability, are somewhat less emotional than, for example, Europeans, which is why Russian sites sell well on average.

2.1 Testing with users every two weeks

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

During these sessions you will be able to:

• Attract people to interact with the interface you are working on (usability testing);
• Explore all the specific questions that you would like to receive information on using more detailed interviews (a personal interview that can provide 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 pre-allocate time to observe the session.

[Approx. translation: we decided to ask whether such practices are used in smaller projects and how they change depending on the size / type of tasks.]

Hryusha ( Platon Dneprovsky , head of UIDG ) comments on :

While we (as an external agency) do not always accompany the product during its life cycle, or at least its significant part. More often it is work on one release. In this case, we test it 1-2 times: either before release, or before and then after some time (if skills from users are needed).

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 possibilities and plans, at least every day. But rather, these are exactly the planned 2-4-week activities for which you are preparing the necessary functions and plans for testing them.

Try to schedule on this day about 5 personal interviews, each lasting 1 hour (attract another “spare” user to the event in case someone is late or will not meet the requirements of the potential participant in the test).

Hold sessions either:

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

Start solving questions on booking the room and attracting participants to the testing at the initial stages of the project life taking into account the large number of similar sessions as part of the creation of the alpha and beta versions 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 test round?
• Formulate hypotheses about your design, for example: changing the text on a button will encourage people to read more carefully certain material.
• To determine what will testify to the confirmation / refutation of the hypothesis, for example: you think that the hypothesis is correct, since the time spent on reading the material has increased.
• Select the characteristics of users with the assistance of whom you want to test for the following parameters: age, location, compliance with the task, and other factors.
• Begin selection of candidates at least one week before testing (the GDS division of Government Digital Service - the UK Cabinet Office recommends searching for candidates through specialized recruitment agencies).
• Prepare an interview guide that describes how to communicate with a potential user and what results should be obtained during the interview.
• Prepare an agreement allowing you to record a session.
• Distribute the daily routine to all team members and urge them to attend the sessions.
• Provide real-time video streaming from the test location through services such as GoToMeeting, so that those team members who cannot attend the session in person can monitor the progress of the process.

Prepare prototypes before the sessions and make sure that:

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

During the session

In the process of conducting each test session with the involvement of the user:

• Make sure the session is recorded on video.
• Make sure that video from the session is available in real time for external observers (team members).
• Constantly remember the hypotheses under study, so as not to miss important topics when communicating with the user.
• Use post-it leaves with a sticky edge to capture observations during the session:
  
  • It is best to use yellow leaves that stick well on vertical surfaces;
  • Fix each observation on a separate sheet;
  • Write with a marker in capital letters (it will be easier then to read the entries made in a hurry);
  • If you are not sure how important observation is, write it down anyway.
• Prepare a written transcript of the session (or during the session, or after it).

After a day of testing, it is necessary to allocate time for analysis before making decisions on changing the prototype. The analysis step is detailed below.

2.2 Guerrilla research

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

Guerrilla testing usually consists of the following: you take your prototype to a coffee shop or other public place and are looking for volunteers who can give you a quick review. Guerrilla testing does not always allow you to use your target audience, but it can provide you with a quick review in the breaks 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 that will help you find answers to a number of specific questions or confirm / refute conclusions made on the basis of core tests for a wider audience. A list of such techniques, as well as instructions on how and when they are best used, 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 will help you:

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

3.1 Data Analysis

It is important to properly instruct the team regarding 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 sessions takes a lot of time, having implemented it, you:

• Get a clear picture of what you have learned;
• Learn what conclusions need to be made regarding the current prototype;
• You will be assured that important observations have not been lost.

Affinity sorting

To hold it correctly, you need:

• Collect all notes taken 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 out on a separate piece of paper above the group.
• Try to connect the conclusions with the hypotheses and decide whether you have enough information to make a statement about the truth / falsity of the hypothesis.
• Further, the hypothesis must be subjected to subsequent quantitative / qualitative testing.

At this step, you are aiming to create a complete list of insights (these can be the results of direct observations and conclusions on them), so don’t try to start designing solutions right away. The analysis process should take several hours.

Work with any team member who watched the prototype testing process with user engagement to analyze the observations, as this will help you:

• Identify all general principles for observation;
• Find confirmation that the team watched during the tests;
• To form a consensus on the findings.

Actions

Decide what you will do about each output (and whether there will be any). And when you find a 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 out these actions on the orange self-adhesive leaflets and attach to the wall next to the leads.

Prioritization

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

3.2 Exchange of analysis results

Place information about the findings of the test results and the actions to be taken where the project team will be able to access this information, since it is likely that you will return to the data obtained so that:

• Remember which ideas you came up with;
• See how a particular topic or option develops during the iterative prototype design.

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 a so-called. story wall (using services like Trello );
• Catalog your research.

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

GDS experts want to create a special format for sharing research findings between government projects. While the GDS is doing everything possible to create such a format, keep your findings in an accessible form for sharing information, so that they can be shared and studied in the future. Whenever possible, the conclusions should be expressed as clearly as possible so that their understanding does not require additional interpretation.

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

Video

Use videos to show research findings and keep video recordings of sessions safe — ideally, where they can be found and watched by team members. If you use a public service (like Vimeo) to store videos, make sure that your recordings are well protected.

3.3 Communication

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

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

Demonstration of the project

The group of designers and researchers of users should act in the same way as, directly, the developers, that is, to present the changes on 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;
• According to the results of the study, conclusions were drawn that must be reviewed;
• According to the results of the study, actions are taken to change the design of the project.

As part of such presentations, team members will have the opportunity to learn all the important points that they might have missed without getting to the prototype testing session, and may 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 interests and more distant stakeholders

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

• Inviting them to demonstrate your project;
• Share on them part of the documents;
• Publish project information to the blog;
• Regularly send information about updates to the project by mail, using screenshots of the prototype to show what was tested during the research sessions.

Publish the latest design information for your prototype.

Make sure that 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 results of the project.

Retrospection
It is important to reflect project progress regularly. Allocate time for a retrospective evaluation of the project, within which the team, in which the work on user research and design is conducted, will be able to openly discuss the process and make suggestions for changing it. Assign those responsible for the tasks and the action lines to make the suggestions made.