The last line of defense! Five steps to improve UI interaction acceptance efficiency

Details determine success or failure. This time, I would like to talk to you about the last link in project development, which is also a link that tests your ability to pay attention to details, namely "design acceptance".

Background: In order to quickly cater to market development, the company's strategic level decided to build a middle-end version. The project has now completed test acceptance 1.0 and entered the design acceptance phase. After experiencing the tested product, it was found that there were certain differences between the page restoration and the design draft, and there were also some problems in the interaction.

The acceptance work at this time exists to solve these problems and is the last line of defense for product launch.

event:

• During the acceptance process, we found some problems in the product acceptance workflow, so we proactively made a systematic acceptance framework proposal, which was successfully proposed and is now being used within the team.

Purpose:

• In order to use agile methods to collaborate and meet business needs, to form standardized workflows within the team, and to better use design to add value to the business...

Generally, project acceptance is divided into three parts: project requirement acceptance, UI interaction acceptance, and pre-product release acceptance, which are intervened at different time points.

Here I will discuss with you the following five details about UI interaction acceptance.

Writing format

During the acceptance process, our team used the DingTalk online form (Knowledge Base - Product Acceptance Issue Record Form) for collaboration, which was maintained by the design department and responded to by the development department.

The collaborative mode is that the design team experiences the product in the beta version, and then compares it with the UI draft, interaction draft, and PRD document, finds problems from them, and writes them in a table. The core of writing is the problem description and illustrations. Development and testing will check the problems, so let's first briefly describe the things to pay attention to when writing:

1. Format consistency

When multiple people are involved in the collaboration, the design team's external output should maintain consistency. Therefore, during acceptance, the writing format of the content of the same module should be kept consistent to facilitate relevant personnel to view and understand the content.

The recommended writing format is based on the navigation system: primary navigation -> secondary navigation -> main menu -> specific module

For example: Department comprehensive analysis -> Department homepage -> Overview -> Cost composition analysis

2. Clustering, integration and unified presentation

In the previous step, we described the problem modules uniformly according to the navigation. Here, the problems of the same module should be clustered together to make the table look unified and show the integrity of the table.

Since acceptance involves multiple roles (product, interaction, design...), it is recommended that you write the problems under the same module together when describing the problems, so as to reduce the repetition of the same content, reduce the complexity of the table, and make it easier for development and testing to check the problems.

In the end, you can clearly see the proportion of problematic modules and even assign responsibilities to relevant personnel.

You can get this design acceptance form template at the beginning of the article.

Screenshot Annotation

Simply describing the problem in words requires a certain amount of understanding. Attaching pictures can show the problem more intuitively. Here are a few tips for reference when marking the problem in screenshots:

1. Full page screenshot

Problem: B-end product pages have a high degree of repetition. If you only take a partial screenshot, in most cases the content in the screenshot will be present in many modules, making it difficult to tell which module it belongs to. You need to check the text to confirm.

Benefits: It is convenient for developers to use the navigation system to locate the page.

2. Mark the problem and modification suggestions on the diagram

Benefits: Developers can clearly see the problem and modification suggestions when viewing the screenshots, and it is also convenient to save the images and discuss the problem with other people. (Source of the problem: On a low-resolution computer, opening the thumbnail in the Excel spreadsheet will cover the table content.)

3. If there are multiple problems, mark them with serial numbers

When there are multiple issues on a page that need to be marked, it is important to keep them organized.

4. For complex issues, please attach the corresponding UI draft/interaction draft/PRD document screenshots

Reduce developer operations (repeated operations of finding files and pages) and improve the efficiency of fixing bugs.

!!!Upgraded version of acceptance annotation screenshot skills

5. Annotate screenshots with code

When checking a page, even designers with pixel-perfect eyes 👀 can hardly tell exactly where the error is simply by visually checking the page.

Here we need to check the page against the code, so we can take a screenshot of the code, find the place to be modified in the code, and attach an explanatory text on the side, and then attach such a screenshot to the acceptance document, which can save a lot of time for development and show that we are so professional.

By the way, I would like to share with you a useful MAC screenshot annotation software "xnip". It can not only take screenshots, but also has many screenshot function keys, and it also has step annotation tools, supports scrolling screenshots, and can set shortcut keys... In short, it is very useful and I recommend it to everyone.

Download link: https://xnipapp.com/

Problem Description

With the previous basic operations, how should we describe the problem during acceptance? Here we need to think from the perspective of others, changing from the design perspective to the development perspective, and thinking from their perspective. What kind of problem description can help developers get the desired information through effective description.

1. Don’t just describe what went wrong, describe how to fix it

This means that you must write the modification suggestions in detail to help developers save time in repeatedly checking manuscripts and calculating parameters, which in turn helps you reduce the cost of secondary acceptance.

Copywriting tips: Use the spacing reduction of 4px instead of vague copywriting such as height 20px, refer to interactive draft, etc.

Complete acceptance

Without a systematic acceptance framework, we basically see what is there, which will lead to omissions, missing, duplication and other problems during acceptance. Therefore, it is very important to have a design acceptance checklist. Only by checking against the checklist can we avoid omissions as much as possible and ensure the integrity of the acceptance.

Here I have compiled a design acceptance checklist based on the project. This checklist can help you accept the product more comprehensively. At the same time, its content should be continuously optimized, revised and improved according to the iteration of the project to make it cover more comprehensively and better enable the business.

Review and acceptance

The acceptance review work is a summary of a product update and also a way to prevent repeated errors in the future.

When the product acceptance work is 90% or completed, the problems have reached a certain level. At this time, the problems should be classified and sorted out to find out the basic component problems and general interaction specification problems. These two categories should be picked out separately, sorted out, and one-on-one docking and adjustment should be carried out with the corresponding person in charge. Modifications should be made strictly in accordance with the component library and interaction standards to achieve 100% restoration and solve basic problems at the source. In this way, when such components/interactions are used in other projects in the future, such problems will not occur again.

In this way, a complete acceptance work can be completed perfectly.

Conclusion

With this systematic acceptance process, we can better collaborate with upstream and downstream during the acceptance process. Of course, the corresponding person who raises the issue must also be held accountable to the end. After the issue is raised, always pay attention to the feedback status of the developer. If there are any problems, actively communicate and give specific solutions to specific problems until the problems are solved to ensure the smooth launch of the product.

The above is my personal proposal for the product acceptance stage. I hope it can improve the efficiency of the team's work and empower the business. At the same time, I hope everyone can provide valuable suggestions.