Reduce project communication costs and risks: Write interactive design documentation

Article Description: How to write an interactive documentation.

It's been a while since we left the circle of interactivity. But because the blog is still, or can occasionally receive some mail, last week, a classmate asked me: I am looking for a job, I see many recruitment instructions on the need for interactive designer interface design documents, what is the interface design document document? How to write it?

It makes me think of it. In 2009, I also vigorously implemented interactive documentation in my project (in the next article, abbreviated as DRD), the format is not limited, the interaction designer himself to write to the interface is also OK, a separate document is also the line, in short, so that interactive designers can not load the interface information through the document precipitation down, Reduce communication costs and risks in the project. Today to clean up the computer, to turn out the previous ppt, share.

This will involve several issues:

What is an interactive description document (DRD)?

The so-called DRD is used to host interactive instructions and deliver them to the front-end, testing, and documentation that the development engineers refer to.

In the project, the main output of the interaction designer may be: Site Map,page flow,wireframes. In the early stages of some large-scale projects, interaction designers may also produce user requirements analysis documents (unlike the market requirements for PD outputs, URD more focused on the needs analysis of target users).

DRD is rarely written by anyone. If you need to explain the interaction design, smart interaction designers will often be directly labeled in the online block diagram, or in the project with the front-end Engineers and development engineers, word of mouth, repeated acceptance, and constantly iterative changes to ensure that all the interaction design intent to finally be presented.

Two, why write?

DRD is not a necessary part of the project, and usually does not set aside a corresponding time estimate for the interaction designer. Without this document, the project will continue, but the project may incur unnecessary communication and time costs. Serious, the quality of the project will also be affected. So writing and not writing, interaction designers need to be sure, time is unified in the "wireframe" link-if you want to write, please reserve 1-2 days in the evaluation.

So, with my past experience, it's necessary to talk about this document.

The following figure is a basic process for a product development project.

Agile development means that the processes of many different roles require parallel operations. If you wait until the product manager's FRD have been finalized, the interaction designer will start to draw wireframe, which would reduce communication costs and rework risk, but it also means that many of the ideas of the interaction designer are not being adopted. If the product manager is stronger, he will even be in the FRD even the original demo is also drawn out, functional requirements and interface interaction needs sometimes can not distinguish too clearly-for example, he will be in the FRD directly required per page entries 40, more than 40 is pagination. And the interaction designer may think that the constant loading of pages like Mushroom Street will be more affinity ... So, we want to start working with the product manager at the same time, complementing each other when the operation is specialized.

Similarly, development engineers want to get involved in requirements early, understand the requirements when FRD is not identified, and then translate the business requirements and functional requirements into the development requirements list that the developer understands (this list, most of which is called UC, use case), when the list is by the engineer's demand analyst--in the past, This role is called RA, but has now canceled this special position, but the development Engineer representative to work on this link, in order to facilitate the description, in this article, I still will do this thing as ra--delivered to the specific execution engineer, Executive engineers can basically be used as a checklist to start working efficiently without having to rethink business logic and requirements. Similarly, test engineers need to write specific documentation to guide many testers to test efficiently after development, based on UC and FRD.

Therefore, the development of demand analysis is a very important link. So how does RA do the job of demand analysis?

1, early intervention, the development of PD needs assessment support;

2, participate in each FRD review meeting;

3. Review the FRD document in detail and confirm with PD continuously.

It is very important for the person who does this thing to have enough detail frd. So while a FRD is a PD output, many of the implementation details are being evaluated and validated by development engineers. However, there are many problems in the transmission of design demand. In addition to wireframe, there is no "detailed descriptive document" to tell them. Like what:

On the one hand, the interaction designer said to the product manager: "This is for us to consider, your document does not have to include design instructions, which can be adjusted at any time."

On the other hand, the review of Wireframes sometimes lets RA participate, sometimes without calling them. Even if they are called on, they will find that the need for interactive design changes faster than FRD. In addition, they would argue that UC does not have to write too much about the need for interactive design.

At the end of a major project, as an interactive designer, I did some research to hear how the relevant people expressed the problem:

Requirements analyst for Development Department:

1, every change is very painful, design changed, I will follow the UC, change the screenshot, sometimes ued changed also forgot to notify us, causing UC problems ...

2, the need for page interaction is easy to miss, because UC can not write too many interactive aspects of things.

3, Hope ued can submit HTML demo to Ra, can also give a page element description document, need to introduce HTML demo in the Copy, link and related picture size or display character number. Now RA spends a lot of time in this area, and ued to confirm the content often.

Product Manager:

Early in the process of RA and PD communication, there are many interaction points can not be clear, such as "the default display how many property values", "How many characters to display the title" and so on. In past needs and projects, we are all thinking of a little bit of a complement to FRD documents or emails. Both increase the cost of communication and there is the risk of missing details. PD, for the sake of controllability, often "FRD", indicating this demand directly in the case (for the interaction designer, it leads to no room for manoeuvre).

After visiting some of the interaction designers, they also have the puzzle of how to clearly and without omitting the need to pass on the interactive design requirements:

The common design requirement, if not expressed, is easily overlooked by the front-end and development. I experienced a project, the front end of the replacement of three people, each time I have to repeat to explain the design requirements, speak a parched mouth. And after doing well, still need to go to acceptance.

DRD as a reference manual to some extent to avoid the occurrence of the problem of not matching.

Even if there is a problem, it can be used as the checklist of interface acceptance. "I said to a," I said to B, "A to B", into "A and b together to refer to the same document" to reduce the cost of communication and information asymmetry.

The full impact of the user experience (all the time to the test will need to refer to the design document).

But the following questions can be solved by a DRD?

[1] [2] [3] Next page