Unpacking UX: A Guide to Speaking Precisely in Product Development

Beyond “Improving UX”: Specifying the Need

In the world of product development, the term “User Experience” (UX) often becomes a catch-all phrase, used to cover a multitude of design, usability, and functionality concerns. However, employing this term too broadly muddies the water, leading to misunderstandings and inefficiencies within teams. To communicate clearly, improve project outcomes, and make it understood that we know what we’re talking about, we need to speak much more precisely about UX.

When we say we need to “improve the UX” of a product, what do we really mean? UX encompasses everything from the visual design of an interface to how a user feels when interacting with a product. By being more specific, we can more effectively target our efforts:

  • Instead of saying, “We need to improve the UX of our app,” consider specifying, “We need to enhance the navigation flow within our app to improve usability.”
  • Rather than suggesting, “Let’s consider the UX in our next sprint,” pinpoint the action by saying, “Let’s include usability testing in our next sprint to identify and address user pain points.”

Feedback and Feature Development: The Importance of Precision

Feedback on features or the overall product can often be vague, attributed to “bad UX.” However, drilling down into specifics can provide actionable insights:

  • If feedback mentions, “Users are complaining about the UX of this feature,” a more insightful approach could be, “Users are finding the interface confusing and need more intuitive interaction design for this feature.”
  • Discussing product strategy by saying, “Our product’s UX doesn’t stand out against competitors,” could be more constructively expressed as, “Our product lacks a unique value proposition and user-centered design approach compared to competitors.”

From UX to Specific Actions

When planning, developing, or evaluating a product, specificity in communication is key. For instance:

  • In development phases, moving from “We need to consider UX while developing this API” to “We need to ensure the developer experience (DX) is considered by creating comprehensive documentation and easy-to-use endpoints for this API,” shifts the focus to actionable goals.
  • Pre-launch checks often get simplified to “We should do a final UX check before release.” A more detailed approach would be, “We should conduct a final round of user acceptance testing to ensure the product meets user needs and expectations.”

Conclusion: The Clarity in Specificity

Emphasising specificity when discussing UX not only clarifies communication among team members but also aligns efforts towards more targeted and effective outcomes. By moving beyond the umbrella term of UX to articulate the specific aspects of user experience we’re addressing, we foster a more efficient, collaborative, and ultimately successful product development process.

We need to challenge ourselves to communicate with precision, ensuring that every mention of UX is accompanied by a clear, actionable, and specific intention. This approach will not only improve our products but also our professional growth and collaboration within our teams.

Design strategy

How to update a complex legacy application.

Rare is the time I’ve been blessed with a truly ‘greenfield’ project, a product so new that the only conventions that need to be adhered to are those that come with the target users (see Jakob’s Law) and those of good product design. More often than not it’s been my job to improve established systems with established user bases, who have invested time and effort into working with a system and its… quirks. How do you make changes to a product – sometimes significant changes – without frustrating your existing userbase?

Option I: Softly softly

“The man who moves a mountain begins by carrying away small stones.” —Confucius

These’s a lovely analogy I once heard to describe making small, incremental, but meaningful changes to an existing system. Imagine you’re standing in a kitchen. You’ve been using it for months now and have learned where everything is. Now imagine I’ve come in overnight and reorganised everything to the most logical, most ergonomic locations, and removed the least-used equipment. Any new person that comes in to the kitchen will stand a much better chance of guessing where to find what they need, but you need to spend tine and effort re-learning everything you knew about how to use that kitchen – you’d be frustrated even if the design of the kitchen was demonstrably better. The same is true for software redesigns.

The solution is small, well labelled changes made on a regular basis. To continue our analogy, rearrange the spice rack to make it alphabetical, and tell the users you’ve done so. Or with UI design, re-order the contents of a page to one that your research has told you works better for your users, and tell your legacy users that this change has been made next time they visit it. Through regular small changes you can quickly redesign an entire system and bring your existing client-base along with you.

Option II: Launch, Coexist, Phase-out, Retire

“Change is the law of life. And those who look only to the past or present are certain to miss the future.” — John F. Kennedy

This option involves building a completely separate version of your product that will run alongside your existing offering. This fantastic new version of your product will be launched with the understanding that existing users can, for a time, continue to use the older version, but that all the fantastic new features will only be coming out in the new version. The two versions coexist for a time, before the old is phased out and any laggards remaining on the old system must migrate across to the new. This was Microsoft’s approach with moving users from Explorer to Edge: Launch; Co-exits; Phase-out; and Retire.

Which option I’ve opted for has depended upon a number of factors such as the scale of the product and the resources available to build an entirely new offering alongside an existing one. But in the end, these have always proven to be the best two options.


“Er” and “Um”: Banish filled pauses to improve your communication

It’s not just, er, what you have to say; how you, um, say it matters too. While it’s painful to read written language containing “er”, “um” and “uh” (collectively known as filled pauses), their use in spoken communication is commonplace and subconsciously undermines the messages received by listeners. If you’ve never considered this before, you’ll now notice it everywhere, from radio presenters to work colleagues, and you’ll almost certainly be using “ers”, “ums” and “uhs” in your own speech. If you can stop yourself from doing this, your communication skills – critical for any good User Experience designer – will be elevated considerably.

User interface design

Test driven design

If you’ve worked with developers, you’ll be familiar with the concept of ‘Test Driven Development’. The basic principle is that the functional requirements of a given task or feature are used to create specific tests that the code will need to pass. The tests are written before the code, which helps developers know exactly what’s required of them and what level of quality is acceptable.

When designing a system, starting with testing in mind is a powerful way to improve usability and the overall user experience.

Usability testing

A practical guide to writing product usability test questions

If you have a well-developed wireframe, prototype or existing product, you can use usability testing to gather valuable data on the system’s user experience quality as well as identify any specific usability failings. Whether the tests are moderated or unmoderated, when it comes to writing task questions for the tests, there are rules that should be followed to ensure effective testing and reliable data.