Transform Your Design with Unified UX

Unless you’ve been hiding under a tinfoil hat for the last few years, you probably know that UX and UI are not the same thing because “UX is more ergonomic”, or some such nonsense. But what about the unified part? Normally speaking, I’ve got very little patience for hipster acronyms and nit-picking, but actually it turns out there’s more to this than fake specs and chai latte.

Imagine you’re standing outside two different coffee shops. They both sell pretty much the same coffee at pretty much the same price. How do you choose? Well I’ll bet you a unicorn frappe it’s not one specific thing that sways you, more a general “feeling” that “it’s better”. And you know what? That’s UX.

It’s probably time to rethink everything

It’s probably time to rethink everything. Experience has become much more important to users than product, and from a design perspective, this puts software in pretty much the same space as coffee shops.

For the service industry, each user-brand interaction is a touchpoint. It’s not important where or how that interaction happens: seeing the shop, opening the door, speaking to someone at the counter, whatever. The aim is to create a feeling of familiarity, ease and comfort for the target user.

Now imagine scaling that experience. Say you wanted to take your coffee shop into a mobile vending unit. How can you make sure that your users get the same feeling of comfort and familiarity that they had in the high street? That’s Unified UX.

The Broader Context

Unified UX is much more than a DLS or style guide. In fact, you’d be better off thinking about tools like Atlassian and Sketch as…well, tools, to help you achieve the broader aim of unity.

It’s more than responsive design and digital ecosystem too. If you’re still thinking in terms of “mobile”, “tablet” and “desktop” configurations, you’d do well to heed the words of design guru Cameron Moll who urges us to recognise that, for today’s users:

The best interface is the one within reach

Take the Galaxy Fold, for example: Phone, tablet, phablet or plain old monstrous? What about Echo, Dot and Alexa with no screen at all? Or Apple Watch? As Cameron points out in the same talk, the concept of “TV” has also become pretty loose. Do we mean the content, or the device it’s viewed on? Is “mobile” a noun, a verb or an adjective? How is a native app different from a mobile browser experience?

The point is, from a unified UX perspective, it doesn’t matter. The job of the UX team is to create that “brand feeling” across all platforms and in all facets of the design.

Take a look at Southwest Airlines’ “Virtual Booking Desk” from — wait for it — 1998; laugh all you want, but remember that back then, most people were completely new to the internet. Seeing a familiar scene gave users a sense of confidence, which is (still) integral to the Southwest brand.

What Goes in to Unified UX?


It starts with deep awareness of the needs, expectations and current experience of the user. Watch people using your stuff. Talk to them afterwards about what it felt like. You’ll definitely learn something. If it’s a new project, do focus groups, then do some more. Co-create if you can.

From there, develop a design principles framework. The key concerns of your user group should shine through in every single aspect of their brand experience.

Broadly, there are two key concepts to unify:

  • Form and Function – Yes, you need both!
  • Data Symmetry – Data should follow users.

Here are some questions to consider:

Available Media

How do your users want to interact with the brand?

  • Android/iOS app;
  • Voice Interface;
  • Live Chat;
  • Bot;
  • SMS integration (very popular in the US);
  • Telephone/VOIP;
  • Video;
  • Print Media;
  • Face to Face.

A website doesn’t work for everyone!

Look and Feel

Does your framework include:

  • color;
  • shape;
  • imagery;
  • story;
  • art direction;
  • icons?

Do your choices work everywhere? How do you balance unity of UX and compatibility? How do you merge native OS elements with brand-specific ones?


Guide users to the content they’re looking for. Will their needs change across:

  • platform;
  • device;
  • time;
  • user journey?

How do you balance usability and unity of UX on small screens?


Are some features device specific?

  • Camera;
  • Location Services;
  • Accelerometer;
  • Compass.

If so, is this what users want? How will interactive behavior transfer?

Responsive Behaviour

Remember the device continuum – it’s usually best to think in terms of

  • small;
  • smallish;
  • biggish;
  • big.

(Not specific devices.)


Important for:

  • Written copy;
  • Voice Interface;
  • Phone Help;
  • Face to Face;
  • Video;
  • Text or Automated Chat.

Does the tone need to change in certain situations:

  • errors;
  • call to action;
  • feedback/complaints;
  • specific user groups?

Are you using dated words like “click” when “tap” would be a better choice?


If the user starts an interaction on one device and transfers to another, does their data follow them? If shopping cart items, elapsed time, favourites etc are consistent across interfaces, you’re doing it right!

Single Sign-On is one of those features that’s bound to make your users smile. With this in mind, are your protocols up to scratch? If you’ve got a native app, you need LDAP or similar, for example. Don’t try and use cookies! Is the backend architecture able to handle the load?

Development Environment

As you probably see by now, unified UX isn’t something you can do by yourself. The better organised your resource repository, the easier it will be to onboard new team members and maintain consistency. Consider:

  • Toolsets;
  • Documentation;
  • Coding and File Naming Conventions;
  • Standard Elements Repo.

Upgrades and Integration

How will you update legacy material and add new elements as the design evolves?

Who’s Doing it Well?

Yes, unified UX can be a pretty large and expensive undertaking, and even the giants still get it wrong. That said, here are some nice little highlights from a few unexpected places:


No surprises here in terms of the company’s size, and sure, their UX is (arguably) pretty slick no matter where you find it. But what really caught my eye today is their commitment to their backend and support for third party developers.

This gives Spotify users enormous scope to enjoy a highly integrated, reliable and ever-expanding ecosystem that always feels the same.


Not only do they have great cross device, cross platform consistency, their famously chirpy tone and loveable mascot are instantly relatable. What’s even cooler is that, when something goes wrong, the tone subtly changes.

This isn’t surprising because they have a really extensive style guide for new writers.


Primarily a web-based translation application, their iOS app is a real favourite of mine. It not only offers dictionary-style definitions, but use-in-context translations as well, which really helps to avoid the classic google translate failures. It’s understandable at a glance on both small and large screens… and it’s free!

Good evidence that simplicity and functionality often win out.

Conclusion – Why Bother?!

Well, in a nutshell, because it’s what your users want. Yes, to really nail a unified experience is a big undertaking, particularly if you’re coming into an old project and dealing with legacy code, but the fact is, it’s the future.

The range of available devices is growing rapidly, and users want whichever one is closest. At the same time, we’re becoming more and more sensitive to experience, and less tolerant of inconsistency or nuisance. Smaller companies must find ways to provide the kind of unified experience that customers expect, or face being swallowed by giants.

As independent developers, it’s in our interests, and within our ability, to find ways to make UX unified.


Featured image via DepositPhotos.


p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

Leave a comment

Your email address will not be published.