Your UX team and where it fits in the organization

Five things to consider when establishing UX within your business

Integrating UX with Agile software development teams is a challenge facing many companies. The “lean approach” or the “MVP” or continuous integration — whatever it is you call it — at the end of the day the goal is often to move fast, learn quickly and course correct and not lose sight of your goal to release a product customers find desirable.

One of the biggest challenges I see frequently is the alignment between the cadence of design teams and the development team. This is true wether you are producing a physical or a digital product. Both teams need lead time and definition for different reasons and once development effort begins it becomes harder to pivot. The cost of experimenting with features and functionality in production can be 10x in labor and resources, not to mention the cost of alienating customers, or flat out breaking something that may not have needed fixing.

“the cost of experimenting with features and functionality in production can be 10x in labor and resources”

1. UX IS NOT UI

UX grew out of the practice of Human Factors Engineering and Human Computer Interactions (HFE or HCI). It is common to see Research Analysts, Behavior Science, Consumer Insights, Industrial Designers, Interaction Designers, Information Architects, Creative Technologists and Graphic Designers on a UX team with each contributing to product definition in slightly different ways.

UI is a deliverable or an output that is often the most tangible thing that stakeholders can react to. However user experience is a multi-dimensional practice that spans many disciplines. Think of it as a toolkit to draw from in order to make informed strategy, product, and design decisions.

Fig 1. The Many Dimensions of the UX Tool Kit

2. UX SETS A VISION THAT ALIGNS TO A STRATEGY

Over the last five years I’ve seen UX starting to elevate as a key team member alongside business strategy and product definition. Predictions are that over the next few years “Customer Experience” will become a more competitive advantage than brand. Product design has become a primary influence on purchase decisions and this influence has become to a large degree an unconscious consumer decision. This is influenced by what designers refer to as “aesthetic usability bias”. A customer or first time user of your product makes an assessment of your product quality within .08 seconds. This is unconscious, largely visceral and driven by the perceived usability and usefulness of your product.

“a customer or first time user of your product makes an assessment of your product quality within .08 seconds”

It’s important to aim for quality when you release, the risk of driving customers away due to a bad experience isn’t worth the gamble.

Key things to consider and questions to answer while establishing your experience vision

What are the buying and usage behaviors of your target market segment.

Are purchase decisions driven by a need that is; utility, entertainment or creates a personal sense of status

What solutions currently exist and how do consumers use them. Is there an opportunity to improve on this solution.

Develop a prototype and test it with potential early adopters or loyal customers (7–10 tests that are representative of your segment should do it)

Paint a clear picture with the key experience moments and touchpoints that make up the lifecycle of consumer interaction

Verify that the solution is 1. Desirable 2. Useful 3. Usable — in that priority order

3. UX IS NOT HERE TO “SKIN THE WIRES” FOR DEVELOPERS

If you don’t have a design spec where does acceptance criteria for your user story come from? Not to say that developers aren’t wicked smart and some even have a great sense of design (I’ve been fortunate to work with a few) but in reality how many hats can one wear? The point here is that within the typical product development lifecycle the stages we move through to validate a market opportunity are much less expensive if we do it within a Design Sprint:

The idea that you can kick off a Development Sprint, declare a goal of producing an MMF (minimum marketable feature) by the end of it and have UX and development hit the ground running at the same time is a recipe for disaster. I believe there are two approaches to development 1) iterating on a mature product or 2) innovating on a new product. Both have different approaches that are appropriate to each.

The nuances of how you iterate and test, do continuos integration, deployment and so on are getting into the weeds a bit but at a high level teams are constantly moving through these phases to deliver and support products. They just approach problems at different times with different goals.

Discovery and definition are a balance of research, key stakeholders and product management. While design is working on concepts and prototypes in order to validate the product market fit. Once this is solidified those assets can become part of a functional spec. When you have validated learning put that together in the form of a UX demo and present your hypothesis, test and findings at the sprint kick-off with assets ready to rock.

At the very least UX should be one sprint ahead of development.

UX is equipped with a number of tools to create hi-fidelity protoypes that look and feel like the real thing and can be produced for a fraction of the development cost. Sketch, Invision, Axure, Zeplin, Dropbox, Keynote, Principle, are all inexpensive tools that can validate concepts without writing a line of code.

As much as your software gives you a competitive edge and is considered IP, UX practitioners also bring critical thinking skills to the table and should also be considered a source of intellectual property. They get deeply embedded in identifying problem spaces, market opportunities and making observations that result in innovative solutions or elegant designs that give you a competitive edge. A significant part of my role on pathfinding teams has been an expectation that I submit and file invention disclosures (and to be clear I am not an engineer).

Design is more than a coat of paint on top of a specification.

4. ACCEPTANCE CRITERIA SHOULD INCLUDE “KEI’S”

Key Experience Indicators are just as important as KPI’s. If you have benchmarks for the features, functionality or product you are delivering they likely have target lift goals associated with them. As some of the performance metrics associated with user experience are somewhat abstract and intangible I’ve started to try to incorporate KEI’s into the acceptance criteria for a release candidate. I think its important that we recognize the semantic’s here that a release candidate is just that, a candidate, it should hit the mark before going to production.

Some of the things we can measure are easy like page load time, latency, and time to task completion. Though some of the experience goals can only be measured through observation (that involves users outside of the building!!!). Does the release candidate invoke a visceral response like a smile, or a desire to share with a friend, or the relief associated with simplifying a complicated task flow.

5. UX IS A DEPARTMENT

Regardless of the size of your group you should start thinking of UX as a department. In over 16 years of software design and development I’ve seen a variety of flavors of organizational structures (likely too many) – the challenges businesses face integrating UX or the design practice in general though are what drove me to write this article.

Here are a few thoughts on Do’s and Don’ts in terms of “fitting UX in”.

DO NOT have UX or designers report to Engineering.

Why not? Good UX is focused on the “why and what if” questions of possibility and opportunity. Engineering is focused on the “how”. I believe that a healthy relationship here goes something like this, “Design challenges technology, while technology inspires design”.

DO NOT have UX report to Marketing.

Why not? While full of energy, excitement, enthusiasm and fun people marketing often is reactive, not very strategic and operates on a pivot or peril mentality. Work is often a fire drill. UX is a process and sometimes needs to follow a methodology in order to uncover the opportunity. (That said if marketing has a consumer insights or voice of the customer division — MAYBE they could align)

DO CONSIDER aligning UX with Product Management.

Why? Product Management gets it. Typically this is the toughest job in the house. Good PDM’s know their market backward and forward, have a deep technical expertise, meet frequently with customers and clients, are often held accountable to a budget and ROI and depend on UX to do the critical thinking necessary to bridge the communication gap with development.

DO CREATE a UX department, and have them report to an executive sponsor (if you can put them in R&D or Innovation)

Why? With UX as an equal footing stakeholder in the product vision and definition they can move from being responsible and accountable at the fuzzy front end to consulted and informed as the work gets approved and moves into development. Reporting to executive leadership or a senior level VP will also frankly keep the team from delivering crap.

If your UX team gets pulled into the weeds of stripping their product down to an MVP it becomes a challenge to evolve. Your feature requirements will focus only on those items in the “must have” column and anything labeled “should have, or could” will be discarded–and we all know V2 is a lie!

The stakes for your product to gain adoption are high. Perception, design and user experience are rapidly outpacing functionality and performance on the product decision scale. Exceptional performance and functionality are quickly becoming table stakes, what sets your product apart will be the UX and how it scratches your customer’s itch.