This article from: https://www.pmcaff.com/article/index/1284824297878656

This article explains how to create an interaction design document that your product, UI, development, and testing will love to read. The content of this article is mainly the interaction design specification template (Axure version) used in my work. This specification is summarized by myself, but the construction of the thinking method refers to the methodology of many predecessors, especially the open class content shared by taobao U Point team.

With the idea that a stone from another mountain can be used as a jade, and combined with the work characteristics of my own company team, I summarized a set of interactive design specifications. In use, some small harvest, share, we communicate more, common progress.

This article begins with an explanation of what the interaction design guidelines are, followed by an example of how to write each module of an interaction design document and the pitfalls it has traversed. Finally, a template and component library is available for download.

Guidelines for document normalization in interaction design

1.1 Why output an interaction design specification

1. “The design is recorded, the information can be traced, and the communication is based”. This is important, important, important. The birth of a product is not something you do alone for a few days. It has the width of multiple departments and the length of multiple iterations. As an interaction designer, if the design is not rigorous, it will be filled in sooner or later. Interaction design norms may help you avoid some of the holes.

2. “Trust is really the benchmark for all communication in a team.” Interaction designers, in addition to analyzing requirements and drawing interaction drafts, more often need to cooperate with UI to improve design and follow up development to achieve results. If your artwork isn’t as polished as it should be, the UI and development will start to lose trust in you. Your other work will be difficult at this point. It is not that an interaction design specification can make developers trust you, but a good specification can make up for some of your shortcomings and improve the correctness of your design. At the same time, a good specification document can reduce the cost of communication and learning and show your professional ability.

1.2 Requirements for Interaction Design Specifications

In line with their own is the best. Must be based on their own company workflow, and the upstream and downstream communication later determine their own documents should include what content, what content needs to be written, what content can be written less, how to write, whether there is a common statement and writing method in the team industry. After all, norms are there to improve productivity.

2. Extensions and updates. Learn to adjust and update your templates for different types of projects, controls, and specifications.

Second, the writing ideas and the pits of each module of the interaction design document

Start with a list of interactive documents

Figure 2.1 directory

2.1 the cover

The opening paragraph provides an overview of the document’s basic information.

Version number: The latest number of this document; (Be sure to update)

Designer, developer, tester: indicate the next level of relevant personnel of document flow, aspect communication (if there are many people involved, can also be listed separately)

Figure 2.2 cover

A standardized interactive draft is not only responsible for themselves, but also responsible for other partners and the future.

2.2 Documentation

The purpose of interactive documents is to upload and transfer requirements into visual documents. It is a process file. Therefore, the legibility of a document is a standard to measure the quality of a document. The documentation module is designed to give different document readers the same “worldview”.

2.2.1 Project Background and scope

A more complete project background should appear in the product requirements document, while there are two purposes to write in the interactive document. First, if the project is small and there is no complete product requirements document, this is the place to convey the project background to all parties. Second, deepen the understanding of the whole project team members to the project, before reading the content, first have a common knowledge background.

(Writing tip: Write content equivalent to user experience elements, strategic layer, scope layer outline.)

Figure 2.3 Project background and scope

     

2.2.2 Updating logs

The purpose also has two: first, face oneself. Work is a process, complete record update log, convenient for their future query, at the same time, but also convenient and development test tore each other, bright evidence; Second, development and test oriented. The whole development process is long, with various assisting parties and complete records, which can reduce unnecessary communication costs of all parties.

(Writing tips: 1. The update log can be written at the beginning after the review of interactive documents is passed and the requirements are locked. Changes in the design process can not be written in it (personal experience); 2, writing content to be specific (write not specific, there will be a pit); 3. It is better to add relevant links in writing to facilitate relevant colleagues to find the location quickly; 4. Note the latest content when the same location is changed several times.)

Figure 2.4 Update log

2.2.3 Design schedule

A schedule usually appears on a project schedule, or on a project schedule (depending on the company). The function of the design schedule in the interactive draft is the same as the previous two. On the one hand, it gives the project team members a common background, and on the other hand, it records the design process.

(Writing tips: 1. According to the design process, it can be roughly divided into requirements sorting, requirements review, interaction design, interaction review, UI design, UI review, development, testing, and can be divided according to their own situation; 2. Personal experience: The progress plan here is not a rigorous engineering plan for the whole project. It is only an outline of the communication and negotiation between the designer and relevant colleagues, as well as his own records.

FIG. 2.5 Design schedule

2.2.4 Review record

Unlike the update log, the review log is primarily written during the design phase. Review record consists of internal audit (designer in interaction and visual items (), head of the UED, UED related designer) and external review (designer in interaction and visual items (), head of the UED, UED related designers, head of (products and the demand side), technology, technology, market operation, head of the personnel)

(Writing tips: 1. It is usually accompanied by the minutes of the meeting. After I finish writing, I will directly cut it out as the minutes of the meeting.)

Figure 2.6 Review Record

2.3. Parsing process

The parsing process is the most important part I think, where trust and mental visualization occur. Before prototyping an interaction design, it is important to split your thinking goal-oriented and translate “virtual” goals into various design elements.

To put it simply, this is the requirements analysis of the design dimension. Different people may have different analysis methods and presentation forms, no matter what the way, as long as it can comb their own thinking to help them design and clearly convey information to their partners.

According to my personal experience, requirements analysis has different dimensions and angles according to different types of projects and products of different sizes. Here I will briefly describe a requirements analysis method THAT I often use.

Human-centered, goal-oriented analytical thinking method

When we do design, from a product to a page, there are goals and goals to be achieved. Purpose may come from corporate strategy, from market demand, or from money, no matter where it comes from, in the business world, we make products for a purpose. At the same time, the users of our products and services, they have a lot of characteristics, a lot of product environment, a lot of thoughts and feelings when using the product, they also have their own pursuit and requirements for the product. We are designers, not artists, so we need to make use of our talents to design products that best meet the needs of users and generate commercial value under limited conditions. This process is the whole idea of the requirements analysis derivation below. I won’t expand on the details here, but you can take a closer look at the figure below. I made some brief explanations for each specific link. In the future, IF there are appropriate cases that can be shared, I can elaborate on them.

(Writing tips: 1. You can write in a variety of ways, as long as it helps you understand your needs and facilitates your design. 2. Demand analysis can be written in more detailed documents, such as interactive documents, for the same purpose, so that upstream and downstream can see and reach a consensus; 3. The other methods listed in my documentation are just examples and can be used according to specific situations.)

FIG. 2.7 Derivation of requirements analysis

2.4 Page interaction scheme

A page interaction scheme is what we call an interaction prototype document. Specific how to write, here will not say, specific business specific discussion. Here I will just say several common ideas and methods of interactive document writing, the scope of writing and matters needing attention in daily work.

Against 2.4.1 flowchart

I don’t want to go into importance. It’s important. In addition, be sure to comb out the flow chart before the design (can not be complete), must not follow up to show the flow chart, so that the flow chart can not play its own role. If you’re not already doing this, adjust your thinking.

(Writing tips: 1. If the process is simple, you can draw a flow chart. If there are many processes, it is suggested to divide them into sub-processes to draw. 2. In addition to drawing function flow charts, it is recommended to draw business flow charts; 3. Various drawing software can be axure or third-party software.

Figure 2.8 Flow Chart

2.4.2 Information Architecture Diagram

I’m not saying it’s important. It’s important. Drawing information architecture diagram is just a result of presentation, how to draw is the core, the method is not developed here.

(Writing tips: 1. Information architecture diagrams can be written from the dimensions of function — page — module — element; 2. Common modules can be used in parallel;)

Figure 2.9 Information architecture diagram

2.4.3 Interactive Page

The interactive page is mainly composed of two parts, one is the page, one interactive description.

An Axure page expresses one thing best and is most popular with colleagues. What does it mean to express something? An event can refer to either a process or a page.

An Axure page represents a page.

(Writing tip: Specify the core page, and the associated sub-pages and processes are expressed in other pages.) Figure 2.10 An Axure page represents a page

An Axure page represents multiple states of a page:

Figure 2.11 an Axure page represents the multi-clock state of a page

An Axure page represents a process

A process is the smallest subprocess, and the subprocess and parent process can be expressed in a tree structure of Axure documents

Figure 2.12 an Axure page represents a process

2.4.4 Interaction Description Document

A qualified interaction specification document should include but is not limited to

  1. Page content description (data source, data characteristics, content type, scope, extreme value, sorting rules, etc.);

  2. Interactive feedback, state;

  3. Interactive effect, visual requirements.

In the following case, the page elements are explained in detail, including data characteristics, calculation rules, update extremum, special case description, state description, visual style description, etc.

Figure 2.13 An interaction specification document

Writing here is basically finished, other content is for the personalized needs of different products, do different specific design instructions.

Third, god assists

As mentioned at the beginning of the article, the purpose of interaction design specification is to improve work efficiency, reduce communication cost and improve design quality. As for whether this “two raise and one lower” can be realized, in addition to the specification, I have two “magic weapon” here.

A customized component library. Combined with their own work characteristics, customized in line with their business category, and work habits of the component library, efficiency will be twice the result with half the effort. Component library is not overnight, but according to business characteristics and design habits, slowly debugging. Attached is a set of component library customized by myself that conforms to my design characteristics. You can make corrections and adjustments on this basis.

Second, the team. Tacit understanding, cooperation and collaboration between teams are the magic weapon to improve work efficiency, reduce communication costs and improve design quality.

See me so long wordy, I also feel a little embarrassed, I send a copy of the interaction specification source file and a design component library. For your reference. Communicate more, communicate more.

The interaction specification source file: https://pan.baidu.com/s/1PnRZpir8JJDmCNVLfEi0vQ

Password: pew7

Component library: link: https://pan.baidu.com/s/1lS4DpO5mU0VtrMh-K3XFCw

Password: r4rp

(PS: Component library is adjusted and updated on the basis of ant Financial open source component library)

, End,

Micro-interaction ∣ Detail design makes for great products

Long press, identify the QR code, add attention

Share the article and let more people know about microinteraction