10 ways to make your wireframe prototype more communicative

Intermediary transaction SEO diagnosis Taobao guest Cloud host technology Hall

Although it's a weekly translation, it's really not very easy. From reading, to screening, to trial translation, to finalizing this week's article and completing the translation, the main thing is to spend some time each day doing it. Fortunately, after all, is autonomous behavior, love, also still in love, this is UX practitioners and translation fancier has wood. tacitly, we enter the text of this time.

I have been involved in many product wireframe prototypes, including my own, and working with other designers, product managers and even business analysts. It's great because I've seen a lot of good projects in the process. But slowly I also found some problems, some people often in the prototyping process to ignore the elements, if you can pay attention to and solve these problems, our interactive design output can play a greater practical value.

The following illustration shows a typical example, and we typically deliver this style of wireframe text to colleagues to follow up on visual design or prototype testing.

This kind of wireframe is a clear description of how the page elements are laid out, but that's all. What it lacks is the ability to communicate with other designers, developers, and tested users. Next, we'll take a look at some of the ways that we can help improve the performance of wireframe prototypes.

1. Describe the visual priority between modules by contrasting the light and shade

What do you want the user to notice on the page first? Where should their eyes be focused? What do we want the user to do? These questions cannot be simply left to the visual designer to consider, and the wireframe prototypes shown above are clearly not helping the interaction designer communicate this information.

First of all, according to the product requirements and the actual situation of the use of research, as a product personnel or interaction designers, we should be in the above information at hand; On this basis, add visual priority to the original Wireframe manuscript. In fact, it is very simple to implement, all the Dark "wireframe" removed, using different brightness of the gray as a background color to define the edge of the page and module, and to express the visual priority between the different elements. Compared to the previous pure wireframe design, we can clearly feel the priority relationship between elements and modules in the following figure, such as the hotel information recommendation and the action button in the right booking form can catch our eyes in a short time.

This approach does not mean that the interaction designer is playing the role of visual designers, we are not saying that "the background color of this element is more than the other elements of a deeper", these light and dark relations to reflect only what elements need to highlight, which elements should be relatively weakened; The final form of visual representation should still be controlled by visual designers.

2. Use real data content

We should try to use the real data closest to the production environment for the sample contents of the Wireframe prototype, including the title of the navigation element, the form label, the introduction copy, the icon, and so on. This approach can be more effective to help us plan the layout of the interface elements, and in the actual environment can be produced in the extreme data situation to develop preventive programs to ensure the robustness of the page structure.

More importantly, wireframe prototypes that use real data as sample content can be more expressive and persuasive in the next usability test, and users who are tested don't have to rely on the moderator's description or their guesses to get more accurate information in the prototype. In addition, the real data can create a more close to the actual product of the use of the atmosphere, which can make the measured users more input. For testers (moderators, observers), we can design more targeted tasks or issues, can be tested in the process of the user to be measured more in-depth observation, the corresponding, the final collection of feedback will be more real and effective.

Still take the example of a hotel prototype, such as "Can you find this hotel's special service information?" Such a problem is not appropriate because it tells the user that it is there somewhere in the page where the information is available, and they will only be looking for it. Most of the cases must be found, but such feedback is meaningless to us.

If you use prototypes built from real data in your tests, it would be a lot better, and we could ask the user, "How do you feel about this hotel?", which would give us a huge increase in access to effective feedback. Users will be able to conduct more autonomous browsing behavior based on such questions, and they may answer "the hotel looks good, but they offer a family pool, and I don't really like the kids running around the hotel." ”

Through this kind of feedback, we can understand that the user not only noticed the important elements in the page, but also made a real thinking about the specific content. It can be said that through a set of no real data content of the Wireframe prototype, we can test the availability of products, and the use of real data as a sample content wireframe prototype can be more comprehensive to help us test the product user experience. To learn more about the practical aspects of prototyping testing, refer to our previous article, "Early prototyping and user testing of the product."

3. Ensure the accuracy of the details

After populating the prototype with real data as an example, we want to ensure the accuracy of the information involved in the interaction process. For a simple example, if the shopping cart's page prototype shows two items with a unit price of 50 yuan, the total price should be 100 yuan instead of any other number in the checkout process. The wrong information can hinder the effective communication, developers may be questioned here, the test users will be confused.

As designers, it is easy to overlook the existence of such problems by focusing on the production of prototypes for a long time. If you have the conditions, you can ask someone else to help you check your prototype for errors in such details in due course.

4. Increase the self-describing ability of the sample picture

Images play an important role in improving the user experience, and when people are looking for goods or services in a Web site, pictures are a key ingredient in making decisions (how to help users make decisions through design). In addition, the picture also can help the user to the website own image and the localization produces the cognition. However, in the online box prototype, we usually only use some gray containers and lines to represent the picture.

Of course, I'm not suggesting that you use real pictures or photos in an online box prototype; What we need to do is let the wireframe elements that represent the pictures reflect what type of picture is in the actual page. Before making a wireframe prototype, it is best to communicate with the relevant product or business personnel on this issue, according to the product's own characteristics and the end-oriented user groups, to determine what kind of visual elements of a picture should have the overall style.

For example, I used to do a website revision for a shirt retailer. Before embarking on the design work, we first used the old version of the Web site for a user test, the result found that the Product details page of the demo will always confuse the user. In order to make the shirts look better, they were deliberately paired with ties and cufflinks while taking photos, which allowed the user to assume that each shirt was a suit containing ties and cufflinks. So when I was designing wireframe prototypes, I drew a sketch of a shirt without ties and cufflinks in the location of the merchandise photo to make sure that the visual designer and the people in the next section were able to understand and avoid repeating mistakes in the new website.

We don't have to use very fine painting to add a description to the picture elements in the wireframe prototype, and a simple sketch to state the type of picture that the user wants to see here. For example, what kind of pictures do users usually want to see on the Details page in a Web site that offers hotel reservation services? The room, the bathroom, the view? These questions are worth taking time to understand and embody in the online frame prototype.

5. Be cautious when using color

In an online box prototype, color is usually used for annotations. When necessary, we can also use special colors for those who specifically need attention to the interface elements to annotate, or to express the error message of the State class content. Remember, however, not to use a color-annotated version of the prototype test, because it is obvious that we do not want the user being tested to be guided or interfered by these "salient" elements.

6. Ensure that the interactive elements are clearly understood

The interaction element should be rendered in a way that fits its purpose, such as if the button should appear to be clickable. The accuracy of the visual representation in these details will directly affect the understanding of the prototype by visual designers and developers, and the potential experience problems of non-explanatory interactive elements are exposed to usability testing.

7. In real pixels

If you use HTML to work with style code to make prototypes (using the front-end development framework to quickly create a page prototype), this problem is largely non-existent because you typically have to set the width or height attributes for the container in pixels. But most of the time, we create a pure wireframes. The layout of the page and the size of the elements are planned and explained in real pixels, which will help us and the visual designers to save a lot of "guessing" and "estimating" processes in the next work. I used to use PowerPoint to make wireframe prototypes, which only show the approximate size and location of elements, and when the project went into the visual design process, it couldn't effectively help me communicate with the designer, causing a lot of trouble.

8. Create Change Log

As iterations continue, changes in each version of Wireframe prototypes are often more granular, from the page structure to the modules and controls, making it increasingly difficult for designers or developers who follow up to discover all the changes. As an interactive designer, it is our responsibility to create a change journal and keep it updated as the project progresses. Each record in the log contains the date, version number, performer, and change description. This way of exchanging information does not take too much time, but the result is more effort, regardless of product personnel or designers, developers, you can make a clear track of the version of the prototype changes.

9. Avoid Dark wireframe

A dark wireframe full of pages will make your prototype look a little layered, rough and messy. As we said in the 1th, try to use different shades of gray as the background color to define the edges of the page and the module. This not only shows the visual priority of the interface elements, but also makes the entire prototype look neater. If you have to use lines in some places, try to use thin, gray solid or dotted lines. While we do not need to make wireframe prototypes look as perfect as visual manuscripts, the mastery of these details can make it more concise and, in practice, tends to increase the degree to which prototypes are accepted.

10. Maintain follow-up

This is more in favor of delivery processes than design techniques. After completing the Wireframe prototype, we can't simply throw it to the colleague following the follow-up. Take the time to support the work of visual designers or developers, and only they can put your design concept into practice. Often, the information contained in the interaction prototype, such as ideas and operational logic, is difficult to understand comprehensively and accurately, and the hidden problems may be reflected in the subsequent stages. It is necessary for us to follow up after the prototype has been delivered and to work together.

These are the 10 tips for improving the communication ability of wireframe prototypes. We can refer to our previous article "The Essence of Wireframe Prototype and Practical Application Overview" to learn more about the basic concept of wireframe prototype and how to apply.

Original site to compile the article. If you want to reprint, please specify: This article from the IS for Web

English Original:

Http://www.netmagazine.com/features/10-simple-ways ... Translator Information: c7210-user experience design and code player, is now working in the public Comment Network product Department ued