It's been a while since we left the circle. 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 the project (in the following article, abbreviated as DRD), the format is not limited, the interaction designers themselves write to the interface also line, the individual document is also the line, in short, so that interactive designers can not load the interface information through the document precipitation down To 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: I. What is an interactive documentation (DRD)?
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 a large project, interactive 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. 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 Cheng 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 instruct many testers to test efficiently after development, based on UC and FRD.
Therefore, the development of demand analysis is a very important link. How does RA do the job of demand analysis? Early intervention, the development of PD needs assessment support, participate in each FRD review, detailed review of the FRD documentation and continuous confirmation with PD. 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. But there are many problems in the transmission of design demand. In addition to wireframe, there is no "detailed descriptive document" to tell them. For example: 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, listen to the relevant personnel is how to express the problem: the needs of the Development Department analyst: Every change is very painful, design changed, I will follow to change the UC, change the screenshot, sometimes ued changed also forgot to notify us, causing UC problems ... The need for page interaction is easily missed because it is impossible for UC to write too many interactive things. I hope ued will be able to 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 the number of characters. Now RA spends more time in this area, and ued to confirm it. Product Manager: Early RA and PD communication process, 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 controllable needs, tend to "take over", directly in the FRD to note this demand (for interaction designers, but also lead to no room to play) after visiting some interaction designers, they also have how to clearly and without omission of the interaction design needs to pass down the confusion: the interaction is considered to be a common design requirements, If not expressed, it is easy to be ignored 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. Full impact on usersExperience (all the time to test, you need to refer to the design document). But the following questions can be solved by a DRD? Three. What do you write? Be clear about the location of the document, starting with what you write and what you don't write, and make a distinction between DRD and frd boundaries. 1. Does not write the Visual specification specification annotation These instructions and the function realization not to have the big relation, mainly is for the front-end does the HTML time reference. General 10243.html "> visual designer will be clearly labeled in PSD. Figure: 2. Do not write function to implement logic.
as shown in the following figure, as a DRD, you need to communicate the design of the Browse by category area: The clickable nature of the link, the point of the link, the number of characters and entries, but whether the class two category is ranked by the number of products or alphabetically, or by manual operation, FRD is the task to be solved. So what does the document say?
give an example to illustrate: 1. Character restrictions improve space utilization, and sometimes dynamic text on a Web page needs to be extracted from the database and truncated. For example, the title and description in the following figure. Your DRD need to communicate clearly: 1. 2, if the limit, how many words appear truncated? Is the truncation displayed as an ellipsis or does it not appear? The Chinese design is relatively simple, if the English word, because it is by character, the width of each character is inconsistent, needs to be estimated, in addition to indicate whether the whole word truncation or between words truncation. 2. The link materialization Many websites have the search result the filter design (refine search), for example aliexpress search results page left. The interactive events in this area are very complex. The difference between a class and a property how do you handle a property and the entry for the property value displayed by each property has a display limit? Checked, the selected attribute value is to stay in place, user-friendly memory, or put to a unified location, user-friendly unified view? Do other property values that are not selected disappear? To make sure that the complex interaction logic you envision can be understood and presented, in addition to a one-page wireframe, you need to keep the front-end engineers and development engineers informed and understanding. So you need to identify the key link events on the page clearly. Some of them point to the interaction without refreshing the page, and some point to a middle page that you have not scheduled for PD (page flow is the responsibility of the interaction Designer) 3. Interactive detail Description
Believe me, I hate to write these things. I like to present my wireframe to the stakeholders in the conference room, and I'll look at using axure to make a variety of dynamic effects that are realistic enough to show all kinds of linkage-for example, when you select an item in the Drop-down menu, the other areas of the page change accordingly. But Axure is not omnipotent. Even if you can express it, a wireframe delivery will not ensure that everyone else will be able to click on it. So you can just repeat it in the boardroom and double-check and urge changes after the event.
But when I try to explain this small and complicated area in detail, it becomes much simpler. So I saved the time to write this ppt. Again, you can explain any effect you want here. Your audience will only need to use 10 minutes to read, marked with his work-related focus, archiving and in the face of problems, can not find you at any time reference. 5. Verification of forms This is also a less creative thing, but if you don't think about it in advance, it's a bit of a hassle in the project. Writing a document may seem tedious, but it's also a key step in getting yourself to think about the audit design itself. I once thought that the perfect interactive design plan is writes the DRD time to discover the significant mistake, then optimizes in time. 6. Browser compatibility requires your products to be compatible with all browsers is a dream, but sometimes for efficiency, we must strategically abandon some browsers, such as IE6.:D 。 Who's going to make this decision? Is it a front-end engineer or a product manager? Or you--an interactive designer? I think the decision is right here with the interaction designer, but he has to agree with the Product manager and confirm with the front end. The more you require a compatible browser, the higher the standard, the greater the amount of work on the front end, and even the amount of work that can be doubled. Four. What time is it delivered? Heidi's advice: deliver as much as you can with your wireframe, and if you deliver a block diagram first, you may be able to identify problems or generate optimized ideas when writing DRD. But it often takes at least 1-2 days to write DRD, and you can't have all your work downstream. So: You can deliver the block diagram for visual first. Visual design tends to do style positioning design first, which has little to do with interaction details. First pay the already determined wireframe to the front end, then after 1-2 days DRD, if there are changes, with the front end one by one confirmed and delivered together. Five. How to write DRD?
1. Choose the most efficient tool. My experience is that this tool is best able to provide a clear directory navigation structure, and easy to annotate. Word is really a good tool for writing documents, whether you believe it or not, I believe it anyway. 2. Establish a fixed directory structure the following figure is for reference only. Details inside, not a wordy. Six. Important principles prepare to write DRD friends, please know clearly what is the real problem of this document to solve? If it is to solve the problem of communication deviation, missing demand, high cost of communication, you have not seen this problem in the project, the partners have good feedback, then this document need not write. If it is to solve the requirements of the design of the archive, to facilitate the follow-up staff to see the revision of the problem, it is another thing (experience proved that the past DRD can certainly play a certain help in the revision, after I left the original project a long time, the new designers also find me to have the corresponding project documents to understand the past design logic). Not to write documents (but to solve problems) for projects, partners (large projects have large documents, small requirements have smart solutions) tool is not a problem (easy to spread, easy to annotate, catalog) template is not a problem, You can see it. The perfect document cannot replace face-to-face communication (review and discussion will not be reduced by documentation) and need to be continuously improved in practice by seven. Who's going to write it? I suggest it be initiated by an interactive designer, but revised by the front-end engineers and passed on to the development engineer. There is a lot of demand, the interaction designer just needs to realize, but he may not care whether it is a front-end implementation or a backend implementation. The front-end engineer checks and revises the DRD, can translate the design language into the language which the engineer can understand, and can delimit and develop the realization boundary.
Eight. In relation to other outputs the deliverables correspond to different use roles, as shown in the following illustration: But the problem is that although DRD's target audience has development and testing, it is impractical for development engineers to refer to so many documents at the same time, so it is still the interface of the development engineer, In fact, RA needs analysis as a demand integration delivery role, the business needs and design requirements, communicated to the specific implementation of development engineers and Test engineers: "Summary" for me to insist on writing DRD, DRD of course the benefits of the understanding. But not everyone likes to write documents, they like to read documents. There are many solutions to the problem, DRD is just one. However, when you have a problem with the design requirements, or if your needs are understood to be biased, or if your needs are missing, or if the project you are taking over is revised, you can try DRD as you comb through the past design logic. If there is a problem with the use of the process, then think about whether there are other solutions ~ Source: http://heidixie.blog.sohu.com/207036464.html
