Start with the most important screen, the one where the user will spend most of their time. If you’re working by yourself just use pen and paper. Next, list all the visual elements (text, buttons, forms, graphs, menus) that appear on a screen. Once your MVP is launched, you can wireframe individual non-trivial features as you build them. If you’re creating a minimum viable product (MVP) you shouldn’t need more than about four or five key screens. Both apps only need about four key wireframes that are vital to their success: user registration, the main feed, people search, and the people search results screen. Practically though, you only need to prototype the most important screens, and you can usually normalise many of the screens into a single wireframe.įor example, Twitter and Facebook both use similar screens for your home feed and another person’s profile, so only one wireframe would be created for each of these two screens. If you have the time and capability to create a wireframe for every screen of the app, it certainly won’t hurt. The benefits of including multiple people are the communication of design decisions and the increased chance that someone will regularly jump in with, “How would the Simon persona use that? ” It’s not design by committee. Too many times I’ve seen a wireframe session dominated by a headstrong developer who thinks that the app should be designed around their way of working. One caveat: only include people who have knowledge of the personas and subsequent feature decision process. If you’re designing the app for a client, their inclusion may help to communicate and improve design decisions. If you work in a small team, you may find it useful to involve the whole team in this process. With the knowledge of interaction design, composition, grids, hierarchy and style firmly implanted in your mind, it’s time to sketch out – wireframe – potential app interfaces. It’s also surprisingly quick and inexpensive – you’ll see results from as little as thirty minutes’ effort. Not to be overly dramatic, but it can make or break the app. It highlights real issues with the interface, and our choice and implementation of app features while they are still easy and cheap to change. This is the biggest test of our work to date. However you feel about these topics, and however experienced you are at interface design, do not skip this step. They often evoke images of disposable, time-consuming, expensive pieces of work. It’s easy to be turned off by the very mention of a prototype or a user test.
Prototypes and user tests - A Practical Guide to Web App Success
0 kommentar(er)
