UX-Driven Design

Looking at user experience from an architectural perspective

Usually, the term UX refers to behavior and emotions the user goes through when she uses a product, including a software product. UX is mostly about interaction, and interaction with a computer is mostly made of visual controls. And visual controls are the interface of the system. So UI and UX are tightly related but distinct.

My point is that UX is more relevant for users than actual UI, which mostly is there to please the eye. Unlike UI, the user experience is also relevant at the architecture level. Because to give users an objectively positive experience, you might want to reconsider the order in which design steps take place and the importance assigned to the presentation layer.

UX is not UI

Some 30 years ago, graphical user interfaces (GUI) changed the rules, and both developers and users learned the importance of visual design. Up until a few years ago, and surely before the advent of smartphones and tablets, well-designed visual interfaces were sufficient to ensure a good experience to users of software applications. The road ahead seems to indicate that a good UI is no longer sufficient for delivering a well-designed presentation layer.

To stay on the cutting edge, we have to replace UI with UX.

Defining wireframes and other similar terms

When it comes to UI and UX, we hear and use a few terms constantly, not always using each with its precise meaning. Sometimes what we actually mean is clear from the context, yet terms like wireframe and mockup refer to slightly and subtly different things. From a ubiquitous language perspective, let me clarify what is commonly intended with terms like sketch, wireframe, and mockup:

• Sketch A sketch is typically a freehand drawing done primarily to jot down ideas for a user interface. Overall, it’s a necessary step for every designer to do in order to translate the original idea into a graphical user interface.
• Wireframe A wireframe is a more precise type of sketch. It contains additional information and is focused on layout, navigation, and content to present. A wireframe is often related to other wireframes to form a storyboard. In a wireframe, you won’t find many details about the actual aesthetics of the final product.
• Mockup A mockup is a wireframe with a specific look and feel. A mockup offers a preview of the final product with a clear idea of layout, content organization, navigation, and aesthetics.

These terms are sometimes used interchangeably. Even though interchangeable use might even be acceptable, I think it’s important to know what each term means specifically.

Defining prototypes and other similar terms

After elicitation, the first required synchronization that must be arranged between development teams and stakeholders involves the presentation. If the complexity of the domain logic is not really high and if tasks are relatively trivial to figure out and implement, a sign-off at the level of presentation might be enough. In other cases, a second synchronization step might be required before going into the final acceptance procedure.

When it comes to needing a second synchronization, a few other terms are often used interchangeably. A misunderstanding about whether you’re expected to provide a prototype or proof of concept (PoC) might be much more expensive than any misunderstanding about wireframes or mockups. Let me clarify the terms, then:

• Proof of concept A proof of concept is essentially a small piece of code created to test the feasibility of an idea and to verify that some theoretical points have the potential of being or becoming a useful production feature. Sometimes, a PoC is also done to put a new technology or framework through its paces.
• Prototype A prototype is a partially fake system that tries to simulate the full system. Like a PoC, it is done to test the viability or usefulness of a system. It seems to behave like the full system except that most features are partially implemented or use canned data or hard-coded logic. The point is to show how the whole thing will work. Compared to a PoC, a prototype is a lot more sophisticated and complex, though it might cost a fraction of the full system.
• Pilot A pilot is a full production system tested only against a subset of the general intended audience and possibly working on a subset of the full data set. A pilot can easily be the full application running on a staging system, database or both.

Sometimes, any of these terms is replaced by a more generic (as well as popular) term: demo. Proofs of concept, prototypes, and pilots are all demos. When the customer asks for a demo, try to have them be more—a lot more—specific about they want. And demos, usually, are not effortless.

Experience is about interaction

If UX analysis is the central point of modern presentation layers, the usability review is the central point of UX analysis. Here’s a quick true story I often tell during conference talks and classes. A customer asked for a tool to cherry-pick tweets based on hashtags. They wanted to see a list of tweets, click on those of interest, and have those saved to a database table. We even worked out a wireframe for the main user interface of the webpage. (See Figure 3-5. By the way, the wireframe in the figure was created with Balsamiq.)

FIGURE 3-5 A sample wireframe for a sample page to cherry-pick tweets

After the first test, everyone was happy and the application was seen as just perfect. After a few days of intense use, though, it started looking quite a bit less compelling. To cut a long story short, two key features were missing that apparently everybody ruled out because they were too advanced for a first run of the app. One was the ability to select and hide unwanted tweets so that picking really interesting tweets became an easier task. The other missing feature was the ability to hide tweets in the stream that had been already picked.

The first lesson I learned from this is that only by looking at users using the application can you reliably say whether the UX you offer is good or not. The second lesson is that the word requirements is less and less expressive of what users and developers need to talk about. Gathering requirements is only the starting point of a far longer workflow that involves building tasks and business processes.

Finally, the third lesson relates to the UX prioritization of features that don’t work. A given feature is either useful or not. And if it is determined to be useful, it must be planned from the beginning. Otherwise, you’ll be doing the work—any work—at least twice.

Explaining UXDD in three steps

In essence, UXDD is a top-down, three-step design workflow. First, you work out screens and storyboards to get approval and feedback from users about the effectiveness of the interface and underlying processes. Second, based on screens, you formalize what comes in and out of those screens and build application layer endpoints that perfectly match that expected data flow.

In other words, the first step lets you discover shape and type of the pegs you’re going to have, while the second step ensures you use compatible holes as well. What about the third step? It’s about building the back end of the system in a way that is completely transparent to the front end and its pegs and application layer holes. (See Figure 3-6.)

FIGURE 3-6 The three steps of UXDD

Understanding the importance of screens and storyboards

One of the most important things I’ve learned from UX experts is that requirements are better when they’re actively generated through discussion than when they’re passively gathered through interviews. Years of real-world experience taught many of us that being too passive during elicitation of feedback from stakeholders leads users to deprioritize a feature so that they can have the software as soon as possible. Even though users might make that decision, it doesn’t stop them from complaining that the system is barely usable when they finally get it.

Figure 3-7 presents an example we can use as a starting point for discussion, and you might spot the weak points in it at first glance. Despite the shortcomings of the wireframe shown, by generating this type of outline you enable users to let you know whether you missed something important—say, a particular aggregation of data. The user can tell you right away so that you have plenty of time to organize the back end to make that particular data easier to grab.

FIGURE 3-7 A sample wireframe to give users a clear idea of the screen being planned

Showing screens and storyboards to users as early as possible, iteratively running them later, and incorporating feedback are critical steps you need to perform to move from sketches to wireframes, and even mockups. You might think this is more or less already done in many projects, but is it more or is it less? I think it’s mostly less. And usually the missing part is the storyboards.

The experience of a user results from using the UI tools to accomplish a task. Very few tasks are entirely accomplished through a single screen. You’ll likely find that just looking at the wireframe of a screen might not provide you with enough information to spot possible bottlenecks in the process implementation. Concatenating screens in a storyboard is a better idea. The problem you’ll encounter is the lack of tools available for easily and effectively connecting screens to build storyboards.

Table 3-1 presents a list of some tools available today.

TABLE 3-1 Short list of tools for UX development

Screens are, at best, HTML or just XML content rendered in some graphical way. In any case, they are purely static content with no life and no action in them. You can use some of the tools in Table 3-1, most notably Indigo Studio and UXPin, to turn wireframes into true storyboards to demonstrate the flow of UI screens. Sometimes, this is only the first step, though.

Turning views into prototypes

Keep in mind that even the best and most widely agreed-upon user interface might turn bad when used extensively. When in doubt, you can go with a working software prototype and you might even be able to film users while they’re using the prototype to get a realistic indication of their actual experience when using your software.

NOTE

Regardless of tiers, layers, frameworks, databases, and technologies, for end users the only thing that matters about a software system is the user interface—specifically, the user experience and perceived speed of the application.

In terms of concrete technologies, a prototype can be anything that serves the purpose of gathering early and informative feedback. It can be a set of HTML pages as well as a XAML-based application. A prototype consists only of the presentation layer and uses canned data or just a fake back end to simulate some behavior. Depending on the level of fidelity you want to offer, creating wireframes and prototypes for an agreed-upon set of sketches is usually takes only a few days of work. Not a big effort, in the end.

The hardest part of turning views into prototypes is probably not creating the prototypes themselves, but making it clear to the customer that what they’re seeing is only a prototype and nowhere near to being even halfway complete.

Tasks and workflows

Suppose that at some point the customer decides they like the prototype and gives you the go-ahead to build the application. The more that you have validated and accurately created the screens and related storyboard to respond to realistic needs, the less (re)work you’ll need to do later. This is the key point that makes UXDD financially worthwhile. If you’re looking for where the return on any UXDD investment might lie, well, this is the place.

Having the screens ironed out brings a lot benefits, and one in particular. You know exactly what the back end of the application has to produce.

Each screen you have can be easily mapped to an outbound class, which becomes the input of the application layer and, in turn, the entry point in the back end of the system. The application layer forwards the input to the back end, and that input proceeds down the stack. Any calculated response is carried up the stack to the application layer, packaged in a view model object, and returned to the presentation.

Now look back at Figure 3-6. What I called pegs and holes in the figure are just classes going in and out of the presentation as they are passed to, and returned by, application-layer methods. Application-layer methods are responsible for orchestrating the tasks behind use-cases.

The rest of the back end

In terms of the actual code you would write within an ASP.NET MVC application, the essence of UXDD is summarized in the following few lines of a controller method:

public class SomeController
{
   private ApplicationLayerService _service = new ApplicationLayerService();

   public ActionResult SomeTask(InputModel input)
   {
        var model = _service.GetActionViewModel(input);
        return View(model);
   }
}

In ASP.NET MVC, any controller is still part of the presentation layer. More precisely, it is the repository of any presentation logic you might need to have. Any actionable UI elements end up calling into one of the controllers, and the invoked controller forwards the call and input data to the application layer. The _service variable in the code snippet is an instance of the segment of the application layer associated with a given controller. The service has one method for each action in the UI that can trigger the controller. The method will receive an input model and return a view model. The input model is a class that contains all data that flows out of the screen. The view model is a class that gathers all data that fills out the screen when it’s rendered back to the user.

The link between the controller and the application-layer helper class is then more elegantly established via any form of dependency injection, including the simplest of all, which is shown in the following lines of code:

public class SomeController
{
   private IApplicationLayerService _service;

   public SomeController(IApplicationLayerService service)
   {
      _service = service;
   }
   public SomeController() : this(new ApplicationLayerService())
   {
   }

   public ActionResult SomeTask(InputModel input)
   {
        var model = _service.GetActionViewModel(input);
        return View(model);
   }
}

Once you have this code architecture in place, the rest of the system that lies underneath the application layer is just an implementation detail, even though it’s the segment of the system that fully contains the entire domain logic and all the business rules of the domain. The idea depicted in Figure 3-8 might seem quite minimalistic, but it’s true.

FIGURE 3-8 The overall layout of a system architected following UXDD principles