UX-Driven Design

Why UXDD is beneficial to nearly everybody

Like many other buzzwords ending with DD for “driven design,” UXDD also is born with the declared goal of saving the world of software or, at a minimum, reducing its costs. In this regard, UXDD shares the same noble goal of DDD.

UXDD, however, doesn’t force you to switch to any significantly different way of thinking about and writing software. It doesn’t require any significant preliminary training, either. When I present UXDD principles at conferences or during classes, more often than not I’m approached by people saying that some core ideas I refer to as UXDD are just what they are doing or have been doing for years.

There’s no strict need to label the practices outlined in this chapter with a resounding new name like UX-Driven Design. Yet, a new and resounding name might help attract attention to it.

Where are the benefits of UXDD?

We write software, and we all would like to write it as effectively as possible and in a sustainable way. Software is a complex matter and an engineering project. We can’t reasonably cut down the actual costs of engineering, though this is exactly what often happens. (Smile.) If our customers perceive that software costs too much, and if we all perceive that software development is not being financed well enough, then somewhere, somehow both developers and customers are doing something wrong.

What exactly are we doing wrong?

My two cents’ worth of opinion on the matter is that the problem lies with UXDD principles. I start from the fact that all that users are concerned about is the experience and how easily they can do their work. The success of any software is determined by its ability to perform business tasks in a way that is constantly appropriate—which is just a bit of wordplay to avoid using the more popular term scalability—and convenient for the user. If the software fails at providing a satisfactory user experience, it can still be used and can still be effective, but it’s not going to be successful software.

UXDD recommends you focus on screens and storyboards first, build them as users declare to love them, and run them by the same users several times. You keep showing them to users until you get them to sign off on those screens and storyboards. I’m not simply talking about a prioritized list of intentions like “I want this” and “I want that” or “You can give me this in v2.” I’m specifically talking about wireframes and possibly animated sequences of wireframes. In this way, you show users how they’re going to use the system once it’s deployed.

This first step is not free, of course, but the cost is a fraction of developing any software at any level and that has any number of features in it. Go through screens and wireframes until you get really close to ideal user experience. Then decide whether it’s good to invest some more time and money and build some lightweight software prototypes. I consider this step optional but in large projects it can really be a lifesaver.

What next?

Once you have users’ approval for screens, you know exactly what output the system is going to produce and what input it is going to receive. The next step is simply about organizing the layers underneath the presentation to handle this data.

There’s very little in UXDD that you won’t do anyway. But for the extra cost of dealing with screens and animated wireframes, you get to write software that users might like perfectly well the first time. And you can be quite sure of that because, well, the users just signed off on that! But even if users don’t like the software the first time they see the screens or wireframe, the chances are great that the number of iterations you have to go through to fix it will be significantly reduced. What else would you call it if not “cost saving”?

Figure 3-9 shows the overall diagram of UXDD development.

FIGURE 3-9 The overall diagram of UX-Driven Design

NOTE

The sign-off step seems more essential with regard to return on investment (ROI) in a consulting scenario than it is in a corporate development scenario. However, when you write software for internal customers, it’s still about coming to a mutually satisfactory agreement with them that reduces the overall time needed to have software up and running in its final form.

MVC, MVP, MVVM, and other patterns

Short for Model-View-Controller, MVC is a pattern devised in the 1980s to originally architect the entire application. Applications of the time, though, were essentially monolithic and MVC as a general pattern totally made sense. The primary goal of MVC is to split the application into distinct pieces—the model, the view, and the controller.

The model refers to state of the application, wraps the application’s functionalities, and notifies the view of state changes. The view refers to the generation of any graphical elements displayed to the user, and it captures and handles any user gestures. The controller maps user gestures to actions on the model and selects the next view. These three actors are often referred to as the MVC triad.

The MVC pattern evolved into Model-View-Presenter (MVP) where the presenter element replaced the controller and took more responsibility, essentially summing the orchestration of tasks to the rendering of the view. In MVP, view and model are neatly separated and the presenter mediates between them.

Model-View-ViewModel (MVVM) is a much more popular name for a pattern that was originally introduced as Presentation Model. In MVVM, you have a class that incorporates both the commands and view model for the UI. A single class—the view model object—exposes properties to bind to UI visual components and methods to bind to UI events. MVVM is particularly suited to application scenarios where a powerful bidirectional data-binding mechanism exists. This is especially true for XAML-based applications and Universal Windows applications.

Don’t get me wrong: in the context of layered applications, MVC, MVP, and MVVM are all patterns for the sole presentation layer.