Doing design is not about working hard when you receive a demand, nor is it a process of thinking first and then doing it, and thinking while doing it.

For interaction designers, in addition to focusing on design planning and execution, we should spare some time and energy to think and explore key issues and key links in interaction design, so as to improve ourselves from the cognitive level.

Doing design is not about working hard when you receive a demand, nor is it a process of thinking first and then doing it, and thinking while doing it.

In this process, if some thinking is not comprehensive or in-depth, it may lead to loopholes in the design, which will not only affect the quality of the product, but also be of no benefit to your professional advancement.

In order to polish each design well, I have sorted out some questions to help myself think. Interaction designers can also try to ask themselves in their work. If these questions can be answered, it is not far from an excellent design output.

Eighteen questions, divided into four groups, may not be comprehensive, but they can also run through the design.

1. Demand

1. Why do you need this requirement? What is the background of the requirement?

It is necessary to understand what kind of activity scenarios users encounter problems, and then generate demands. This is the place to fundamentally understand a requirement and finally verify product functionality.

2. Who proposed it, and is it an original demand?

Sometimes the requirements received by the designer at work are second-hand and third-hand requirements. After being transmitted through multiple nodes, the information is easily distorted. If the user cannot be reached directly, it is best to contact the person who raised the first-hand need.

3. Do users have unexpressed needs?

Users sometimes just describe confusion and problems without describing their needs professionally. Even if there is a description, it may only express the superficial problem. A good designer needs to be able to see the real problem through the surface.

2. User Scenarios

1. How do users use this function and what is the process? How do users usually understand it, and what is the specific scenario?

Excavation of this problem is actually very important. When we do product design, we actually help users solve problems that arise during activities in a certain scenario. Being able to clearly know the habits, methods and processes of users using the product, and understanding their understanding of the product (user mental model), can help us target the design very well, instead of designing “how we think users will use it” The product.

2. Who will use this function?

Many products have many large and small functions. If there are 100 users for the entire product, some of the small functions may only be for 10 audiences, and these 10 people may not be exactly the same as other user portraits. Then when designing certain functions, it is necessary to rethink what are the characteristics of the user portraits of these 10 people.

eg: A personnel management system mainly for HR users, some functions of which are also used by the company’s top management, such as viewing the company’s organizational structure. The demands of executives when using it are different from those of general HRBPs. So for this function, we also need to learn more about these executive users.

3. Have you tested it with suitable users, are there any new findings in user research, and what unmet expectations do users have for this function?

If you can’t get in touch with the user who first raised the problem and raised the demand, you can find colleagues/friends who have a high degree of overlap with the target user portrait to help you do informal user research. On the one hand, you can learn more about their problems in use, and on the other hand, you may There will be new discoveries and gains.

4. How often and how important is it?

The frequency and importance of a function or control will affect its position in the product/page, visual prominence, design and development costs, etc.

5. Will it affect other functions in the product?

Some functions do not exist completely independently, and are likely to be related to some other (page) functions in terms of operation and data. When designing this function, you should also consider whether the design will be harmful to it. There are associated features that have an effect on usage.

For example, in WeChat, the user groups contacts A, B, and C into “family members”, and then sends a circle of friends to be visible to the “family members”. So if the user adds D to the “Family” tab after a period of time, can D still see the previous Moments message?

6. How are competing products resolved? If no competing products are found, how are products with similar functions resolved?

Occasionally, when doing design, you will have no ideas, or get stuck in a certain point, or you will always feel dissatisfied after making it. At this time, you can look for excellent competing products. If there is no direct competitor, you can also look for a product with this function for a certain function.

3. Controls

1. Can it be done with existing controls? If new controls are added, is it necessary? Will it be reused elsewhere?

It is very important to manage design resources. The generally formed design specifications and control resources should be reused as much as possible to avoid adding new controls and specifications without restraint, otherwise it will easily affect the development cost and later control maintenance.

2. Have you thought about the various states and the various changes caused by the control during operation, is it smooth and comprehensive?

When drawing, we often only make some key pages for review and discussion. After the review is passed, when we continue to refine, we find that the change status of some controls and the page changes caused have not been considered, and even some functions that have passed the review have been affected. big impact. Therefore, it is recommended that you have your own interactive self-examination table (I am also trying to sort it out, and I will share it after sorting it out), so that you can check whether each situation and change of the control is considered comprehensively, and whether it can run on the page. Makes sense.

For example, designing a list should take into account the display of empty data, data arrangement rules, styles for adding and deleting data, situations that exceed one screen, and so on.

3. Will the added/deleted/modified parts that I take for granted be available in actual scenarios?

When completing a requirement, you may add/delete/modify some existing functions according to your own ideas. It is not impossible, but you should also consider that this kind of spontaneous change by the designer should be placed in the actual scene. Is it really applicable? If it is, that’s great, but if it’s not, it may be a waste of effort.

4. Will it cause misuse, and if so, how to avoid it?

If the size, position, spacing, and color of controls are not designed properly, it may cause user misunderstanding or inconvenient operation, resulting in misoperation, so try to avoid it from the design level.

4. Check

1. After the design is completed

Have you tested it with the right users?

Sometimes the design made by myself is OK, even if it is a very experienced designer, sometimes it is not easy to jump out and find problems after a function has been worked on for a long time. Ask your colleagues/friends to help you take a look after you are done. Maybe the problems and doubts they see at the first sight can give you new inspiration.

2. Is this enough?

We can use conventional methods to solve many needs, and the final solution is likely to be a satisfactory solution. It is not good, but it is not good either. At this time, you can think about whether there is a solution with better experience and more convenient operation, and the advancement of designers sometimes starts from “thinking more” here.

3. Have you tried it out first to see if the actual effect works?

It is not very responsible to directly submit the design draft to the development without verifying it yourself. In fact, software linkage is very convenient now. After finishing a picture on Sketch, you can directly import it into Principle or click to view the effect on your mobile phone. Make sure that the place that can be clicked can be clicked and the effect is correct, and then delivered to the development, which can also avoid later rework. Of course, if it is a very small change or design, it is OK if you are sure that you can make up the running effect.

4. Is the design document written clearly? Are there any minor changes that need to be specially emphasized so as not to be missed by development?

After the design drawing is completed, it is necessary to supplement the interactive documents, which will involve more details, such as interactive logic descriptions and even visual annotations. In addition, if there are some small changes in the original page/function, it is recommended to emphasize it in your own way, so as not to miss it if the development does not notice it.

eg On a certain page that is already online, only a certain title text needs to be modified, and the development may not notice it. I usually add an arrow with a large color contrast and a text description to indicate it.

5. Have you communicated with the developer, and is the development achievable? Did it cost more than expected?

Sometimes because of the different product forms, some effects that we take for granted are not so easy to achieve in the development view. For example, some effects that we are familiar with on APP are not necessarily easy to realize on H5 pages, and sometimes even cannot be realized due to some technical limitations. Therefore, after the design is completed, the development can be reviewed in advance (especially some newly designed and uncommon interaction methods). Of course, it is recommended to think about this question at the end of the design, so as not to set too many limits for yourself in the early stage, which will affect the performance of the design.

In the face of these problems, just like “I reflect on myself three times a day”, I often ask myself and reflect on it. Only by being able to ask questions and solve them can I benefit from it.

However, it takes time to ask these questions one by one, and it is recommended to use them for more complex or tricky requirements. And it is not necessary to go through it all every time, just add or delete as appropriate according to the actual situation.

Leave a Reply