10 Strategic UX Design Questions answered
Engaging with our professional peers, we see a recurring set of questions and challenges related to Strategic User Experience Design.
These questions and challenges especially pertain to organisations where the UX have grown to a critical mass and is now ready to start impacting the rest of the organisation in a more profound and strategic way. This means moving from a “responsive UX service” in projects to an upfront initiating and driving approach.
The following 10 questions are tell-tale signs of mature UX teams that are transitioning towards a more integrated and organised maturity level (see infographic on the right).
No matter the maturity level of your organisation, the individual questions will almost certainly also resonate with your own UX-related work.
〰〰〰〰 Question 1 〰〰〰〰
❓How do we best communicate the value of UX?
How do we best communicate the value of UX to other professionals with no formal UX background - both internally and to clients?
This is certainly a question central to most UX professionals. How do we legitimise and document our worth? It is almost business existential!
I have two overall thoughts on this:
If we hope to get our message across, we need to be more precise in our communication of all things related to UX. In itself, UX is a very broad headline that covers a wide variety of perspectives. These details are often lost. For instance, when we talk about UX, we should operationalise that into the important constituents: Do we talk about product features and functionality, or do we talk about usability qualities?
UX has little inherent quality. To communicate the value of UX, we need to translate UX qualities into relevant qualities for those we talk with. Talking to a business developer, we should make an effort to link UX qualities to business developer terms like “user retention” and “market size”. The same logic applies to our clients. Instead of focusing on what UX will do for the users, we should be crisp on what UX can do for our clients.
▶︎ For additional input, we suggest reading “Images of usability” by Morten Hertzum to help be precise when it comes to what you mean by usability. Also, see our section about Strategic UX Design in the UX Campus Library.
〰〰〰〰 Question 2 〰〰〰〰
❓How do we make our UX work measurable and how do we know that we are a success?
Measuring UX and knowing that we (as UX-professionals) are a success are closely linked aspects. It is through data-driven documentation that we can make the business case for the value of UX design - AND the UX design activities that took us there.
While we can measure all kinds of things related to UX, we should be mindful of how those measurements link up with the bigger picture related to end-user behaviour and business value.
In a prototypical user-centred design process, such as the double diamond, we can make measurements in both diamonds:
Examples of first diamond problem space measurements:
Diagnostic usability measurements of existing solutions.
Measurements of the importance of identified user needs (to help prioritise). For instance, the value proposition canvas requires us to rank order jobs, pain and gains.
Examples of second diamond solution space measurements:
Ratings of different concepts in the ideation phase (e.g., feasibility, risk, viability, desirability).
Measurements related to usability. Especially objective performance metrics like time-on-task, learning curves, error rate, and error recovery. But also subjective ratings like perceived usability and safety.
▶︎ For additional input, we suggest reading “Think like a UX Research” and “Measuring the user experience”.
🎓 Get the full story about Strategic UX Design.
Attend our three day course at UX Campus in Strategic UX Design & Design Leadership.
See course program, dates and free sample videos.
〰〰〰〰 Question 3 〰〰〰〰
❓How can we help our clients make the right design strategic decisions when they come with new feature requests?
This answer is a bit longer - so hang in there!
This question tap into a common misconception about user-centred design:
If users ask for a feature we should deliver it!
As a general logic user-centred design is about understanding user needs and then finding ways to meet those needs in an optimum way (factoring in a broad range of requirements like price, risk, regulations, strategy etc.).
If we just deliver on feature requests (from users) then we shortcut the process. Here is why.
PLEASE NOTE: the other critical side to UCD is involving users to test your design to make sure it works in the hands of the intended users for the purposes and use contexts intended ( The double diamond has TWO diamonds).
Don’t promote users to incompetence
If we simply execute on feature requests we risk promoting users to be experts in how to best deliver on user needs. That is not a good idea. Instead, we should acknowledge that users are experts relative to themselves and their needs but not experts in design.
To complicate things, people will typically communicate their needs in concrete ways by relating them to existing design, functions and features. So we naturally get “feature or functionality requests” when we engage with users.
This means our job as user researchers is to understand the underlying need that the user is trying to communicate with those functionality requests.
Our job is thus not the be 1-1 facilitators between users and the design project but to uncover underlying needs (and the logic of those needs).
This logic is nicely captured in the phrasing:
We should take people seriously - not literally!
Push-back to decision-makers.
This means that we sometimes need to say “no” to feature requests. Or at least challenge them. This can be tricky since it makes for a very powerful signal when we “listen to our customer base by giving them what they want”.
It is also important to understand that it is not a linear process where we “know better” on behalf of the users. Users should still have the ultimate say in deciding if their needs have been met or not.
That is why we also transform user needs into potential conceptual directions in order to allow users to validate the work we have done. An important part of user research is therefore to validate that we have truly understood the user needs behind the “feature requests”.
PLEASE NOTE: validation of user needs seems very similar to concept validation. However, it is useful to distinguish between the two.
First, we need to validate user needs. Sometimes using design concepts to express what we learned.
If our user needs are validated then it becomes user requirements for a given solution. Once we have user requirements we can then start to ideate concert conceptual directions (all being answers to validated user needs). These conceptual directions each have pros and cons as they also deal with the messy reality and an often crooked design space defined by a multitude of corner flags (price, regulations, production)
Yes, sometimes users nail it - but don’t count on it
Yes, sometimes a user will nail it and provide suggestions for a feature request that is spot on. So while this is definitely a possibility from time to time we should not set up our design processes to rely on users being able to do so.
A robust design process is a combination of expert skills and an understanding of how they supplement each other. The user is an expert in their reality whereas the designer is an expert in design.