Thoughts on successfully implementing UI/UX standards

Developing brand compatible UX/UI standards is relatively simple. Successfully implementing them is not.

First, it is important to distinguish between UI and UX. UI consists of the visual elements of an interface. Colors, shapes, icons, fonts, etc. Creating standards for the UI from brand standards is trivial.

Thoughtful UX design has two tiers of complexity. The easy tier is very similar to UI, and consists of reusable interaction metaphors. Things like the navigation and the styling of widgets like select/drop downs, tabs, accordion panels, tables, pagination, etc., elements generally found in widget libraries like JQuery or Bootstrap.

This level of UX and UI can be easily distilled into a set of design standards and patterns so that product teams have a visual reference for updating current products and guiding development of new products.  At the very least the end user will not have a disruptive and jarring experience when going from product to product. There are challenges here - the design standards will need to offer compromises based on limitations of legacy products. For example, while products today are built to be “responsive,” so they adapt to difference screen sizes, older products may have fixed width tables that cannot be easily made responsive, or may be native applications with completely fixed layouts. So the goal should be to have standards that allow for compromise, accept mediocrity when one must (but document, track and prioritize fixes), while painting a vision for the future.

The more challenging tier of UX is how the system guides the user through a variable flow and produces the desired outcome, in a way that causes the least distress to the end user (and perhaps even “delights" them, but that is a rare occurrence and mostly lives in the minds of sales executives) and provides the desired value to the enterprise. The solution here is implementing a robust design methodology that requires a full and detailed comprehension of the problem being solved by the software system. This is not so much a standard as a practice, and often requires cultural change.

Which leads to the challenge of implementing UX standards and practices. When product teams are distributed, they tend to develop distinct sensibilities and characteristics, a result of things like remote management style, local management style, employee longevity/turnover, team competency, end user understanding/access, hardware and software skills required/preferred, the overall organizational culture and the local culture.

For example, some product teams can be insular and highly defensive of their product. Developers can be reluctant to implement even the simplest of javascript widgets if they have not done so before, and they will push back with excuses. Strong leadership (and technical knowledge) is required to prod these folks to execute to the standards. On the other hand, there are many hidden gems in product teams whose creativity is dormant and who yearn to implement techniques and designs they see being created by online peers or that they encounter everyday in mobile apps and want to do the same. Of course, many product teams are highly collaborative and will embrace anything that makes their product better — which creates another problem in that you have to manage the constant refactoring.

And that is just UX/UI design standards. A UX design methodology is much harder to operationalize, and needs to be driven top down to be successful. Since the methodology should require full understanding of the problem being solved, the processes captured and modeled need to come from facilitation with and direct observation of actual end users (anecdotal and third party observations can be woefully inaccurate, and even direct feedback may not be truthful based on the perceived seniority of the questioner).  So now you need to not only engage with the product teams, but customer support and sales as well, which adds greater risk, particularly depending on the nature and state of customer relationships. Often in enterprise software, the folks who approve the acquisition of technology for a particular purpose may use very little of the system themselves, or not at all. And frequent users who had little or no say in a system that has been imposed on them must suffer the burden of using something that perhaps was not the optimal solution it was sold as. Meaning, sales and customer service often hear very different kinds of feedback on UX and UI issues, and direct observation/questioning is the best way to understand how to refine and improve functionality and experience.

Bottom line, developing UX/UI standards are easy. Assess the products, incorporate brand elements, done. The hard part? Assessing and understanding the unique culture of each product team then developing an implementation strategy/plan (Inspire? Incent? Replace? Cajole?) to get them on board. And the key to success? Strong, strong, management support.