In the digital era, understanding and designing for users is the root of successful product development. During a recent tech talk at Leeds Digital Festival, Emily O'Connor, Principal Test Engineer at Audacia, explored this topic with a focus on a common pitfall among development teams - assuming they know their users because they understand the product. Emily highlighted how development teams should step outside of their perspective and embrace user-centric design to improve product quality.
Recognising the Gap: You Are Not Your Customer
Teams are not representative of the average users of the applications they build.
While it may seem obvious, teams can often design based on their preferences and behaviours rather than the actual needs of their users. Teams across various industries often fall into the trap of designing for themselves.
For example, engineers can often focus on technical excellence, assuming that users have a similar level of understanding. However, the typical user might be juggling everyday challenges such as commuting, parenting, or simply trying to get through a task quickly. They aren’t immersed in the product daily, nor do they have the same context or expertise as the development team. This disconnect between the development team and the user can lead to products that, while technically robust, fail in usability.
It’s a focus on balancing this.
The Average User: Demographics and Characteristics
Take the demographics of the "average user" using two personas:
Jessica, the average American
Sarah, the average Brit
Both women represent the typical mid-30s, white, working-class users with specific education levels and life circumstances. Despite their similarities, these personas often differ significantly from the backgrounds of the development teams designing software.
Development teams however are typically younger, hold a higher level of formal education, and possess higher technical literacy than the average user, a disparity that can lead to incorrect assumptions about user needs.
For instance, the average development team are likely to know that you can swipe between tiles, but Jessica or Sarah might not share this assumption.
This mismatch underscores the importance of regularly engaging with real users, rather than relying on assumptions derived from personal experience or intuition.
Common Assumptions That Undermine Product Quality
Common assumptions that development teams frequently make:
- Application Context
- English not as first language
- Use of OS, device or browser
- Older users who might use a higher zoom
- Using dark mode
- Older users who are less tech savvy
- Completing a user-journey within a given amount of time
Let’s take application context. Developers may assume that users will inherently understand certain icons, gestures, or navigation flows because they are immersed in the product every day. For instance, an icon representing "swipe left" may be obvious to the development team but completely foreign to users who are unfamiliar with touch gestures.
In terms of technology, testing on the latest versions of popular browsers or devices is common practice, but it overlooks users with older devices or different settings (e.g., high zoom levels on smaller screens). For example older users might experience drastically different interfaces due to larger text sizes or outdated browsers, which developers can fail to consider.
And even the fact that many teams design applications with dark mode enabled, assuming users will prefer it because they do. However, preferences vary, and products should be tested across different settings and modes to ensure accessibility and usability for all users.
The Power of Challenging Assumptions
Within the talk, Emily provided insight into her own experience with aphantasia, a condition that prevents her from creating images in her mind's eye. While this may seem like a limitation, it has become a strength, allowing a more critical approach to user interfaces by forcing the ability to rely on logic and critical thinking, asking questions that others might miss, or make assumptions on. This unique perspective allows the identification of potential usability issues that others, who might visualise the system perfectly, could overlook.
For development teams, a similar mindset can be advantageous:
Always question the features and functionalities being built. Are they user-centric, or are they based on what the team finds intuitive?
Testing early and often, and using A/B tests to validate assumptions, which play a critical role in uncovering how real users interact with the system, especially given user acceptance testing is likely to focus on a small population size.
The Challenge of Retaining User Focus
Take the game of telephone.
This can be a good representation of how product vision and user needs can get distorted as they move through different stages of development.
In this analogy, a product owner starts with a clear vision, but as that information passes through the hands of designers, developers, and testers, the original intent can become misinterpreted. Each person in the chain adds their perspective, assumptions, and interpretation, which can lead to a final product that is far removed from what the customer actually needs.
The introduction of AI adds another layer of complexity. AI-driven tools often rely on patterns and assumptions about user behaviour, further widening the gap between product teams and end users. This game of passing along requirements and assuming user expectations highlights why it is so difficult to maintain a clear, user-centric focus throughout the product development cycle.
Designing for Everyone: Accessibility and Usability
Whilst designing products, it is important to make sure that they are:
- Perceivable
- Operable
- Understandable
- Robust
These four Accessibility Principles are part of the Web Content Accessibility Guidelines (WCAG), a critical resource for ensuring that products can be used by a diverse audience.
Teams should ensure they are testing user interfaces are perceivable and operable on a variety of devices, screen sizes and browsers. Colour contrast should be tested and alt-text should be added to images and navigation items. At the same time, teams should plan accessibility testing to ensure they have not made assumptions about a user's abilities, language fluency or technical literacy.
By adhering to these standards, teams can ensure that they are building products that are not only functional but also truly user-centric.
Conclusion: Empathy Drives User-Centric Development
Empathy is at the heart of user-centric development.
By recognising that the average development team does not reflect the average user, teams can start to design products that meet real needs, rather than imagined ones. This requires constant questioning, testing, and revisiting assumptions throughout the development process.
Ultimately, you are not your customer.
To build products that resonate, development teams must break free from their own perspectives and step into the shoes of the people who will actually use the product. Only then can they create solutions that are not only innovative but also intuitive and accessible to everyone.
Key Takeaways:
- Recognise that you are not your customer:
The majority of development teams do not reflect the average user’s needs, habits, or challenges. It’s vital to accept this and continuously engage with real users to understand their context.
- Challenge assumptions throughout the development process:
Assumptions about user behaviour, device preferences, and the context in which your product is used can lead to poor design decisions. Use A/B's, user feedback, and data analysis to validate any assumptions early and often.
- Leverage accessibility guidelines:
Ensuring that your product is perceivable, operable, understandable, and robust not only creates a more inclusive product but also drives higher usability for all users.
- Empathise with your users:
Building empathy is key to developing products that resonate with users. This means not only understanding their needs but also recognising the constraints they operate under—whether it's time, attention, or accessibility.
