Leveraging UX as a competitive Advantage

Listen, you probably get it. You’re on a designer’s website, looking at their Nth project, you probably understand the importance of UX quality in shipping projects. So while this is preaching to the choir, seeing importance of design thinking is not a universal attribute for product teams. Nowadays, design, user experience, and accessibility are very real market differentiators. Design-driven companies have proven to outperform the S&P 500 by 228%. This is from one of those incredibly expensive Forrester studies.

The product I led design for, Microsoft’s Partner Center, is comprised of tools our users depend on to flourish. Not only is experience quality is a direct reflection of how a product organization cares for its userbase, but users now expect refined, high quality, and bug-free experiences from just about everything, yes including the output of a top three technology company. Even if it is “just productivity.”

We talk about user delight quite a bit in this industry, but I’m here to tell you that delight isn’t rooted in (only) cute button animations and relatable marketing copy. In the productivity space, delight is going to be derived from users being able to reliably complete the tasks they need to do for their job. Delight is driven by consistency and efficiency.

Partner Center has a number of issues that affect the perception of quality. I’ve mentioned the challenge of having a very small design team attached to product of this breadth and depth, and figuring out how to scale the team involved shifting our operating model to be more focused on foundational initiatives. So how do we build towards increasing quality while having the design team work on fewer features? Yikes, that’s a hard one, but if shipping excellent products that delight our users is the outcome, establishing minimum UX shipping criteria for new or updated UI seems like a really good place to start.

That’s going to require rigorous bug identification, tracking, and resolution. And probably a cultural shift. 😬

but How?

First we had to create documentation for what UX and UI best (and worst) practices are. In creating these, we identified six key categories:

• Accessibility. Accessibility bugs are when an experience is a mismatch for a user’s abilities or backgrounds. Common occurrences could be insufficient contrast for a user with color vision deficiency or UI that assumes certain cultural knowledge.

• Consistency. Pages should be built with the standard components and page templates. If a user sees inconsistencies from page to page, it reflects negatively on the portal and organization’s professionalism.

• Navigation. If an entry is mistakenly added to top level navigation without validation, or if navigation elements are implemented contrary to published guidance.

• Tone, voice, and terminology. Hey maybe don’t use so many acronyms and non-standard jargon. Oh, and error messages have to be human-readable.

• Style & aesthetic. Style and aesthetics go together like peanut butter and chocolate for designers, right? This one can be pretty wide, but use of non-standard colors or type ramp and messed up spacing are all good examples.

• Performace. If a site feels slow or doesn’t give the user the right amount of feedback, their minds will wander. This happens subconsciously and automatically! Brain science!

Then, as we identify bugs, we prioritize them by looking at frequency of use and number of users affected. I should mention that I meant the “royal we.” My team is certainly not resourced to do this by ourselves!

Now that we know what a bug is, we can log them and triage them. Important to note that product teams need to resource for this and account for UX bug fixes in scheduling. Seems pretty basic, but if I’m mentioning it here it means it wasn’t already happening in a standardized way. All new or updated UI is validated by the UX stewardship team, but the expectation is that bugs are logged and fixed prior to making it this far. While reviewing the new features, a UX certification report is generated. Any bug rated as Priority 0, Priority 1, Accessibility, or identified from an area of high business importance during planning will need executive exception. Very harsh!

Wrapping it up

Shipping a quality project is going to require constant engagement with everyone involved in the shipping product, at any point in the products lifecycle. But there are special responsibilities for different disciplines:

• The design team is responsible for maintaining guidance.

• Program managers are responsible for tracking bug closure and identifying projects meeting the definition of ready.

• Programmers/developers are responsible for implementing fixes.

• And the leadership team is responsible for staffing and resourcing appropriately.

I believe this is a cultural shift, and so the most important thing is that the majority of people involved believe in the cause. Just like Santa Claus.