“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.