UX, Then Architecture, Then Tools

Imagine you are building your dream house. Would you trust a general contractor who talks like this?

First, we’re going to pick out the material for the kitchen counter and the glass for the windows. Let’s just guess the amounts of each to buy for now.

Then we’ve got to buy some of that new concrete everyone’s been talking about. I suppose a truckload will do it for now, but we could always order more later. I just can’t wait to try it out!

After putting the beams in place we should decide how many floors the house should have. And right at the end we should decide what style the house will be. Sometime before you move in we should get planning permission, and I’ll probably contact an architect for some drawings after you’ve settled in.

It sounds ludicrous because there’s a well-established method for building houses, and it’s based on common sense. You start with a vision, get a set of plans, pour a foundation, build the framework, fill in the internal stuff, and finally finish all the little details.

Putting any step out of order would cause complete chaos. Finishing the walls before the electrical would mean you’d have to punch holes in all your walls in order to run wires around the house. Cleaning it before it is completely finished would be a wasted effort given the amount of dust builders cause while they work.

However many coders build their systems backwards. They become enamored with the latest whizz-bang framework or charmed by the reportedly speedy performance of the newest database. And they lead their thinking with those choices as they build new features, whether those technologies are appropriate or not.

More importantly, using a technology-first design typically means that the user experience (UX) will be left until last. And if you put your users last in your order of priorities, it will unfortunately be very evident in your system’s lack of usability.

UX First

The first order of business in application design is deciding what its users will experience. This should be a high-level vision sketched out on paper or in simple digital mockups, and it should express the flow of the system from the user’s perspective.

It doesn’t matter if you’re building a web application for senior citizens or a system-level tool for serious computing nerds. The UX must be designed first.

Type of System

Your First Thought Should NOT Be…

Your First Thought SHOULD Be…

Online music player “I’m going to design the database schema!” “Let’s design the UX”
Social media plugin “Let me start hacking around with some online social media APIs!” “Let’s design the UX”
Multiplayer Game “SuperFastDB is apparently really scalable, I’ll start testing it today!” “Let’s design the UX”
Virus Checker “I’ve been dying to write a new virus scanning algorithm, so I’m jumping right into that!” “Let’s design the UX”
GPS Device “I’m going to research the latest in OLED technology right away!” “Let’s design the UX”

Then Comes The Architecture

Once the UX has been designed and the vision of the system has been defined, an architecture should be laid out to make sure that the code that eventually gets written will actually meet the needs of the users. The choices made in the UX design radically shape and inform a system’s architecture.

A good UX design will cater for less obvious things that might be part of the overall user experience. A well-written specification might include requirements such as “the overall load time for page loads must be less than 200 msec” because the designers know the consequences of slow page load speeds. It might also call for close-to-zero downtime, so the architecture might end up requiring a multi-datacenter deployment.

Last But Not Least, The Tools

Now it’s finally playtime! Once the UX has been defined and the architecture has been laid out, the process of picking the right technologies, frameworks and libraries can begin. The crucial point is that now the tools are being chosen with the UX and architecture in mind, so any tool that doesn’t fulfill the needs of either can be quickly disregarded.

This Does Not Mean “Waterfall”

If you think that this design sequence requires an outdated Waterfall-like approach to accommodate it, think again! This is completely appropriate for Agile development. The implementation of a whole new product, an epic or even a single user story should follow the UX -> architecture -> tools sequence. When beginning the development of a product or epic, spikes should be used to design the UX and the architecture. And individual user stories should include enough details for the engineer to know what the UX for that story should be once it is fully implemented, and the engineer should also estimate enough points to cater for architectural planning to be done once work on that story begins.

Tools are great fun to research and to experiment with. Programmers love discovering new ones and finding “The Next Big Thing” in the framework jungle, and having lots of tools at your disposal is wonderful when the time comes to build a system that satisfies the UX and the architecture. Just don’t begin the entire design process with them. So remember: UX first, then architecture, then tools.

9 thoughts on “UX, Then Architecture, Then Tools

  1. Agree in general, but ðere is a reaſon ƿe are often are forced to diſcuß tools or architecture beforehands: it is becauſe ƿe arrive at a ſituation ƿhere inadequate tools ſuch as MS Ƿindoƿs or MySQL are already beiŋ decided upon.

  2. Terrible advice and flawed analogy. Designing UX first is like “OK, we’ll have roof build of gold and platinum. I have no idea how we’re going to build the wall that will support all these sparkles, but I promise I’ll figure something out. Look, sparkles! So shiny.” and then you’ll end with gold roof and concrete walls hundreds meters wide. That’s what comes from UX first. Complete waste of time, energy and failure.

    1. If the business decides that a house with a shiny roof is what’s needed to compete in the marketplace, then what’s the problem? That’s a vision for a new product, and the developers will have the responsibility of creating an architecture that can support it and then use the right tools to then build it.

      The developers can (and should) negotiate with the product owners at the start of the process if the vision for the product is totally removed from reality and would lead to a terrible product. But at least both the business and the technical sides had their input into the process at the right time: the start.

  3. Form over function.
    Doesn’t sound like a good way to build robust software. I agree that UX is important, but data model should come first in most cases.
    (Do own a Mac?)

    1. A piece of software has to ultimately meet the requirements. If you haven’t adequately defined them, no amount of form is going to make your software effective.

      A common mistake is to think that UX refers to the UI. UX actually lays down what the customer needs and expects, which is what you need to base your code around.

  4. Interesting read – thanks.

    IMHO, UX and the backend should be to a large degree separate. For example, it’s the responsibility of the database to store the data in the most effective way – it shouldn’t be affected by how the UX will work. The decision to use traditional (web-traditional) MVC or some sexy client-side tech should not affect whether you want a RDB, a No-SQL DB, a graph DB etc – the data should be the only thing affecting this decision.

    Saying that, I agree that the UX is probably the bit of the application that in reality will make it succeed or fail. Scaling is essential, but you can scale badly (eg. Twitter Fail Whale) but if your UX is clean and works, then you’ll probably get through it. If you choose the wrong DB you can always change it (a hassle though it might be), but if no-one can work out how to use your app, then what’s the point. So in that degree, I agree with your premise.

    In a tiny team, then work on the UX together then work on the backend – great. But if you have a bigger team, then I don’t see any real need to wait for the UX to be designed before the DB guys or the API guys get on with making stuff.

  5. There’s one flaw with your analogy. The laws of physics dictate the order in which things must be done when building a house. No such laws exist for software systems so there is no “natural” or “right” way to build a software system.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s