Don’t Gamble with UX—Use Wireframes

By Dino Esposito | January 2016

Dino Esposito Paraphrasing immortal scientist Albert Einstein, I dare say, I don’t know what the future has in store for software architecture, but if any changes are upcoming, one would certainly be embracing a top-down methodology in design of layers. Short for UX-driven design, UXDD is an approach that primarily promotes the use of wireframes and storyboards as the starting point of software architecture. In UXDD, the outcome of the elicitation process isn’t a dry-and-flat collection of requirements, but instead an alive-and-kicking collection of sketches clearly indicating the way users love to work. And not surprisingly, the way users love to work is the plain software representation of real business processes. As I see things, technology is losing the central role in software architecture it had for decades. Today it takes more the architect’s ability to combine available technologies and products to achieve a specific set of goals, taking into account existing investments in specific technologies, legacy platforms, skills and budgets.

Sounds like a foregone thought? Well, it probably is. This vision of software is nothing new, but it’s also a vision of software that has never become mainstream.

Defining Wireframes

I’ve been using the word “wireframe” and also use it interchangeably with the word “sketch.” Let me clarify and set in stone the difference, from a UXDD perspective, between wireframes and “mockups.” Here are some definitions for terms in UXDD:

A sketch is a freehand drawing primarily done to jot down and capture a flashing idea. Ideal surface to persist a sketch is paper, including paper napkins from cafeterias. A sketch may represent the top-level skeleton of an architecture, but, more likely, it captures the idea of an interaction between the user and the system.
A wireframe is a more precise and accurate type of sketch as it adds information about the layout, navigation logic and details about the organization of the content. At the same time, a wireframe is agnostic of any UI details such as colors, graphics, shadows and fonts.
When a wireframe is extended to incorporate graphical skins, then it becomes a mockup.

There’s a key psychological difference between mockups and wireframes. When you show users mockups of an application, the attention is inevitably captured by graphical aspects such as background images, colors and style. Rarely, the users’ attention is caught by organization of the information and how the same information is navigated and laid out. Wireframes are kind of scanty mockups entirely devoid of graphical content. Wireframes can be drawn manually or through generic drawing tools such as PowerPoint, Visio or, perhaps, Balsamiq. More specialized tools, however, are appearing to link wireframes together, thus forming storyboards to give users a concrete idea of the final experience.

Why Wireframes Are Cost-Effective

Developers generally agree that using wireframes to form an idea of the presentation layer before even planning the back end is greatly beneficial. For many years, folks in this industry cultivated the idea that architecting software is much the same as architecting buildings. The Agile movement then emerged to combat the idea that we needed a big up-front and closed design before writing code. Not that Agile really means no design and no analysis—quite the reverse, I’d say—but Agile probably failed addressing the core issue of software development. What is the ultimate goal of software? Are we simply writing software just to store and handle data? Instead, aren’t we writing software primarily to have users perform business tasks more efficiently and more quickly? In the latter scenario, of growing relevance today, the presentation layer is all that matters. Agility in this case means iterating and collaborating with users to define an acceptable set of wireframes and storyboards rather than information sufficient to create a good persistence model.

Yet it’s not uncommon for software managers to see any time spent on wireframes as a useless cost that brings no deliverables and no direct money. As such, it can be avoided to have the team focus on actual software artifacts. The analogy between software and civil engineering is a longtime analogy and it’s useful to recall it now to say the following: When you want to build a garage (not to mention more sophisticated types of buildings), are you going to explain what you want or are you just expecting bricklayers to put bricks together and then complain when they deliver something you never wanted or asked for?

Creating and validating wireframes is an extra task to manage and an extra cost. However, it’s one thing to tweak a wireframe file that jots down a visual screen; it’s quite another to tweak a multi-layered system made of thousands of lines of code. By adopting wireframes and UXDD, you definitely spend more time before any single line of code is written, but you save a lot more time once the first sprint is delivered. And you save even more time when the system is halfway and its effects and benefits can be better experienced and evaluated. With UXDD, you go much closer than ever to the dream of delivering the project right away. What you save in subsequent sprints and remakes is much more than you spend up front with wireframes.

How to Produce Wireframes

At the foundation of UXDD and wireframes lies the idea that software should not be created to model the business domain. Rather, it should be written to mirror the business domain. This shift of perspective has relevant spin-offs in the patterns we use to devise the system. In particular, it gives the preliminary analysis a strongly task-oriented focus and blurs the relevance of modeling. This aspect scares most managers because it sounds like a weird thing to do that nobody did for decades. The expected outcome of interviews with customers has long been information to create an all-encompassing data model to read and update the state of the system. As complexity of domains and applications grows, this approach is less and less effective and manageable.

Classic individual and group interviews are still acceptable, but more desirable if aimed at understanding the relevant events to handle in the system and the tasks and circumstances that cause them. Event storming is an emerging methodology to capture wireframes and to lay out the presentation layer quickly and effectively. You can find a brief introduction to the practice of event storming, written by the very own author and master, at bit.ly/1N25MJl. In a nutshell, this is a method to explore complex business domains in a way that is both quick and straight to the point. It has a strong task-oriented flavor and lets you learn about the domain and, especially, the tasks to implement. Better yet, it lets you listen to what users really need to do and the actual flow of actions, triggers, and events you need to mirror and reflect through software.

How to Validate Wireframes

This is a key point: Without an explicit signoff and acceptance from the customer on the wireframe creation, any effort is lost because it doesn’t guarantee a final ideal UX. In UXDD, you must have approval for wireframes before you start writing any serious amount of code.

Having customers look at wireframes is only the first step, though. Effective validation of wireframes typically requires more effort. You must show users what it means to perform a task and the resulting sequence of steps and screens that completes any given task. Storyboard is the term used to refer to the concatenation of multiple wireframes to compose a business task. If the content of wireframes is accurate enough, playing a storyboard is really close to testing a software-made prototype, except that the cost of a storyboard is a fraction of the cost of a software prototype and can be fixed nearly instantaneously. In more advanced scenarios, it might even be reasonable for film users to use film while playing storyboards. Their body language may reveal a lot, as well as the average time that each operation takes. An accurate validation process might also include elements of cognitive analysis such as Test-Operate-Test-Exit (TOTE). As shown in Figure 1, TOTE is essentially an iterative trial-and-error session aimed at progressively improving the satisfaction of users and achievement of shared goals.

Figure 1 TOTE Flowchart from Cognitive Analysis Adapted to UX Analysis

There’s no magic behind TOTE—it’s plain common sense, but as foregone as it sounds, it works effectively. The more you apply cognitive analysis and the more you spend up front, the more you save later. For those who do so, the balance is largely positive. Overall, it can’t be worse than when you start coding based on assumed models and then figure out the wrong artifacts were delivered.

An Exemplary Story

The story that follows is real. After an endless series of meetings, both the team and the customer were sure that all aspects of the Web site to build had been properly discussed and analyzed. Every single aspect of the system was allegedly clarified and written in stone; no bad surprises were in order. The honeymoon lasted for just a couple of days until the developer working on the login page raised the first exception. Is login going to happen only through membership? Would there be no social authentication? The answer was a resounding “No, the customer didn’t mention that.” The login was delivered without Facebook and Twitter authentication. Guess what? Social logins were for the customer a strict requirement; it was so strict and obvious that it wasn’t even mentioned. Social logins were extra work and knowing that beforehand would have likely oriented the implementation of the membership system differently. At the same time, it was clear to everybody within the team that if anybody showed users a sketch of the login page the lack of the social button would have been noted and reported, as shown in Figure 2.

Figure 2 Wireframes for Social Login that Nobody Created

From Wireframes to Prototypes

The more you feel engaged by the idea of using cognitive analysis in the elicitation process, the more you might be looking for specific tools that help with creating wireframes and storyboards. Wireframes are relatively easy and quick to create, but the same can’t be said for storyboards. It should be noted that the simple concatenation of a few wireframes may not be enough for certain users and certain business scenarios. Sometimes, some code must be written to proof concepts. Some terminology applies here that is useful to clarify. A proof-of-concept is typically a small exercise to verify an assumption or play with a new technology in a given context. I like to call a proof-of-concept a domain-specific “hello world.” A prototype instead is a fake system that attempts to simulate the full system and is done to test the viability or even the usefulness of a system. This is what you need to have when storyboards prove not to be enough. Finally, another term that is often used interchangeably while having its own strict definition is “pilot.” A pilot is a full production system only tested against a subset of the general intended audience or data set.

Wrapping Up

To be effective, wireframes should be the currency to exchange between stakeholders, just at a different abstraction level than the domain-drive design ubiquitous language. Both ubiquitous language and wireframes aim at simplifying the conversation and reducing the risk of misunderstanding, misrepresentation of data, and wrong assumptions because of lack of information and guidance.

Ubiquitous language and wireframes are not methods that can magically turn ideas into running code. Far less ambitiously, the point of both is to find a sequence of concrete steps that can reduce the cost of writing software close to expected budget and deadlines.

Next month I’ll take this further and discuss the (deep) architectural implications of using wireframes.

Dino Espositois the co-author of “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2014) and “Programming ASP.NET MVC 5” (Microsoft Press, 2014). A technical evangelist for the Microsoft .NET Framework and Android platforms at JetBrains and frequent speaker at industry events worldwide, Esposito shares his vision of software at software2cents.wordpress.com and on Twitter: @despos.

Thanks to the following technical expert for reviewing this article: Jon Arne Saeteras

[Cutting Edge]