IF YOU COULD ONLY HIRE ONE UX PERSON, WHO WOULD THEY BE? WHAT ABOUT TWO? THREE?

One of the most common questions I’m asked by growing companies is “if we can only hire one UX person, what role should it be?” I break it down thusly:

If you can only hire…

One: A generalist with strong Interaction Design (IxD) competency if not a full on IxD

Two: Another generalist with strong Visual Design (VxD) and research skills.

Three: Depending on the company’s needs and/or appetite for research, either a dedicated VxD or a dedicated researcher

Four: Whichever role wasn’t hired in the previous step

Five: Again, depending on the company’s inclinations, ideally another dedicated researcher. If not, then another dedicated IxD.

Once you get to four or five, it’s time to start thinking about seniority and more segregated specialization, but that’s beyond the scope of this case study. For Sphera, I needed a team that could simultaneously untangle the mess of several disparate legacy products while simultaneously collaborating on foundational collateral. We inherited a fantastic senior level VxD from an acquisition and the budget allowed for two additional hires: ultimately a senior level IxD with an associate level generalist fresh out of a UX boot camp. This handpicked team was perfect for the challenges we faced at Sphera.

PASSWORD REQUIRED DUE TO NDA
CONTACT FOR PORTFOLIO REVIEW ACCESS

Building on the initial UX framework, next came what is arguably my most important piece of work during my tenure at Sphera. The Sphera Cloud UX (SCUX) Style Guide served as a central repository for all things UX at Sphera. It included:

• The UX framework
• Verbose descriptions of each element, component, and system detailing when and how to and not to use each
• Visual examples of each element, component, and system
• Code snippets and construction guides for each element, component, and system
• A style section comprising language usage, colors, iconography, and fonts
• An appendix containing further information for those interested in learning about UX

To the left is a link to a deprecated early version of the style guide which was created in HTML, PHP, CSS, and JavaScript by me before the rest of the team was hired. Since then, the style guide was migrated to to SharePoint to allow collaborative editing with my UX colleagues.

The SCUX Style Guide was based heavily on IBM’s Carbon Design System as it is the single best system I’ve found to use as a base for enterprise level software. Unlike the trendier Material Design, Carbon is much more accommodating of real-world cases involving big data sets and obnoxiously large numbers of records. Material Design, on the other hand, tends to be much more tuned for smaller, idealized boutique apps.

WHEN LIFE HANDS YOU LEMONS…

As mentioned in the very beginning, Sphera was in dire need of some UX discipline. However, they were at the same time highly resistant to suggestions, especially when it came to research initiatives. As quantifiable user research is central to any reasonably competent UX team, we needed to find way both to change the minds of the leadership team and find non-traditional ways of gathering the all important voices of the customer. To do this, we embarked on a two-fold mission of UX evangelism and alternative research tactics.

UX evangelism took place in many ways. In addition to the major deliverables described above, we gained traction in other ways. Firstly, by providing useful assets and consulting input to the development teams, we were able to quickly help them understand that while we were ostensibly taking away some of their decision making power when it came to design decisions, they were in turn receiving a substantial boost in productivity as their time could be focused solely on programming instead of designing. This additional productivity more than made up for the “additional asks” that UX teams are often notorious for bringing to development teams.

In addition to ingratiating ourselves upon the developers on an everyday level, we also prepared a presentation to the company as a whole to explain what it is that UX does, what it doesn’t do (UX is not simply putting “lipstick on a pig”), and how best to work with us. You can view a pared down version of our presentation to the right (with personal information redacted for privacy).

Lastly, we found our research efforts stymied often, given flawed (but common) excuses such as “there isn’t time, we’re losing customers” (yet we don’t know what they even need), “if the users even get a hint that we might change something, they’ll panic!” (if we’re actually losing customers, wouldn’t they be excited to see that we’re making improvements?), and “we can’t change how it works, just make it look modern” (that won’t actually solve anything in the long run). Thus, encountering resistance when pushing for a traditional UX research plan, we started figuring out alternative ways to get what we needed.

One of the most helpful resources we found came from the sales team, who kept a record of every lost sale and the given reason why. While this hardly constituted a scientifically valid study, it at least gave us a place to start. That information, paired with traditional competitive analysis through heuristics evaluations gave us an idea of the places where our software was lacking in the broader scheme of the market. Armed with that information, we requested to sit in on any demo or interactions with users we could. Afterword, we would give suggestions on ways to ask better questions and started volunteering to help prep for upcoming sessions. Eventually, the UX team took over running the sessions entirely and we were able to get invaluable feedback directly from users.