The Cost of Skipping Wireframes
‘We don’t need wireframes.’
Why make a plainer, black and white version of your app if you can make a colored, good looking one right away? Why follow the ‘process’ when you can get the ‘result’ anyways. Sounds like a valid argument. But unfortunately, it is not true.
We recently wrapped up a project. There was a fair bit of firefighting involved towards the end. And we all agree, most of the issues that seemed to crop up were due to lack of wireframes in the project. I won’t go into why the wireframes were skipped, but I will tell you how it affected the project.
Issue 1: Incomplete taskflows
What Happened:
We ended up with quite a few ‘screens’ but not enough ‘flows’. For example, we had a single ‘settings’ page. But there were no pages showing what would happen when a certain component of that page was tapped on. And this issue cropped up over and over again, for a lot many pages such as — user profile, help pages, history etc. Flows which fell outside the ‘core’ function of the app seemed to suffer the most.
Why It Happened:
Diving into finished design at an early stage pushes the design team to focus on granular information (colors, icons, fonts) rather than the overarching flows. You are pretty much making up the flows on-the-fly, so you are very likely to do a poor job of it.
Issue 2: Lack of Oversight
What Happened:
When we skipped the wireframes, we inadvertently skipped thinking about different device sizes, error states, blank states or different scenarios of use. ‘What would the profile page of a user who is not logged-in look like?’ ‘Is our primary CTA still visible of a smaller device?’ ‘What should we show when we can’t show the information the user asked for?’
Why It Happened:
In the UX world, we often talk about ‘reducing the users cognitive load’. Cognitive load is the information the user is trying to hold in their mind while simultaneously trying to process other information. By reducing the cognitive load, we help users make decisions with greater accuracy and efficiency.
The splitting up of the interface design process into its different steps is an act of reducing the designer’s cognitive load. The designer is then able to work towards a single objective (or more accurately, a smaller subset of related objectives) at a time. A narrower focus results in more accurate and comprehensive results. When forced to think of everything at the same time, you are very likely to miss out on somethings.
Issue 3: UX Writing. What’s that?
What Happened:
When the flimsy film of ‘Lorem Ipsum’, dummy texts and dummy images came off, we realized a lot of work still needed to be done. Lots of buttons read ‘Ok’, ‘Done’, ‘Cancel’. The app looked pretty, but it was doing a poor job of communicating.
Why It Happened:
Like I mentioned in issue 2, it is difficult for a designer to focus on all aspects of a design at the same time. A designer who is focusing on how something looks, is less likely to be able to focus on the right UX copy.
The point I am trying to make with all of the 3 issues I have mentioned above is illustrated in this famous video (Please watch it again even if you have seen it earlier :)):
Missed opportunities
Apart from the issues mentioned above, there were other missed opportunities too. Wireframes help teams to plan and collaborate.
Wireframes can be made (and updated or disposed off) much quicker as compared to finished screens and that is the best thing about them.
Wireframes can be shared with the other teams who can study them and get a sense of the work that will be expected of them. They can identify and highlight some issues or problem areas early on. The design, development and business teams can then collectively decide if a design needs to be updated or if the development team needs to conduct some research and identify solutions. The business team too can also contribute to this discussion — highlighting which components are in line with the direction the business wants to take, which components are better left-out because their expense (monetary or time-wise) outweighs their benefits etc.
You can argue that teams can also collaborate over finished looking screens. Theoretically yes, but the collaboration may be inefficient. Firstly, finished screens take longer to make. So you won’t be able to collaborate until your screens are ready. Secondly, discussion will often take the route of ‘this icon looks strange here’, ‘what should the color of this button be’. Again, it will be hard to retain the team’s focus on flows rather than visual elements. Thirdly, your team may feel intimidated to collaborate. Your team members maybe afraid of ‘ruining’ your pretty screens by drawing over them. Or, your designs may benefit (but in reality suffer) from the Halo effect. A design that looks good may be deemed to work well too. It makes sense to use this effect to our advantage while presenting things to our end-users. But while reviewing our own work it is better to do a thorough job of reviewing devoid of external influences.
Skipping wireframes is a bit like driving and looking at a paper map at the same time. Once in a while you may get by without a scratch, but you are very likely to make errors, take inefficient routes, not enjoy yourself, and take longer to reach where you intended to go.
