1. What is an interactive document?
Interaction documents, that is, interaction design documentation. English "Design Requirement Document", abbreviated as "DRD". It is used to carry design schemes, interactive prototypes, interactive descriptions, etc., and to archive and interact with team collaboration documents of project-related partners.
2. Why do you need interactive documents?
You might say: "A product manager can output DRD without an interaction designer." But in fact, many interaction designers can also assume the role of a product manager... balabala omits 10,000 words here~ as long as you are good enough, you can become a CEO! To put it bluntly, the job title is just a division of job responsibilities, and it is a way for the company or department to improve professionalism and work efficiency to achieve the company's goals.
Closer to home, as an interaction designer, the job responsibilities play the role of "connecting upstream and downstream, linking the previous and the next". Whether it is in the explanation of the program review or in daily work communication, one should have excellent language expression and DRD expression ability.
DRD can not only perfectly explain the product content and design ideas, but also facilitate the design specification and unification, keep the product consistent, play an important role in the coordination of all parties in the project, and facilitate the later project summary.
Therefore, DRD is a medium that facilitates teamwork, and is also an important output of product specifications and project summaries.
3. Who is reading the interactive documentation?
Business side/demand side: including product managers/operation managers, mostly product managers here.
They will pay attention to whether your design scheme meets business and user needs through DRD. After discussing product planning and business requirements with them, interaction designers decompose key factors based on user needs, and finally summarize design requirements. And DRD is the elaboration medium of the whole design idea.
Visual Designers: Visual and UI designers are included here, or animation designers are included.
What do they need to know about product positioning? What pages should be designed? What is the transition between pages? What state does each element of each page include? How to design in special cases (data loading, network exceptions, extreme cases, etc.)?
Developers: including iOS, Android, H5, Web and other front-end development engineers and back-end engineers.
They need to know from DRD, how many functions does the product need to achieve? how many pages? How to achieve it? How to jump between pages? How to deal with abnormal situations? …and implement it in code.
Testers: Includes test engineers and others involved in testing.
They need to refer to DRD to sort out the test cases. The test cases must cover all functions, usage scenarios, operation behaviors, and product details, and must ensure that there are no bugs or less bugs in the online state.
Follow-up related personnel: such as account managers and customer service specialists.
They need to have a good understanding of the business and products in order to better carry out follow-up work.
4. Structure and content of interactive documents
So, what should a good DRD contain, and what aspects should you pay attention to? The following are the DRD output ideas I sorted out, for communication or reference only. The content comes from the summary of work experience, the communication and feedback from colleagues, and the summary of related articles that have been read in the past.
4.1 What tools are used to write interactive documents? What format is the output in?
What tools are you used to writing interactive documents? PPT, Sketch, AI, Axure... ?
What format are you used to exporting your interactive documents? PPT, PDF, HTML...?
I also ask myself the same question, what tools and formats are the best? After practice, the summary is as follows:
For large projects or complex requirements, Axure is recommended to output HTML format.
Axure contains a site map, which can clearly display the hierarchical relationship and complete the jump of the scene very well. It can also be updated in real time by sharing links, making collaboration more convenient.
For small needs, it is recommended that Sketch output PDF format.
\Sketch draws prototypes with high efficiency, and the output PDF is beautiful, overall, not easy to miss the content, no equipment and network restrictions, easy to read. But there is no site map, so it is inconvenient to read large projects/big needs.
If it is an overview of the plan, it is recommended to output PPT in PPT format.
PPT has no threshold for use, is convenient and efficient, looks more formal and beautiful, and has no equipment and network restrictions. But one page of PPT can't put several interfaces, and there is no site map.
4.2 What should be included in the interactive document?
DRD can determine the content, elements and styles according to the actual situation of the company or project. This is just a more general document structure template organized in my work: it is divided into document cover, update log, document legend, design background/ideas, overall business process, page interaction, special instructions, wastebasket and other parts.
DRD cover
[This picture is not for commercial use, please contact me if any infringement is involved]
DRD Cover: Including document title (project/product name), version number, release time, author and other basic information. The heads of all parties involved in the project can be added as needed. (such as: product manager, interaction designer, visual designer, development, testing, team name, etc.)
update log
Update log, including specific new or modified content, modification person, modification date and other information. In actual work, the modification and optimization of the scheme is inevitable. The update log is convenient for project members to pay attention to the key update content at a glance, and it is also convenient for development to find the corresponding person in charge to communicate and improve work efficiency.
Other details of experience sharing:
-
The date the document was updated is ranked first by the most recent update (it is better to distinguish it by color). In this way, it will not take too long to find because the log is too long;
-
The latest modified page can be clicked to directly jump to the corresponding page. It is convenient to find the corresponding documentation page faster.
document legend
Explain the legends you use in this document to assist reading. Especially for those who are new to your DRD, it will help them understand your documents, especially some non-universal symbols.
Design background/thought
It can include some project background, demand analysis, user research, competitive product analysis, etc. It is used to sort out and record design ideas, which is convenient for reading, for people participating in the review meeting to understand the design ideas in the context of the entire project, and for future review and summary of the design. However, there is no need to put all the analysis content in, just put in the key content in a structured way.
Requirements analysis should include business requirements/functional requirements, user requirements, and analysis and induction of requirements. The following figure is a random example for reference only:
Business flowchart
Mainly the overall business flow chart. At work, most of them are written by product managers, communicated and sorted out by interaction designers (we will not share them in detail this time). The flow chart can also be adjusted according to the specific project, for example, follow the module or process of page interaction.
page interaction
Page interaction is the main body of DRD. Including information architecture, task flow chart, interface interaction diagram, interaction description, etc. The structure of page interaction should be built according to the product information architecture. It is required that the function level should be clear, the naming should be reasonable, the format should be unified, and the updated content should be uniformly marked, so that others can browse and find it conveniently.
1. Information architecture: It is the skeleton of the entire product. It is relatively stable. When it comes to the needs of information architecture, it is generally a new product, new function or major revision of the product. The information architecture diagram can help us sort out the structure of the entire product in the early stage, and iterate according to the large architecture in the later stage, while making the information easier to understand and browse.
To build an information architecture, it is necessary to determine the structure type based on product characteristics, clarify the priority of functions, and extract important functions according to their importance, commercial value, and frequency of use. Scalability also needs to be considered to facilitate later iterative optimization.
2. Task flow chart: It refers to the steps and process of sub-tasks to express the logical relationship of the product graphically, and refers to the feedback of various results after the user uses the product.
You need to fully understand the needs, consider and guide the user to complete the user's goal from the user's point of view, paying attention to the user's operation can not only make your thinking clearer, but also avoid the omission of operational logic. It can also be quickly understood by others.
Other details of experience sharing:
-
Write by task, don't write all the processes in one big process, it is inconvenient to browse, and it is easy to miss or make mistakes;
-
The "start" and "end" of the flow chart avoid being lost for a long time;
-
The process is clearly defined, and the process can be browsed smoothly, and each process can be seen in an all-round way;
-
The flow chart is simplified as much as possible, the process line is avoided as much as possible, and multiple processes pointing to the same result can be combined.
3. The content of each interactive document page:
-
Documentation page title: Usually at the top of each document page. Indicate which module or process the content of the current page belongs to, so that the viewer is not easy to get lost;
-
Interface title: pay attention to the naming, so as to facilitate the mutual connection in the interactive draft, such as "jump to [XX page]", "back to [XX interface] state";
-
Interface: It is recommended to reduce the size of the interface according to the proportion of the actual interface, so as to avoid that the design you take for granted does not conform to the specification, and also avoid that an interface is too large to affect the reading effect;
-
Design description: logical relationship, operation process or feedback, element status, character limit, abnormal/special status, etc., can all be placed in the design description;
-
Process line: illustrates the logical relationship between interfaces;
-
Jump link: point to other pages, such as a sub-process, which will be convenient for development partners to read.
Special Note
Include some content that needs special instructions, such as global general instructions, default page summary, animation effect instructions, sound effect instructions, etc., depending on the actual project. On the one hand, it can ensure design specification and product consistency, and there is no need to repeat every detail on the document page; on the other hand, it is convenient for visual design and overall viewing of development. This part of the content is also usually placed in the "page interaction" structure.
wastebasket
The wastebasket is actually the "regret medicine" of DRD. The design plan is constantly adjusted and optimized. The content that I thought was useless is all put here to prevent it from being used later. (Change, change, you know~)
Other details of experience sharing:
After the "Trash", it is best to note "ignore not to see/only UE to view". Otherwise, it is very likely that someone who does not know why will come to you and ask you, which is the latest, this page or the previous one...
4.5 Other small experience sharing
1. Don't write documents for the sake of writing documents, write to solve problems.
It is mentioned at the beginning that DRD is used to carry design schemes, interactive prototypes, interactive descriptions, etc., archive and deliver to relevant personnel for reference. So don't write documentation for documentation's sake, solve real problems.
2. DRD should be rigorous in logic and concise in text
The content structure of DRD and the structure of page interaction need to be clear in thinking, rigorous in logic, and conform to the hierarchical relationship of the product architecture. The content of the document should be written logically and concisely, so as to better visualize and simplify the ideas and solutions of the interaction design.
3. Beauty is applicable, pay attention to the experience of documents
DRD also considers beauty? The answer is yes.
DRD is also for human use, and should also focus on user experience. In addition, are my abilities in other areas (such as logical thinking, product creativity, etc.) so good that they can overshadow my shortcomings in the presentation layer? If so, then you don't have to care too much about the form. However, the definition of DRD "beauty" is different from that of vision. It should be beautiful, clear, easy to use, and in line with the principles of user experience. It is more inclined to a logical beauty and an experiential beauty.
4. When making a plan, first consider and complete the normal situation, and then start to draw all abnormal pages or content.
Because starting from the whole, the boss or the demand side can have a complete plan to see if they want to see the plan in the middle; in addition, if the large process and page are not confirmed, what's the use of being detailed?
5. One page of interactive documents, one task/process.
The content that can be displayed on each page is limited, and if it accumulates too much, it will become a problem; in addition, it is also convenient to form a common task/process
6. It is best to display different states of the same interface/page in the interactive document on the same page.
So as not to cause modification or reading confusion.
7. Try to use black, white and gray for interactive prototypes.
Avoid prototypes from interfering with visual designers and affecting visual performance. In addition, if the color is inconsistent with the visual draft, the test will ask which one to use~
8. Alignment makes documents more readable.
The alignment of the interface to the design specification, and between interfaces, makes the document easier to read.
V. Summary
Interaction documents are very important, but their core is not pure formal beauty. The most important thing for interaction designers is to think in many aspects when designing.
(Although this article does not focus on "needs analysis and design thinking", it is really, really, really important!)
Learn more about business needs, ask why, find out more fundamental questions, summarize core business needs, and tap the most fundamental and real needs of users...
What are the solutions to these needs and problems? Which solution is better? Is there a better solution? When the designer cultivates to consider everything clearly, and then make trade-offs. The user experience of the product can be made better, and naturally a high-quality DRD without logical problems can be produced.
In this way, you can tell how well your plan is doing at a glance at DRD, and you can tell at a glance whether your DRD is good~