“O, what a tangled web we weave when first we practise to deceive!” – Walter Scott
Most website projects have inherited a traditional model of the software development process, typically something like:
- Understand – The designer talks with the business owners to find out what they want and get an understanding of the product
- Feature wishlist – The designer keeps a feature wishlist and starts putting together visual designs that reflect this
- Build – The product is built
- Give to users – A version of the product is launched and made available to the users
- Collect feedback – The designer and/or the business owner get feedback about the product, perhaps adding some user tracking or analytics.
Funnily enough, if we tip that list upside down we get a process that much more effectively considers the needs and wants of the users:
- Collect feedback – The designer talks with users to get feedback and learn about what their needs and contexts are, and might set up some web analytics to record what people are doing.
- Give to users – Design sketches or existing products (perhaps even a competitor’s product) are shown to the users to see what works and what doesn’t
- Build – Learnings from this research and testing help inform the way the product is built
- Feature wishlist – By the end of an iterative process a clear understanding of the features is known
- Understand – The designer and business owner now have a strong understanding of the product and its users that can be built on into the future
It is easy to see that the main differences are in the assumptions made at the beginning of the process and in how this colours the remaining activities. The two important things to understand from this are:
- Without a user-centred approach we rely heavily on the business owners knowing most of the answers before the project even begins.
- With a user-centred design process we have the ability to learn things early and make changes to correct the course of the project.
Defining factors
A user-centred design (UCD) process has the following characteristics:
- The philosophy is to design the product to fit the users, not to force the users to change their behaviour to accommodate the product.
- The needs, wants and limitations of real end users of a product are given extensive attention at each stage of the design process.
- It’s a design process – it identifies and solves problems, and does this by paying attention to the ‘needs’ rather than just the ‘wants’. It is objective rather than subjective – the researchers, designers, developers (and even the users) don’t necessarily get to pick their favourite colours.
- Users are consulted from the start (so designers can analyse and foresee how users are likely to use a product), considered during development (by testing the validity of design assumptions about user behaviour by conducting real-world tests) and the product is validated at the end by testing.
- It is multi-stage and almost always iterative.
A popular alternative method for software development is Agile, and the lightweight, iterative nature of an agile software development method marries very nicely to our UCD process. There are some great strategies UXers can use to contribute effectively in an Agile team, balance some weaknesses in Agile methods (for those who have some concerns about its approach), and produce a more robust process and more successful designs.
If you’re a UXer who is new to agile methods, a book that explains well the mindset for user-centred design projects is Hugh Beyer’s User Centred Agile Methodologies.
We’ll be talking in more detail about user-centred design in our next few posts. Keep your eyes peeled!
Have you ever wondered how you’re expected to quote upfront for a large, unknown web project?
This post has been translated to Croatian.
Hey…you’ve made some insightful points here. Thanks for the share!
Thanks Lee! I’m glad you found it helpful!
I agree. The process always needs to be user focused. Asking the client about their target audience’s preferences, conversion points, etc. All this can then help shape the features/understanding needed.
Thanks Jeff =) And one step better than asking those questions of the client is asking them directly of the users. One of the things I enjoy most about UX is how many decisions can be made objectively by sourcing the right data. It creates helpful conversations within the team and helps avoid politics and ego in projects.
It’s amazing how many web designers still do not ask enough questions to their client and end up just building a website they like, even though it might not meed the clients requirements.
Yes, too true, Mike. I can understand the vision that forms in a designers mind during the early stages of a project, and how a designer might want to protect this by limiting external input. I’ve been guilty of this in the past too. But since making an intentional effort to widen the amount of input in the early stages of the project I’ve found that my work is a lot more robust and the quality of the design even better. Some designers might call this ‘socialising’ the design, but I think it’s one of those UX techniques that comes naturally. This includes talking to the client, as you say, but also (and importantly) it should include talking to the target users of the website. Otherwise it ends up being the designer and the client just building the website they like. =)