Suppose that you want to build a hotel. This isn’t a well-funded project backed by a major chain – it’s a personal project backed by some savings and an initial loan from the bank. You have grand plans for 50 or 100 rooms, a modern, boutique style, a small pool and fitness suite and a great restaurant. First off though, you need to get the Hotel built and up-and-running as quickly as you can, so you can start getting paying customers through the door. That way, you can begin to pay the bills and make a case for getting further loans to do the rest.
This is an interesting metaphor for a software development project and there are a number of lessons that we can learn, because most development projects don’t have ample time and funding: you can’t just build everything that you want straight away and release it to the public when everything is ‘finished’ – just like the hotel, you need customers to start using the software as early as possible, both for revenue purposes and so that you can start to learn what works and what doesn’t.
HARD ENGINEERING AND BASIC GROUNDWORK
The first thing to notice about the Hotel metaphor is that there are a lot of fundamental and necessary things that have to get done, but are easy to overlook. First off, you need a site, you need architectural plans and you need to get the necessary permits; then you have to find a contractor to do the building work; you need to lay foundations and you have to build the basic shell of the hotel and make it weatherproof; you need power, water and sewerage; you need a heating system and wiring.
All of this is a long way from creating the funky rooms that you have in mind, but it is all essential – you can’t skip it, and you can’t afford to do a poor job of it – cutting corners in these areas will inevitably come back to haunt you later.
This is similar to the ugly realities inherent in most software projects: sure you want to build a beautifully simple interface that users will love, but you have to hire people to build it; it has to be deployed somewhere; the backend needs to be built – databases and business logic; you need test environments and continuous integration; you need sufficient bandwidth to support the expected traffic; you might need to register your company and have a good lawyer you can call on; you need to pay your taxes.
A slip up in one of those areas could cost big later on, but it is easy to overlook the hard engineering that needs to take place behind the scenes to create a simple and effective piece of software.
However, we can also be smart about how we approach these big pieces. You have to lay foundations and build the shell of the hotel, but you don’t have to build it big enough for 100 rooms straight away – you could build one wing, with a clear plan as to how to extend it later.
You need a kitchen so you can serve food to the first guests, but you don’t need to buy equipment to feed hundreds, you can keep it simple to begin with – perhaps you build the shell of the kitchen big enough to fit in what you will need later, but only buy a quarter of the equipment to start with.
In the same way, you don’t need 15 servers before you’ve even released a beta version. Start out with just enough to cover the expected traffic for the first 3 months, but be clear about how you can expand it when you need to. Do you have enough space in the data centre to add more servers when you need them? Where will you order them from? How long will it take to install them? If you go virtual, how easy is it to order more bandwidth from the supplier?
CORE FUNCTIONALITY
Let’s think about the more tangible stuff – the pieces the guests get to see. You have to fit out a nice enough lobby and you need some rooms. But even if you’ve built a shell for 50 rooms, you don’t need to fit them all out at once. This is all about prioritisation. Time and money are limited, so they need to be invested in the best possible way.
It makes sense to focus effort on getting a subset of the rooms complete – ready to let – rather than having all of them half ready. In this case, half ready is not ready at all. However, that doesn’t mean that they need to be fully complete in terms of your ultimate vision. You could do without the coffee maker, the iPod dock, the trouser press, the individual safe. You won’t be able to charge as much for them, but you could get paying guests.
A good question to ask would be: what if the money runs out tomorrow – which things should I do today that would maximise the overall completeness of the enterprise if we have to stop building?
The same considerations apply in building the interface of a piece of software: there are some pieces that you have to build and some functionality that can wait to a later version. There are areas that need to be beautifully polished, and dark corners that don’t merit the same investment.
Think about the range of features that you have designed: which ones are really essential to get paying customers using the software for the first version? Get those implemented first, with a clear plan as to how to add the other elements later. Think also about the importance and traffic of different elements: the main functionality needs to be complete and well crafted; you probably also need settings and options – but these are far less important, they need to be functional, not exceptional.
DECOR AND VISUAL DESIGN
To have happy customers at your hotel, it needs to be well decorated, with a high quality of fit and finish. What you have in mind is a stunning modern look, with beautiful feature wallpapers, luxurious fabrics and original artwork. This will be expensive. But do you need it all at once?
As before, you can see that this could be done in stages. Getting paying customers in doesn’t need all of those touches – perhaps the rooms could be simply painted at first, with bright, but inexpensive fabrics, and prints, rather than originals. You could plan to upgrade these rooms piece-by-piece once the business is running. Another approach to staging the work would be to keep these rooms much as they are for a while and focus on building out the next set of rooms to a higher standard – and charging more for these when they are ready.
What about the fantastic visual design for your software? Well, it can be surprisingly expensive to implement visual design correctly, and it clearly wouldn’t make sense to insist on perfection throughout the whole system at the cost of getting the basic functionality to work.
Just like our hotel example it makes sense to think about where to simplify and where to invest. There are three main ways to do this: you can focus effort in getting the highest standards in the most important and well-trafficked part of the application; you can focus on the main elements on each page and take a more basic approach on others (e.g. using basic CSS capabilities of browser and library controls, rather than custom-styling them); and you may be able to simplify certain aspects of the design to make it easier to implement (e.g. changing gradients, strokes and shadows so that they can be created using pure CSS).
As with the Hotel example, taking this approach doesn’t prevent you from increasing the sophistication later – figure out a plan that lets you start simple and improve gradually. However, what shouldn’t be debated is the need to reach an acceptable level of quality at all times – using paint rather than wallpaper is fine, but the edges should be straight, the brushstrokes neat and paint should not be dripped on the floor. How often have you seen the equivalent in a poorly-built UI?
Bear in mind that there is an additional reason to take a staged approach when it comes to visual design: fashions change. Certainly more than in any other aspect of a build, the visual design is likely to change regularly, which means that it should always be considered a work in progress.
CONCLUSION
As designers, we have a responsibility to consider the delivery of the whole project, not just the interaction and visual design. We need to understand the bigger picture and work with the other disciplines involved to create the best possible outcome – not just the implementation of the interface as we designed it.
You need to bear in mind the complex and fundamental engineering that the developers can’t avoid – the ugly realities of deployment, business logic, servers and bandwidth. These are things that you can’t help with, but understanding that they exist will make you more tolerant when they push back on the implementation of your brilliant, but complicated UI design.
Design the best UI that you can, but work with development to implement it in stages wherever possible: focus investment in the places that matter the most, find ways to lighten the load everywhere else. Don’t take that as an argument to always give in – ensuring that the interface is the best it can be is your part of the problem. Sometimes it really does make sense to invest in the UI, but be prepared to make that case. Don’t expect it to be obvious to everyone involved.
Above all, work to maximise the overall completeness of the project at any one time, in case the worst happens and you have to ship it tomorrow.
Martin Colebourne 