User experience design process and documentation guide

Document authoring contributes to product concept formation, design, creation, and performance measurement. However, the purpose of writing a document should not be solely for product maintenance. After all, nothing in writing can compare with the real product experience.

As the minimalist user experience advocate, Jeff Gothelf, described in an article in Smashing magazine, the detailed delivery of the user experience as a reference for the future is largely useless from the completion of the production. In today's era of simplicity and flexibility, the key to user experience should be the core of the product, not the overall delivery result. Whether you choose a simple or detailed process, the key is to ensure that the document helps the design move forward (not just a lagging indicator).

The following is an overview of product design development documentation, individual elements, and phases. Different companies have different product development and documentation processes (such as Spotify, but many of the deliverables below are to some extent common to most companies.

The method that we choose is the best way to use, you can choose according to your own situation.

respective relationship

In terms of product design documentation, theory and practice are completely different. We all know the basic principles of user-centric design. We can also recognize the whole process of different research methods, prototyping stages and documentation techniques from a variety of methods. However, you will often ask yourself the question: How does it work in practice?

Simply put, the document is designed to complement the design process rather than simply as a complement to the design process. Before delving into it, let's take a quick look at the documentation work during product design development from a macro perspective. Below, we introduce the links between the various steps of the design documentation from a practical standpoint:

1. During the initial phase of the product definition, you need to brainstorm with all the people involved about the product and how the project will work. Brainstorming may bring a set of start-up plans, a streamlined framework, and a series of early conceptual maps and models.

2. Start the survey below and at this stage your team needs to refine all assumptions and fill in the blanks. This phase may vary depending on the complexity of the product, the timing, the level of knowledge available, and other factors. On the whole, however, it is beneficial to conduct competitive market analysis and perform customer surveys. If you have a ready-made product, it can be helpful to review analytical techniques, heuristics, content, product backgrounds, and user testing.

3. During the analysis phase, product marketing data collected as of now can provide the basis for user features, experience maps, and required documents such as functional spreadsheets and user task matrices prioritized by priority. At this point in time, product definitions, product priorities, and product plans have been defined and prepared to become more formal design deliverables. Sketches and flowcharts may also be produced in succession during this period.

4. The results of this phase will lead to the use of scenarios, concept maps and models to enter the design phase. Common document types include sketches, wireframes, prototypes, Task flowcharts, and design specifications. For example, the competitive analysis and user features obtained during the research and analysis phase will be applied to models, concept maps, and usage scenarios. This, in turn, affects intermediate or advanced deliverables such as wireframes, storyboards, and detailed models. Some companies see the research, analysis, and design phases as a big process.

5. In the implementation phase, a combination of code and design resources is required to produce products that conform to the design specifications.

6. At the time of the actual product release, support records, bug reports, and other analytical techniques are also required to continue to drive the product through successive versions of iterations and upgrades. In subsequent production models, it is necessary to continuously generate and monitor data in the form of analysis and reporting to ensure a successful continuation.

7. Finally, continuous measurements and iterations in the production environment through performance index tables and analytical techniques ensure continuous data-driven product improvement.

Guiding Principles

Now that you have seen the links between the stages, let's look at the principles that will help drive the product forward in all phases. We will show how to use the product sprint approach to keep the process moving forward over time, rather than staying in the initial definition phase.

Similar to the concept of flexibility at the core in software, design sprints mean focusing on specific product and design issues over a 1-3-week period. According to 3Pillar user experience leader Alok Jain, the three key elements of the design sprint are collaboration, reduced friction and concentration of team effort. To put it simply, your design documents should aggregate the work of the parties and must always be user-centric. Because you need to perform all stages quickly, you should maintain momentum and minimize waste. What's more, you have to deal with small issues so that you can be more deeply explored and have a higher risk-taking capacity.

Here's a detailed explanation of how you can use this mindset when you understand products, products, releases, and product improvements.

1. Understanding the Product

Before you build your product, you need to understand the context in which it exists. Why do people, companies, and users care about your ideas moving forward?

According to Smashing magazine, your activities should be able to meet both business and user needs, and the key to meeting both parties through the best design solutions is "activities", because while documents such as business model blueprints and minimalist blueprints are important, You also need to give power to other stakeholders, or you can spend a lot of money asking a bunch of expensive people to gossip about a well-known topic. These activities should be efficient and enable collaboration:

· Interviews with people-using templates, you can have each team member interview 3 related people. How does the product feel about the customer? How should they operate? You can set benchmarks for usability testing and user analysis by documenting how your customers think, feel, and operate in their minds.

· Requirements Workshop – Bring people together to discuss the project plan, and then explore how concepts fit into the product and technical requirements. You can come up with an empty business model blueprint or a minimalist blueprint to fill out with your team.

· Speed 8--pick up the marker and let everyone draw up 8 different product or function ideas in 5 minutes. Ask everyone to rate each idea, and then you can see the overall trends and preferences. This activity is actually the 2nd step in the Google ventures redesign process.

After completing the basics, you can invite a large number of users to conduct interviews and tests to get real-world data for research and analysis. Uxpin's ceomarcin treder approach is to conduct in-depth customer development and usability testing after identifying the problem and scope of work. When Uxpin was just a prototype creation tool on paper, Marcin and the star of user experience Brandon Schauer, Luke Wroblewski, Indi Young, and others shared a detailed record of more than 50 user interviews and in-person usability tests. The product team then used the recorded content to develop user features, wrote dozens of sets of user stories, and ultimately planned the product requirements.

The first step in the "backward" approach used by Amazon is to envision the scene of a finished product's internal press conference. This approach helps to push backwards from the customer's perspective, rather than limiting the customer to a single idea. By iteratively modifying the post-release to perfection, the product team immediately checks for credibility and writes benchmark documents for later design and development use.

2. Design Products

Once you have the basic concept of product use purpose, the following main goal is to build prototypes. Whether your team is willing to use a napkin to paint or to create a wireframe with high-fidelity or low-level fidelity, the final result should be functional. The uniqueness of this phase is that, for most deliverables, the document is the design itself.

Cennydd Bowles, a design manager at Twitter, said the product team should investigate two iterations ahead of time, design an iteration and review previous versions iterations, and if you want to stay flexible, he suggests creating a low-fidelity prototype that allows "interaction over the process." If you are more inclined to focus on detail and are flexible, you can start with a concept map or a sketch, then iterate over the low-fidelity wireframe and finally create a high-definition prototype. Regardless of which method you use, be sure to test with the relevant people and users.

If budget and time permitting, you can also draw an experience graph that emphasizes where the product meets or fails to meet the needs of the user, and makes a task model that shows the activities that the user needs to perform to achieve their goals. While these are not part of the design, it is also helpful to know that you need to understand the positioning of your products in people's brains and markets. Interestingly, Yelp writes style guides that contain common code as a complement to the design phase, allowing the document to truly integrate into the product.

In Uxpin, our process is to use a fine marker and grid paper to organize the team to sketch, then select several wireframes, and then gradually add the details until the high-fidelity model was reached. If user testing is required, we will make the model a high-fidelity prototype. If you want to publish important features, we also conduct extensive user testing, allowing the user satisfaction rate of the prototype to reach 70:30.

3. Build and Release products

When starting to focus on technical jobs, be sure to document the documentation to help you get a global idea. Specific requirements can vary with the refinement of the product, but the documentation must be able to help you understand the priorities of the product when it comes to the public.

Redstamp User Experience Manager Kristofer Layon's view is that you can visually visualize product requirements and technical specification documents in the form of a roadmap. The product roadmap can showcase user stories and help you sort the primary and secondary functions to meet user needs. Sometimes, you can add a specific date to the route map to make it work in the timeline. The benefit of the roadmap is that it helps you prioritize, complementing the building methods identified by the product requirements and technical specifications. When determining a feature, you can use the Kano model to evaluate the functionality in 3 categories:

· Basic Properties --required for the product to work. For example, the basic property of a notebook is to have a keyboard and screen.

· Performance Properties --can be used as KPIs to compare with different products. For example, notebook CPU speed and hard disk capacity is the key to the pros and cons, people generally tend to fast, large capacity of the computer.

· add -on attribute--different supervisor attributes according to customer preference. For example, the Macbook air is extremely thin and smooth to the touch. Some users will think that these are good selling points, but some people do not pay attention to these.

Based on this model, 1-5 points to the functional score, and then put the function into the priority matrix, can help you to initially form the outline of the product roadmap. Apple's approach is to use its route rules and apple new product process as a roadmap for its products, with a set of responsibilities, the creation phase, and significant milestones from concept formation to release. In fact, Apple's route rules are highly valued and will be dismissed immediately if they deviate from the route (clearly stated in company documents).

4. Optimize your product

When building (and ultimately releasing) a product, the document also needs to focus on defining and tracking product sales and other kip. After all, if you do not know which indicators to optimize, there is no way to talk about optimizing products.

Launchclinic's founder, Dave Daniels, suggested that you write down your release goals (for example, 30 downloads in 30000 days) and then confirm that you have the right tools to keep track of your progress. Using the Metrics tool and bug reporting software allows you to create reusable reports that can be tracked in the weeks and later of the product launch. On the customer side, you can also categorize users, then send them a customer survey to assess the content and timing of the iteration.

Spotify's iterative phase is one of the longest stages of product development. The product team uses the current metrics and priority matrices (which may be created during the design phase) to compare the amount of work required to improve some of the products beyond the "local maximum" level, compared with the benefits they can bring. If they feel that the effort is worthwhile, they will return to the definition phase to revise the product to reach the "global maximum".

Objective process under the subjective environment

There is no ultimate shortcut to product design documentation. Almost all companies that use our products use the techniques we have described above, more or less. While product development and user experience design is a highly subjective task, your processes and documentation are not necessarily subjective. After all, the ultimate goal of the product is to get revenue, which is no subjective.

Whether you choose a simple document or a detailed document, the goal is the same: to put your thinking process into writing, so that your team can interact and reflect. The document should be a compass for the product, not a dead-end rule. Some of the stages we discussed earlier may unfold in slightly different order or in parallel, but whatever the order, they are the way to inspire you. Please do what you need to keep your documents moving with the product.

Transferred from: http://www.woshipm.com/pd/117974.html

User experience design process and documentation guide