Optimize for confidence
We spend too much time at work to use bad software while we're there
I took on my first internship in 2016 after doing basically zero research on the company. I couldn’t have been more clueless on Day 1, and over my first week, I learned that I was going to be building software for an internal team at a digital ad targeting firm. To be clear, I do not recommend this approach to job hunting…
In complete honesty, I was immediately disappointed. At the time, I had my heart set on a career in consumer tech and was more than frustrated with myself for eagerly accepting an internship at a company that had so little to do with my future plans. But as the weeks ticked by, I started to enjoy coming in every day. A lot of it had to do with the team— to date, they’re still the best group of people I’ve ever worked with, and I credit them for teaching me everything I actually know about UX.
But just as much of my satisfaction came from watching our software make real, observable improvements in the lives of our colleagues who used the tools every day from 9 to 5. In user interviews, they would gush about how much easier their jobs would be once a new feature was launched. A real goal of our project was to reduce the number of profit-decimating errors that these account managers made on a daily basis in the original tool, and while it was good for the company’s bottom line, it was also good for the people themselves! Imagine if you made a five or six-figure mistake at your job every week. Would you be happy to go into the office each day, or would you be filled with dread every morning?
Americans spend around 1800 hours at work every year, which comes out to around 20% of every trip around the sun. If the software that we use at work is straightforward and helpful, we’ll feel more confident and capable at our jobs. If it’s confusing or prone to human error, we’re likely to be less assured in our roles, and experience more anxiety.
So that’s where I come in: I love working on work— building good software that makes us feel more confident in our jobs.
Optimizing for confidence
Yeah, that’s the tricky part. The point where someone feels confident at work definitely varies from person to person, but I think there are some common threads that most of us can identify with.
- Everyone wants to feel competent with their work.
- We all want our workplace to feel comfortable, not scary.
- Ideally, Sunday nights aren’t filled with dread, even if you’re not exactly jazzed to return to work.
Our teams, managers, and assignments all have a lot to do with our confidence, but I’ve witnessed firsthand how the tools we use can contribute to our confidence, too. Here’s what I try to keep in mind when I’m working through product designs.
Minimize jargon
Nothing is more demoralizing to a new employee than looking at a piece of software and realizing they need to memorize 47 acronyms and abbreviations. To the greatest extent possible, I try to reduce UI copy to the most accessible available terminology. If you’re thinking, “Well great, but how is this specific to enterprise software? Don’t consumer products do this too?” You’re right— this is not exactly groundbreaking advice. However, in my experience working on enterprise product teams, I find that this is usually one of the first tenets of good UX to go out the window. Don’t forget about it!
Sometimes, jargon is unavoidable— don’t worry, I live in the real world just like you. Instead of burying a glossary in your product docs, try using tooltips to easily add definitions to terminology that you think might be confusing for a novice user. In professional, enterprise products, this is the difference between a new user feeling excited to use your tool or dreading the idea of opening it up.
Prioritize hierarchy
Enterprise UIs can get exceedingly dense, which makes it even more important to treat hierarchy as the single most important design principle to nail. Treat each view of your product as specific to a context, and then ask yourself what tasks the user is trying to accomplish within each view. Optimize your visual hierarchy so that those tasks are easily distinguishable.
Sometimes, a useful exercise I put my designs through is a simple question: How much can I strip out of this UI while maintaining the user’s ability to accomplish the stated task? For each view, actually remove the elements that aren’t absolutely, positively essential. It’s not always best to go with the bare minimum, but this practice gets you out of a mindset of “The more information, the better.”
When all else fails, design the training
The simple reality is that some software requires training— sometimes, no amount of excellent UX design will get around that. Maybe the stakes are too high, and users need to know exactly what they’re doing before they start tinkering, or maybe they just need to get up to speed as efficiently as possible. Whatever the reason, creating a training curriculum should never be a hand-wavy, last-minute task. Whenever I’ve seen a product team procrastinate on producing quality training materials in parallel with the product, they’ve always had to stop everything to go back and do it later.
A great time to create training is during the final QA/polish phases, but it helps if you keep up with some of it during the product development cycles. I like to draft documentation at the same time a feature is being developed, and devote some time while engineering is working through QA to polish it up and make it presentable to users. Whenever you create your training materials, just make sure you devote the time and attention to them that your users deserve.
Ask the question
Often, the best way to understand if your UX efforts are working is to just ask your user— how do you feel when you’re about to use our product? Do they dread your tool? How sure are they that they’ll be able to accomplish their goal? Sometimes they may not have a ready answer, and this might be a great sign, too— if your app is emotionally invisible, it might be functioning exactly as intended.
Think about the after-hours
At the end of the day, my goal is to create tools that nobody ever goes home after work and tells their spouse about— unless it replaced a previously-awful piece of software and made their life a lot better, that is. My worst-case scenario is an exhausted user sitting at her dinner table explaining to her family how my product ruined 8 hours of her day or cost her company a lot of money in errors.