How to write a design document--Go

The structure of a design document can be divided into background project background, schedule schedule, history version historical record, Information Architecture information architecture analysis (including site Map, Experience Map, flow, etc.), framework frame design, wireframe wireframe, and mockup visual artwork. Depending on the actual project, some content can be omitted or added, such as storyboard storyboard, prototype interactive prototype, etc.

In the past, I once did not have any normative design document writing habits, with paper strokes finished information architecture and wireframe, hurried into the mockup stage, the final delivery is only mockup. Early time feel nothing, and then feel the problem, so it is easy to fall into the visual details of the entanglement, design to half forget the original design goals, sometimes spent a lot of energy tangled a module interactive or visual design good or bad, but found that the whole module has no meaning, Has deviated from the original business objectives and design goals, is not what the user wants, or the scenario is not comprehensive, the design of a module and put into the whole is full of contradictions, the result will need to spend more effort to remedy, resulting in delay or only the version of the issue is full of problems.

and good design document writing habits, although will occupy more time and energy at the beginning, but can ensure that the whole design thinking has been relatively clear, do design time to think about who the user is, what the goal is, so that the design can help to achieve the goal, to the team, to communicate their own design solutions to the partner , but also stronger persuasive.

Background

This part of the content in the designer and PM, the business party to fully communicate the needs of the completion, my habits are generally divided into these modules: Product Description , to design the product is what, depending on what platform, in what scenario, business/product status , Summarize the main problems faced by the demand side, what are the bad experiences, what are the key pain points, what are the user goals , the types of user groups, what problems they want to solve, the access process , what portals the product has, and where the user is ultimately directed. These need to confirm with the demand side clearly, understand the whole context of the product, the final refinement of the design goals: what new features need to be designed, the need to optimize which existing design, improve the experience of the use of the product, guide users to do what the operation, and ultimately achieve the business goals.

Schedule

And the demand side to identify the time nodes of each phase deliverables, to develop a specific plan for the completion of the design, what is likely to be done at each stage, when the internal review, when and the project team review and so on. Ensure that the design is developed at a reasonable pace and can be delivered on time with high quality.

History

Design version of each occurrence of a larger iteration update, should be recorded in the version history, compared to one by one to turn over the previous design, version history can clearly show the design of the iteration process , there are changes in the needs of the design without thinking clearly need to modify the place, What are the opinions and suggestions that people give when review? Sometimes the version needs to be rolled back, can be more easily traced, and after the end of the project to browse this section, you can see your design in which aspects of the beginning of thinking about the problems, how to be discovered, improved and improved, the next time you can think about and avoid the design.

Information Architecture

Depending on the nature of the project, this piece of analysis tool also has a large difference, the specific choice and use to follow the actual situation, rather than mechanical application.

If it is to design a set of Web site system, sitemap is necessary, through it will need to design the content to be presented in a panorama, the entire site architecture can build a preliminary impression, such as the architecture level is too deep, page content duplication and other issues can be found through site Map, Furthermore, it can reduce the information level of the page, merge some pages and so on, and optimize the experience of the product as a whole rather than trees trees.

Experience Map can be the product in different use scenarios, the process of experience problems visually presented, we sometimes get some use of research results feedback, but a large number of feedback suggestions directly enumerated will be very messy, do not know which is the real problem, which is only the individual user's spit groove, Through the experience map can be sorted out the user use of the product is probably what the scene and link, each scene and link have encountered what kind of problems, which problems appear high frequency, etc., to help designers better into the user to use the product of the actual experience process, and then think about the scene, In the link can be carried out how to design the target disassembly and design optimization , and ultimately help complete the overall goal of the product.

Flow Flowchart is also a common tool, you can summarize the different scenarios of the user's use of the product process and the steps are how, the possible branches need to be considered in the design, where possible to produce a large loss, the steps can be combined optimization, Can you abstract a common process to build a framework design, and so on.

Framework

The main difference between the framework and wireframe is that the former is more abstract, generalized, and does not require much content detail, while the latter is more detailed, sub-scene, already has the deletion and detailed copy, etc., from the mockup even only the color, icon, shadow details.

The framework begins to build the shape of the product, abstracting out the general layout principles, what are the modules on the page, what are the primary and secondary relationships between the modules, and how each module will help the user to achieve the desired goals. Thinking clearly about these issues, the next design will reduce the target deviation and the probability of the program rework, can grasp the overall structure of the interface, module relationship, and so on, rather than into the details, the result of the secondary things to distract.

Wireframe

Wireframe a complete skeleton of the product based on the framework, which requires careful consideration of every possible usage scenario, including special cases such as extremely small, error , and so on.

I generally used to create a lot of pages in the Axure document, each page according to the scene to name, and then in the page to draw wireframe, specific to each module may appear some special scenes, etc., directly in the page in the form of a module in the main interface next to the presentation, if it is relatively simple situation, can also be directly described in text. In short, every corner should be considered properly, can not be omitted.

Wireframe Although not mockup, but in the visual effects of the presentation is not sloppy. At first I think not the visual manuscript does not need to consider so much, in painting wireframe when the grid is not considered, the final visual effect is also relatively rough. Later was pointed out in the wireframe this ring, copywriting and other content is basically determined, if not to consider the visual effects, may be in the actual production of visual output, will occur because of the excessive overflow of text content, resulting in the entire page structure must be forced to adjust the situation, and ultimately increase the product design costs. As an interactive designer, we may not have to consider a lot of color, create character image and other visual details, but must understand the basic UI design specifications , even when the visual requirements are not high (such as many B-terminal products), need to directly play the role of visual designers, which is also our difference from the " The important value of a product manager who can draw wireframes.

There is a copy , the popular word is "speak words", a variety of navigation labels, various guidance questions, various buttons, such as the copy is also interactive designers need to think.

mockup

Mockup as the main output of the performance layer, on the basis of the wireframe to complete color matching, icon drawing and other visual details of the appearance of the product's skeleton cover the final skin. In the case of wireframe has taken full account of various scenarios, mockup does not need to be exhaustive, but to select the key scene of the interface to draw performance, attention to some hover/active and other state performance, and then labeled (In the company with the help of the artifact seems to have no use of this step, anger praise, sketch Bang Bang, front-end are professional even know point design, do not need too much communication can be high-fidelity restore effect, feel happier than before! ) delivered to the front end. (Think of yourself painting a lot of energy to paint different scenes of mockup, a lot of only a little details of the difference, and wireframe is a bit of paper and pencil sketch, feel stupid to explode =)

Finally put a piece of your own design document structure, although axure a lot of people black, but I think in the document structure to present this piece really is the best use.

How to write a design document--Go