How to adopt an iterative approach to UI design

As digital projects become more complex and business critical, our approach to UI design has to adapt. This has led to the rise of an iterative approach.

It is hard to believe that when I started out in web design over 20 years ago, I used to build websites for international brand single-handedly. Not just the UI design, the whole thing! Can you imagine one person making a site for a major brand name today? Today it takes large teams of individuals. Specialists in everything from copywriting to design and development.

In fact these days, even those specialisms have specialisms. User Interface (UI) designers, User Experience (UX) designers, user researchers, front-end developers, server-side engineers, database experts, information architects, digital marketers, digital project managers, the list goes on and on.

It is hardly surprising that we need these experts. After all, most organisations websites are a hundred fold more complex than 20 years ago. Then there are web apps, mobile apps, chatbots, etc. This complexity has forced a rapid evolution in all kinds of fields, including UI design.

UI Design is becoming ever more complex.

Why UI design needed to evolve

With the rise in the complexity of projects comes increased expense, which in turn leads to greater risk. A risk further magnified by the critical nature of digital projects. Organisations can no longer operate without an effective digital presence.

The high risk of digital projects attracts an increased number of stakeholders. People from across the organisation who need the project to succeed and have strong opinions on how the company can achieve that.

UI design has to deliver. Otherwise, businesses can waste significant investment and suffer serious consequences.

As if all of this is not scary enough, users continually raise the stakes with spiralling expectations. Expectations defined not by direct competitors, but by the last best UI they have encountered, even if that interface was from a major Silicon Valley brand who can invest millions into UI design.

The only way that organisations can deliver against these increased demands is to form bigger teams made up of numerous specialists. But this too brings complexity, with competing priorities and different perspectives.

It is hardly surprising that the old models of building websites are breaking down. It is no longer enough just to pour content into design templates or for designers to throw UI designs over the wall to developers. Everything is too interconnected for that.

But shifting away from this waterfall model is culturally challenging for many organisations, and the result is significant failures. Companies who have tried to roll out large scale redesigns and ended up going over budget and suffering from massive delays.

I have long spoken about the reasons behind the big failure of website projects. One of those reasons is how the projects are run.

Amongst all of this growing complexity, it is from UI design that new approaches are evolving. Design thinking that introduces a more iterative approach to the development process and UI design in particular.

An iterative approach to UI design

There is no right way to create a user interface, and no one size fits all solution. But there is a shift away from a more linear approach to something more iterative, where collaboration is key and ideas are continually validated.

That is an approach that often begins with what has become known as a discovery phase.

The introduction of a discovery phase

Even the most traditional of projects have started with some form of initial phase before work begins. A time where the project is defined, and you set expectations. But a discovery phase is a unique beast.

For a start, it begins from a different premise. While more traditional projects start with the question ‘what do we want to achieve?’, a discovery phase asks the question ‘what does the user want to do?

That is not to say organisational objectives are irrelevant. Rather it acknowledges that the user’s needs are under-represented and you need to give them particular attention. It also realises that in most cases focusing on user needs helps achieve long-term organisational goals.

Answering the question of what users want to achieve is done through user research. That is not the same as more traditional market research that has been carried out for years. User research focuses on understanding user needs, rather than how to convince them to buy. The emphasis is on observing their behaviour, rather than canvassing their opinion.

You replace focus groups and demographics with top task analysis and an emphasis on user questions. Equally, you can look beyond marketing personas to empathy maps and customer journey mapping.

Empathy maps shift the focus away from convincing your target audience towards meeting their needs.

But a UI design discovery phase is different in another way too. It is usually significantly shorter than its more traditional counterpart. That is because UI design recognises that change is inevitable and even desirable as you learn more about user needs.

In traditional projects, scope creep is the enemy because the cost of change once work has begun is typically high. As a result, the initial phase of a project often involves the creation of a detailed specification that covers every aspect of the project.

But this initial phase is typically incredibly time-consuming and in the digital field at least unnecessary and harmful. It is only once you have something tangible to test with users can you truly understand their needs. What is more, adapting based on what you learn is relatively inexpensive as the raw materials (pixels) are free. In UI design projects, change isn’t to be feared; instead, you should embrace it.

Therefore instead of a detailed specification, all that is required is well-written goals. Alongside those, you need a thorough understanding of your audience and what success would look like from their perspective. That will significantly reduce the time involved before work can begin.

UI Design and visual identity

At this point, it is worth pausing to talk about brand identity and aesthetic design. Although closely related to UI design and in many cases done by the same designer, they are slightly different disciplines. UI design focuses on usability and interaction. Aesthetic design and branding place a greater emphasis on feel and emotional connection.

In many cases, much of the branding and aesthetics are already in place by the time an UI design project begins. A designer has already established the personality of the brand, and the primary job is how to interpret that for the user interface.

However, that is not always the case. The project maybe for a new product or service. It is also not unusual to carry out a brand refresh at the same time as a website redesign. In such cases, after the initial discovery phase, it is often necessary to address the issue of aesthetic design.

Although there is no right way to approach this, I prefer to tackle this apart from the UI design. That is because you are asking different questions and solving separate problems.

Many exercises can help establish your brand identity. Exercises like collaborative mood boarding, designing reception areas and working out what famous person your brand would be.

There are many exercises that help establish a brand identity including moodboarding.

You can also test whether user perceptions of your brand are in line with your desires. For example, you can identify words that you hope will represent your brand. You can then show these words to users alongside many others (including complete opposites) and see what they select.

Keyword matching can be a useful way of identifying whether you have established the right aesthetic for a brand.

It is entirely possible to evolve the aesthetic elements of design alongside the user interface. But I prefer to try to at least get the basics in place before beginning work on the UI itself. That allows you to focus your testing with users on one element of the design at a time.

Testing is the backbone of the UI design approach, and for testing to work, you need something to test. That is where prototyping becomes so critical.

Building to an iterative prototyping instead of specification

In many ways, the prototype replaces the functional specification. It becomes the shared vision of the project towards which everybody is moving. However, unlike a technical specification, it is a fluid concept that evolves based on user feedback.

Your discovery phase will have identified many questions users want answering and tasks they wish to complete. That will become the basis for your new site and associated UI design.

Often the best place to start is by running a card sorting exercise on these questions and tasks. In short, this boils down to writing each question or task on a separate index card and asking users to sort them into stacks of cards that make sense to them. You then request the user to label these stacks, and that becomes the basis of your information architecture.

In a card sorting exercise, users organise information into stacks that make sense to them.

But this information architecture will need testing to ensure you are confident in it.

My speciality is with content-heavy sites such as in the higher education or charity sector, rather than with web apps. Therefore, my process often begins by plugging the proposed information architecture into a content management system. That is the genesis of my prototype.

At this stage, the pages within our content management system are mainly blank. At most, they just list the questions that any particular page answers. But that is fine. All we are looking to test is whether the site structure matches the user's mental model. Can users find the page that contains the answer to the particular question they are asking?

Initial UI prototypes will be extremely basic focusing on information architecture and user questions.

In other words, we have formed a hypothesis about a possible approach and are now testing whether we are correct. If we are not, we can make further refinements to the information architecture. If we are, we can move on to the next phase.

This process of hypothesis, testing and iteration is the foundation of a modern UI design process. The same basic principle applies whether working on information architecture or any other aspect of the UI design.

Over time we become more confident, and so we can start to add increased fidelity to our prototype. Content specialists can begin to identify key components of the answers to user questions and sketch them out as bullet points. Meanwhile, UI designers can start to think about the sites visual hierarchy, introducing basic layout elements to draw the users eye to the main components of the page.

Over time the prototype can evolve to include visual hierarchy and more complete content.

Once again, these improvements will need testing and iterating upon, based on user feedback. However, as we become more confident in our direction, we can begin to add even more fidelity to our prototype.

At this point, we can also start to standardise UI design elements into a pattern library. That is a reusable library of design components from which we can build the final site. A pattern library will ensure consistency, improve maintainability and reduce the cost of site builds in many instances.

Meanwhile, content writers can start to draft complete answers to user questions, while designers can introduce UI stylings such as typography and colour.

The design and copy can continue to evolve based on user feedback and as further fidelity is introduced.

In this way, the UI design and content will begin to emerge through a process of testing and evolution. Each round of iteration gradually introduces more fidelity to the user’s experience, moving the organisation closer to a new version of their website.

That ensures that there are no surprises when the company launches its new website, and the public see it for the first time. After all, users have been testing it every step of the way.

But even launching the new website can be handled in a more efficient way than many have done things traditionally.

From prototype to beta and then live

Once again, how we manage projects has been heavily influenced by the physical world. In such a world the moment comes when a company launches a product, and you wait to see what the public’s judgement of it is going to be. It is a binary moment where one minute the product is in development and then it is released. But in the digital world, we have more flexibility.

When the development team and stakeholders start to become more confident in the direction of the prototype they are building it is time to start moving it across to a production environment. That is the point where we can put a more robust architecture in place, and the complex integration work gets done.

This yet unreleased website is often referred to as a beta. The point will come when this beta is feeling fairly robust, and all involved are confident in its ability to deliver on user needs. It would be tempting at this point to push the site live and call the job done. But this would be a mistake.

Although we have been testing the site with users throughout its prototyping phase, we have yet to see real users interacting with it in an entirely natural way. To achieve that we need to make our beta publicly available.

Typically this is the point where we launch the beta alongside the existing site on a subdomain. We can then signpost the beta on the main site, asking users if they would like to take it for a test drive.

Eventually the beta should be made publically available so you can monitor how users interact with it in the real world.

That affords us the opportunity to monitor how users respond to the new website when they are not conscious of being watched. Using analytics tools and session recorders we can see users naturally interacting with the beta and make final changes based on what we learn.

Eventually, after further refinements to the beta, the point will come when the beta is better than the existing site. At this stage, the team and stakeholders will make the decision to retire the current site and replace it with the beta. That is the ‘go live’ moment, but it is not the end of the project.

Continual monitoring, refinement and evolution

One of the biggest mistakes I see in UI design is the belief that when a site goes live the project is over. Nothing could be further from the truth.

When your website goes live, digital affords us an unprecedented level of data on how real users are interacting with it. This treasure-trove of information arrives just as the money typically dries up on a traditional web project.

We learn more about user behaviour after launch than at any other stage. Unfortunately this is typically when the money dries up.

Fortunately, that kind of thinking is beginning to change, and more progressive companies realise that the UI and content can continue to evolve and improve long after the go-live date.

That said, in the real world, teams cannot sit around, endlessly iterating on the same piece of work. There is always the next project to be done.

But what they can, and should do, is periodically revisit previous work. The digital team should look at analytics and identify areas for improvement. They should ask whether either consumer behaviour has changed or business requirements. In short, they should look to evolve their web presence every few months, and that includes the UI design.

This iterative approach to UI design is not perfect. It has its flaws, but it is considerably better than more traditional project management techniques.

The advantages of iterating UI design

The irony is that the justification given for not adopting this more iterative approach to UI design is the same reason they should be doing it.

For example, I often hear organisations complain they don’t have the time or money for prototyping. Ironically in my experience, prototyping provides significant cost savings and prevents projects inevitably slipping.

By validating each stage of development, organisations can avoid costly mistakes and assumptions about user needs that will be expensive and time consuming to fix at later stages of the project. They prevent the cost of building functionality that nobody wants and get to market faster because of avoiding long specification phases.

Iterative UI design also improves communication as everybody has a shared vision of the prototype and stakeholders see that prototype evolving. This both educates them and ensures everybody is moving in the same direction. Unlike a specification, they can remain flexible, adapting to lessons learned on the journey.

But most of all, it avoids endless discussion and debate about the best approach. By testing with real users, you resolve a lot of these issues far faster than you can through arguments between stakeholders.

Testing a prototype with real users resolves disagreements over direction in a fraction of the time.

Another common objection is that moving to this new model is just too big a risk. People would prefer to stick to the tried and tested approaches used over the years. But how useful are those strategies? When was the last time you launched a website that was ahead of the competition and remained relevant for more than a few months?

Too often projects run over budget and fail to get to market fast enough. Even when a project doesn't fall into these traps, it often fails to meet organisational objectives.

One of the best things about iterative UI design is that it reduces risk. By continually validating ideas with users throughout the process you can be sure you are building something that works and meets their needs.

It allows companies to be considerably more confident going to market and sure that their investment will generate a return.

But you don’t need to embrace all of this in one go.

Give iterative UI design a go and measure the results

I would encourage you to try iterative UI design. You don’t need to switch wholesale to the approach overnight. Instead, use it on a single low priority project and see what happens. I guarantee you will be pleasantly surprised.

When that works out, try introducing some aspects into larger projects. Maybe that is a discovery phase or at least some prototyping and testing. Even implementing some aspects of interactive UI design is better than doing nothing.

Remember, there is no right approach. Make it work for you by adapting it to your needs.

Boagworks

Boagworld