There is one thing I always say to customers in a kick-off meeting: I will fail, and I will need your help to get it right. I am not particularly humble, nor am I trying to set low standards so that I can easily exceed them. The idea is to call for their active participation in the design phase and lay the groundwork for shared accountability. Accountability means that I will fail, but then, together, we will win.
Fail Fast to Fail Cheap
An old argument used for software testing states that the cost of fixing a bug early on in the development process is dramatically cheaper. That if you find it when you’re gathering requirements, you can save up to five times the amount of money that you’d spend if you found the bug in QA or Production. Someone tested this; I am sure.
The underlying idea also applies to a well-structured UX/UI process. If by the end of the design phase, your intention is to shape a concept into a beautifully crafted clickable prototype, then you should start finding and fixing your misunderstandings and misconceptions right from the start.
So You Go Lo-Fi First
Imagine it’s day one, the kick-off for a new app. Around the table, there are very important people from the customer, possibly some key users, and you, second cup of coffee in hand and eager for that thrill of learning something new that always hits on the first meeting. They start explaining their goals for the app, and they walk you through the process they want to create or improve. They show you the benchmarks, even marketing data if you’re lucky, and probably some process flow diagram that only the guy who made it can pay attention to.
For the next few days, you’re enrolled in user research. You get to create user interviews, go for contextual inquiries, and define personas and main user stories. Fundamentally, you learn about the real pains felt by the users and gather loads of input for what comes next. The gods are happy.
At some point, you find yourself seated at the drawing board, about to get serious.
Some Techniques to Clear Your Head
The empty canvas is not scary. Scary is all the data you gathered and that now needs to be organized into a meaningful experience. And to be meaningful, it has to be correctly structured and capture the way concepts are tied together and the cognitive processes used when performing the application’s specific tasks.
Trying to clear your head from all that you’ve learned will help you to come up with a new approach that focuses on first things first. Try taking a step back before starting your design, so that you don’t just mimic old approaches with a better look and feel or clutter the screens with all sorts of requirements.
The very first question shouldn’t be how to fit everything the users need to do into a bunch of screens, but rather what is the app for and what big problem does it solve. To make it clear, start by laying out all the concepts you’ve gathered in that kick-off meeting and user research to understand hierarchies, relationships, and flows. There are several techniques that can help you do just that.
Mind-mapping is one of those techniques. And it’s pretty much like using sunscreen: you are creating an extra layer, ideally, before going out in the sun, that prepares the ground for your screens. Mind-maps are nothing but diagrams, a bit like the one you’ve seen at the kick-off, but you’ll make sure you’re not the only one that gets it. There is a key concept, and it should relate to a key task to be performed in the software, from which derive all others. There is a set of other concepts that gravitate around the main one, but the hierarchy and scope are defined and agreed upon, avoiding skin burns and itches.
To make it fun, you can also invite your stakeholders and users for a card-sorting exercise. This can be done by writing down all of the concepts on actual cards, post-its, or an online tool such as optimalworkshop.com, and then ask people to collect them into meaningful groups. The primary goal is getting categorized and structured information from those that have to handle it on a daily basis.
Card-sorting and mind-mapping will lead to a shared and agreed-upon notion of what comes first, dissolve ambiguity and confusion, and remove the unnecessary (as much as possible) before designing around your main tasks. Better than that, both enable you to get your information architecture solidly in place.
You Ugly Little Mockup
Lo-fi stands for low-fidelity. It means that you’re drawing something that has a low degree of fidelity to how the application will actually look in the end. A low degree of detail and realism means that you start sketching and making decisions with no focus on being visually attractive or respecting branding guidelines. For now, it’s all about user experience.
What you’ve got so far is good enough to get going: business goals, user needs, and even a kind of blueprint of the application’s information architecture coming from the mind-map and the card-sorting research activities. Now let’s open your Balsamiq, Axure, Omnigraffle, or whatever tool or notebook you’re using, and start your first rough sketches.
Get your artboard ready. Some of these software tools will provide you with stencils ready to drag to your work area. Find a browser window or a phone and reshape it according to the screen resolution that the majority of your users work with. If you don’t have a clue of what that is for the web app or if you’re going to have more Android or iOS users, just visit browser stats websites and check the most common resolution, device, or both. Is there a stencil for that? No? Then just draw a rectangle and let’s go.
The first major decision on screen: how will the menu structure adhere to the complexity of the tasks at hand? Can you live with a one-level top menu, meaning that you won’t be needing a lot of menu sections and that you can use all the real-estate beneath for content? Or do you need a second level? Can it live at the top or should you change it to a side menu so that you can easily switch between sub-levels? Can you spare the space it requires?
Now, the second round of decisions: how will the screen sequence obey the natural flow of the tasks at hand? Do you need a dashboard with counters, graphs, and shortcuts that presents the users with the main things they want to know and access when opening the app? Or do you need them to follow a process using a wizard or maybe start with a list and a search that then goes to detail pages?
There’s a third round, a fourth round, and perhaps a fifth round of decisions. What matters is that you’re making them so you can address the main user stories first, those that account for the main tasks to be completed and to the main personas completing them. Be sure you’re not solving uncommon scenarios or corner cases, those are outside the scope of the first mockups. And you’re doing it all in low-fidelity, meaning you’re deciding the most of your app in a sketchy and wireframe mood.
But We’re Not Calling It a Wireframe, Are We?
Wireframes look pretty much like mockups, but mockups go one step further. They mock-up the real app, which means that we rely less on placeholders and more on data. So you shouldn’t forget to ask your stakeholders and users for seed data to include in your designs. It will inform and support your decisions, too: imagine that you have to include a customer’s list on your application.
If you know from the start that each customer will involve a name, email, and phone number, why not design the page with elements that look like business cards? If you know you’ll have to show the person’s full name, maybe that graphical representation has to be reshaped so that the long names fit. Also, self-explanatory data, such as an email address or a phone number, don’t really need labels, so there you go—another change to your design just because you have access to real data.
Now for Your Clickable Prototype
“Which screens do I draw?” you ask.
“It depends,” designers will say.
It really depends on a bunch of things. You may be designing a specific feature and, although it is a secondary functionality, you want to make sure the entire flow is there, documented in all its details and micro-interactions. Or you may be on a short-term project, like I usually am, helping companies build extraordinary apps at full speed. What makes sense in those cases is to draw the main user stories and leave the most complex scenarios solved, so that you’re building something that others can finish.
What you draw is always a story. Full app, specific feature, or just the happy path—your screens tell the user story. They log in, search for the customer name, click the email to do whatever, and go on doing what they have to do. Screen by screen, you’re simulating real usage and getting what you need for your first clickable prototype.
And what is it really? In this first moment, the prototype is composed of low-fidelity mockups in a sequence that replicates the tasks to be completed by the users in the application. You can use tools like InVision to define what your buttons and links in the mockups do to react to user interaction and really simulate an application. This exercise is useful when presenting our work to stakeholders and, more importantly, when doing usability tests with these app-look-alikes.
Fail Fast to Fail Better
When you’re showing low-fidelity mockups, just remember to explain what they are first, so you avoid questions and comments like these: “Is this final? Why is it all black and white? Where is our brand? Oh, I think it is a bit ugly.” Because they will happen if your audience is not used to seeing these kinds of things.
Also, explain why you’re doing low-fidelity. Make them see it as a first proof-of-concept, something to start testing and quickly getting the conversation going. This is not the time for cosmetic pretensions or to discuss the perfect label. This is just the setting to make collaboration possible. You didn’t go home for three months after the kick-off to prepare a beautiful design all by yourself. Instead, you came back after a couple of days with ugly screens that tell a story.
Ultimately, that is the story they want to hear. That you’re basically failing fast with your prototype to fail cheap, and failing fast to fail better.