“She is 24, single, and has a cat called Torx.” A common starting point for a UX workshop is the ‘User Persona’, the imaginary customer that is used to theoretically explore the needs of the future product’s real world user. Using a methodology that centres around customer Personas for a work in progress product allows requirements to be defined, and challenges to be addressed. And once the Personas are written, when the great diversifying product feature is fleshed out, when the beautiful mockups are prototyped and animated, we throw the redlined Sketch or PSD files to the developer and move on to the next project.
Yet as designers we tend to ignore or forget that UX has a fundamental role to play in the development process. To ensure a competitive end product, nice visuals and great micro interactions are only one part of the whole.
Why Personas are not enough
It can be fairly common place that budget isn’t available to conduct real-world user research, and Personas are a cost effective method of validating ideas relative to a variety of target customer groups.
Too often though, Personas are taken as a factual starting point to identify a product’s needs, ignoring that they are usually just guesswork; educated guesswork, but guesswork nonetheless. As designers, it is easy to fall into the trap of creating Personas in the image of the ‘ideal customer’, a person that is easy to design for, and already wants to buy the product, before it’s even been finished. This make us ask the wrong questions, leads us down the wrong path, and on to wrong conclusions, sometimes without the team even realising it.
An alternative approach is to limit the usage of Personas to initial high level kickoff research, and then soon after to focus on solving problems related to context, causality and motivation. The development of Job Stories in conjunction with theoretical User Personas, can be a more effective method of validating ideas, and iterating towards a valuable product. Job Stories address the Situation, Motivation and Forces, and Expected Outcome, and when combined with Personas, allow for the creation of a modular set of questions that need to be answered at every stage of the product development lifecycle.
UX is not UI
A great user experience happens with every interaction someone has with a product. Durability, loading speed, weight, and readability; everything plays a part, yet design often tends to be so segregated from the development process that it is easy to ignore these factors in favour of cool aesthetics of a product’s UI.
Take web design. Font style or size choices are often debated in terms of aesthetics, but to a customer with even mild dyslexia, readability can mean the difference between engaging with your digital product, or bouncing from your website and reaching a competitor’s instead. The hours poured into crafting the ultimate user flow go out the window when a customer struggles to read your content.
Performance is another often ignored aspect of UX. Again remaining with the web design theme, it is well documented that long loading times lead to high bounce rates and low engagement (and let’s not forget, frustrated humans!), but far too often the design process is simply too far removed from development to have prevented the decisions that allowed latency issues to creep in. If a web designer believes they are truly targeting optimised UX, then they must be heavily involved in the development process. Low resolution image alternatives, font loading times - and best practices for implementation, and content load priority, are a few of the factors that an effective web designer needs to be considering.
It is good to see that it is less common to see design that simply focuses on UI, but we still need to set the bar higher for what qualifies as UX design. UX should be considered from the very initial product concept, through the full life cycle of product development and distribution. We are designing for real people, let’s solve their real problems.