November 2015

Volume 30 Number 12

Cutting Edge - Better Architecture with UX-Driven Design

By Dino Esposito | November 2015

The design and engineering of any software system begins with a well-known step: collecting requirements from users. This usually involves several meetings and interviews with customers and domain experts. Following the last meeting, nearly everyone involved in the project should believe that all details of the system have been ironed out and development can safely start. No one should doubt that the final product will be different from what was explained and understood. Customers should be happy and architects should believe they know exactly what to do.

However, in practice, experience shows that agreeing on abstract requirements doesn’t guarantee successful implementation. When customers actually see the prototype, more often than not they just don’t like it. No matter all the meetings and discussions, it seems that customers and developers form distinct ideas of the final product. Developers receive requirements and build the software around them. But the final product often misses the mark of what users want.

I think developers often tend to aim for functional completeness and don’t focus enough on the business processes end users need for the system to perform. So while functional aspects of business processes are captured, the overall implementation is rarely as polished and smooth as expected. In this article, I’ll present a design approach that can improve the chances for architects to build the right thing the first time. I call this approach UX-driven design, or UXDD for short.

The Apple That Fell on My Head

You may remember the apocryphal story of the apple that fell on Sir Isaac Newton’s head, leading him to formulate the Universal Law of Gravitation. Recently, an apple fell on my head and the message I received was that paying due attention to users’ expectations and real processes sometimes requires building different things. That is, it takes more than just a functional analysis.

A customer asked to build a quick-and-easy—so they said—Web application to support the competitive bracket for a tennis tournament. There was just one user story. The operator indicated the name of the player and the related position in the draw and the operator expected the system to expose some XML feed that reflected the current state of the draw. My developer’s mindset immediately created the vision of a database table to hold the data. Next, I had the vision of some quick HTML form with two text boxes: one to indicate the player’s name, and one for the position in the draw. Interestingly, when the discussion ended, the customer was certain he had a tool to enter players and positions and had some XML to support it. But when the developer—me—delivered just that and the customer tested it in the simulation of a live draw, it didn’t work. The customer actually wanted something a lot more complex. A look at Figure 1 shows different perspectives between developers and customers. The background screen is what the customer desires and the representation of the real process; the yellow screen with black outline in overlay is the low-cost solution, as quick as it is inappropriate.

Figure 1 The Difference Between What’s Wanted and What’s Understood

At the end of the day, the UX is much more than just gestures and graphics, it’s the experience that users go through when they interact with your software. To design an effective UX, as an architect and developer you should focus more on tasks and business processes than data models and storage. To understand tasks, you need to learn more about the domain, the users and how those users operate in that domain. UXDD addresses this, but it isn’t simply a generic recommendation to use wireframes and mockups. I used that in a simple scenario and it didn’t work because the customer—in his mind—thought the software was too simple and not worth the effort of fully engineering the real process. As an architect, I didn’t get the right message from the customer about the importance of the task. Never choose a low-cost solution; choose an effective solution. I have to admit that the original solution I proposed—the low-cost solution—was just impossible to use in a realistic situation. My fault was to entirely and blindly trust the customer’s analysis and not learn more about the actual business processes.

UXDD is a set of architectural prescriptions that can minimize the risk of missing important business points that relate to tasks and the UI. Interestingly, UXDD can change some of the consolidated practices of today’s development and software engineering.

Top-Down Design

From a functional perspective, you can successfully build a working system regardless of whether you start the design effort from the bottom (say, from the persistence model) or the top (say, from presentation layer and view model). From a UX perspective, you can only be successful if you start designing from presentation and view models and build everything else, including the back-end stack, from there.

Many of us learned professionally that once you had a persistence model made of entities and relationships, built from user requirements, you were pretty much done. That model would be the model of the entire system used throughout the entire stack and only occasionally partnered by a few UI-specific data-transfer objects. In this context, designing and building of the system take place in a bottom-up manner and the presentation layer inevitably reflects the persistence-centric vision of the data model. We often call this create, read, update, delete (CRUD) and we often reduce any system to CRUD with just a bit more sophisticated business logic. In doing so, we pay little attention to the presentation layer. Sometimes a UI too close to the data model is good for users; sometimes it is not. The latter scenario gives spark to additional negotiation once the first working prototype has been delivered. You first devise a system from the ground up to find out, at some point, that the outermost layer has to change to reflect different user processes. This is in no way different from trying to fit square pegs into round holes. Because of this, I see it as the biggest challenge of many software projects.

What can we do to improve the process? I believe the answer is to move back to a top-down design approach that starts from the presentation layer and makes any further decision and implementation detail descend from presentation needs. To make it effective, a sort of sprint zero, or waterfall preliminary step, is necessary to ensure that a deep understanding of the UX is captured before moving to build the back end of the system.

The UX-Driven Methodology

I learned from UX experts that requirements are better actively generated through evidence-based discussion than passively infer­red via interviews. Sometimes architects and analysts tend to stay too passive during elicitation and this causes users to lower the priority of any features in order to have the software ready as soon as possible. Then they complain the system is barely usable when they finally get it. At the same time, staying too passive in the elicitation with the excuse that “this is what the customer wants” doesn’t help make sense of the “thing” we’re going to build. Today, we write software to mirror pieces of the real world rather than to model what we’ve been told the customer wants. Missing on structural aspects of the business is a deadly and costly sin.

It’s a common practice to use wireframes to come to an agreement about the expected UI. Iteratively running wireframes by users to solicit feedback works only to a small extent. Wireframes are great, but of limited value without storyboards.

Very few tasks are entirely accomplished through a single screen that you can summarize effectively to a wireframe. Just looking into the wireframe of a screen may not be enough to spot possible bottle­necks of the process implementation. Concatenating screens in a storyboard is a much better idea. In this regard, the biggest challenge I see is finding the tools to build storyboards. These tools are a rapidly growing marketplace. Figure 2 lists a few tools that can help you quickly prototype the presentation layer of applications in a way that gives users a concrete idea of the process being designed.

Figure 2 Tools for Quick and Effective UI Prototyping

In addition, recent versions of Microsoft Visio and PowerPoint (especially in combination with Visual Studio Ultimate) also feature some prototyping capabilities. All tools listed in Figure 2 offer a rich platform to create wireframes and in some cases offer the ability to create clickable mockups, and turn them into functional prototypes.

The most advanced of these tools provide early feedback and, more important, let you involve customers earlier in the design process and before writing a single line of code. If you find you missed important presentation points when half the back end is done, you either throw it away or adjust things.

At the same time, simply outsourcing the presentation layer to a team of UX experts isn’t enough. The presentation layer today is the most important part of a system and must result from the combined effort of solution architects, UX architects and customers. This must be the first step and ideally you move on only when the customer signs off on the presentation. In terms of methodology, it’s acceptable to take a waterfall slant and complete the entire presentation design before coding, and be more agile and add the presentation analysis as a step in the sprint, as shown in Figure 3.

Figure 3 The Three Steps of Architectural UX-Driven Design

Designing the Rest of the Solution

Once you’ve finalized the presentation layer for the entire solution or just the current sprint, you have a collection of screens—for example, forms—with a well-defined data flow (it’s clear what comes in and out of each form). Architecturally speaking, this means you know the input model of each action and the view model necessary to fill out the form or generate the expected response. The presentation layer connects to the back end via an intermediate service layer that conceptually matches the Service Layer pattern as defined by Martin Fowler (bit.ly/1JnFk8i), as well as the appli­cation layer in the layered architecture of Domain-Driven Design. It is the logical segment of the system where you implement the use cases and any orchestration of tasks they require. The application layer is the topmost part of the back end and dialogs directly with the presentation layer. The application layer is made of direct endpoints for each of the actions that can be triggered by the presentation. These endpoints receive and return just the input and view models resulting from wireframes.

Is this approach really effective? You bet. If your wireframe analysis is thorough and correct, you’re implementing just the processes customers want, and it’s right the first time. You cut down significantly the chances of renegotiating changes after you deploy the first release or demo. This saves time and, subsequently, money. As shown in Figure 4, developers indicate this as emblematic of how users look at software. And UXDD leads to designing software in that way.

Figure 4 Essence of Software from the User’s Perspective

Wrapping Up

Compared to how we design software today—from the data model up—UXDD assigns more importance to tasks and presentation than data models. Not that data modeling and persistence are unimportant, but their roles are functional to tasks rather than the other way around. Like it or not, this is closer to what the real world demands today. UXDD is about methodology rather than technology or patterns. UXDD doesn’t deny nor mandate any technology or pattern, though it goes very well together with CQRS and Event Sourcing. If you’re not satisfied with the actual process of building applications, use the UXDD approach as a form of lateral thinking.

Dino Esposito is 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