Interface Interaction design Document what document should be written?

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 a lot of recruitment instructions on the need for interactive designers to write interface interactive design documents, what is the interface of interactive design document document?

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.