PART 1
UX lessons I wish I had learned earlier: Craft
They say “hindsight is 20/20”. It’s very true. 10 years ago I made the switch from graphic design to user experience after a 10-year stint working for print shops & manufacturing environments. It has been an incredible journey so far, but there are many things I wished I had learned earlier than I did. These are the top 30. I share them with you in the hope that you can avoid many pitfalls I encountered along the way and become even more effective at improving users’ lives than I am. For when any one of us improves, we all win.
I have broken these lessons into 3 categories: Craft, Job Searching, and Working With Stakeholders. There are 10 lessons in each category. In this article, I will focus on Craft.
To craft is to exercise special skills in making something. “Craftsmen” often spend many years refining their craft. They put some of their soul into everything they do. In times past, often apprentices would work under “master craftsmen” to learn and practice their chose trade before venturing out on their own. This quote on craft I think captures the sentiment perfectly:
“I think ‘craft’ is a word that comes with some weight. All types of apprenticeships that existed before modernity show us that we should see our work as a reflection of ourself. If you work with special care toward detail, then you necessarily ought to see that work as craftsmanship. If the mix you’re describing in a margarita has a good portion of man hours, study, and consideration poured into it, then perhaps it should be recognized as a craft cocktail. However, it’s not just about whether the ingredients are all natural. I think ‘craft’ is a reference to the nature of the worker and the care put into it, not solely quality ingredients.”
—Kala Alaeye Danae Ellis
UX designers apply ‘craft’ to their work as well. We put many hours (sometimes hundreds of hours) attempting to understand users and improve their lives in specific ways that somehow will increase revenue, retention, profitability, or stickiness. We partner with many other people to do this. We work under many constraints. Every designer is distinct and puts their own unique mark on their work.
Here are the top 10 lessons relating to UX CRAFT I have learned in the last 2 decades.
LESSON #1: There is no single design process, only a UX toolbox
Everyone has to start somewhere, so when we teach UX we talk a lot about “the design process”. Many books outline steps as if design in the real world were still using the Waterfall framework. This causes many designers to struggle when they get into the real world and there isn’t time for some technique they learned in design school or used at their last company.
The truth, though, is that there is NO single ‘design process’. There are only tools & techniques. Great designers are familiar with dozens of different approaches and pull out the right tool for the right situation. If you stop viewing usability testing, or wireframes, or journey maps, or mental model diagrams, or user interviews, or affinity brainstorming, or high fidelity prototypes, etc as steps in a rigid process, your life, and effectiveness as a designer will dramatically improve.
Naturally, this is harder to teach which is why this approach is rarely taught in schools. Knowing which tool to pull out in which situation (and which to NOT pull out) takes some time, but you can start today. Look up a new technique with which you are unfamiliar and experiment with it. Then at the end of the project find another designer, stakeholder, or trusted confidant and do a post-mortem or retrospective. Identify what worked, what didn’t, and what you would change next time. Consider if the problem was with the tool or with the WAY you used the tool. (A hammer wouldn’t be very effective if you held it by the head instead of the hand — the same thing applies with UX tools).
You may not often use every single tool you learn. Yet, there ARE situations where certain tools are useful and others are not. Experimenting intentionally will help you learn the difference. If you need some suggestions of tools to get started with, here’s a great list of UX Method and Deliverables, User Research Methods, and Effective Brainstorming Techniques.
LESSON #2: Research is important, but it isn’t a big deal
So many new (and even seasoned) designers get stage fright on testing day. We work ourselves up into nervousness because we know that research is important. Yet most of us also present our work to our team members and other stakeholders frequently each week to get feedback. Research is no different. We’re just talking to people.
A lot of the shift needed is simply in the mental model. If you get nervous going into research sessions, just imagine that you’re talking to an old friend or a coworker over lunch. Prepare, but don’t make research into a ‘big deal’. It’s simply a conversation between friends. This is a simple concept, but its impact can’t be understated. It can impact how effectively and how often you conduct research. This lesson is particularly relevant if you—like me—consider yourself to be an introvert. (There are many introverted UX Designers and Researchers).
The other piece of advice I have to help with getting nervous before (or during) a research session is to do them on a regular basis. The less research is a ‘special occurrence’, the less of a big deal it will seem. Work up to having some interaction with customers weekly. Get people excited about coming to observe. Make it something to look forward to and be excited about.
LESSON #3: User Research is more about getting to know users than testing designs
When I first started out in UX (like most designers at the time), I thought that user research was about “testing” designs before putting them into production. I viewed Usability Testing as a kind of Quality Assurance to make sure we were solving user needs. There are a few problems with that:
- You never are able to test a statistically significant portion of your users. (So it doesn’t serve as an effective ‘test’).
- Even though we try to do research “early and often”, if we are viewing research as “testing”, it by very nature is reactive.
- The true value of user research is about learning, not testing.
You’re probably going to want to push back against this idea. (I did at first, too). But if you remove your biases and look at it objectively, you’ll realize you already know it’s true.
Most of us UXers are always going on about developing shared understanding, learning from users, getting out of the building, the importance of observation and all the rest. Yet observing users purely within the frame of designs we just came up with causes us to miss the entire point.
Consider this quote by Jared M. Spool in his article A Fundamental Shift For Usability Testing:
“The real value of user research comes from increasing our understanding of who our users are. The product or service team should better understand our users with every study, every interview, and every interaction they have. They should constantly increase their understanding of what those users need and the contexts the users work within.
We can say that usability testing, at best, is a gateway drug. But if we focus on only finding problems and not learning more about our users, we’ll never get our teams hooked on the biggest value of user research.
Instead, we’ll lock them into this mindset that user research is just a variation of QA testing. That it’s about finding bugs, not about delivering better-designed products that truly meet users needs, whatever those needs are.
We need to move away from the problem-finding mindset. The teams that know everything possible about the users are the ones that deliver the best-designed products and services. That’s the mindset change we need.”
— Jared Spool, Founder of User Interface Engineering & Centre Center design school
I’ve found this to be true. The more you understand users, the better design decisions you can make and the less you need to ‘test’. That’s because you’re no longer making assumptions but making decisions on knowledge. That’s not to say you can ever stop doing user research because there’s always more to learn, but you can focus your research on being more and more proactive. It also dramatically improves cross-functional relationships because most usability problems get solved earlier and with more unity between cross-functional team members.
LESSON #4: You can’t (& don’t need to) research everything
One thing that causes a lot of us UXers stress when we first enter the workforce is the picture most colleges and bootcamps paint that research is vital. That IS true, research IS very important to delivering great experiences. We all have to understand the Jobs and Outcomes our customers are trying to achieve and the circumstances around them (as well as what is preventing them from achieving those outcomes).
The problem arises when we translate that to mean that we have to research everything. The idea that we can’t put any code into production without usability testing it, or start solving any problem without interviewing users is not compatible with the real business world. Not only that, but the cost of being wrong is not always the same. Some things can be tested in production. Others don’t even need to be tested because they’ve already been informed by existing data or research. As has already been stated, the true value of research is about proactively understanding customers anyways.
This results in situations where you start with a decently informed educated assumption of what will be impactful for customers. We should spend our time researching those things that, if we are wrong about, would cause our project to fail. Because of this, I have learned 2 important approaches whenever you have less time to do research than you would prefer.
Prioritize your research.
Rank each research goal by how certain/uncertain you already are about your assumptions AND/OR how big the impact would be if you turn out to be wrong. Reorder the list accordingly and decide what you have time for and what you don’t. If you don’t have time for something essential, then you have some talking points as to why you need more time. Most likely though, what falls off will be things you would like to research but that aren’t really critical at the end of the day. It has been my experience that if a tradeoff is needed, most often it’s the evaluative “testing” that ends up giving way to the discovery or “generative” research to inform your designs, (but I digress).
Create a Research Plan as the first step of any research project.
It always surprises me how many designers I meet that conduct their own research but have never actually sat down to create a formal research plan. A research plan has many benefits, including:
- Getting everyone on the team aligned on what you are setting out to learn, what are the questions you want to be answered, and what method will help you get there.
- Creates an objective you can compare against once your research is complete to show its value.
- Helps your research be much more focused which results in much deeper insights.
- Can even be a big help in securing financing for offsite research when needed.
The basic idea is to define the Objective, Assumptions/Questions, Method, Participants, Roles, Script, & Approach (and any budget needed if applicable). There are lots of resources available online about creating research plans, but if you would like an idea to get started, I describe the process I follow for creating user research plans and provide a 1-page Research Plan Template in my article here.
Contenting yourself with living in a world of time constraints with regard to research actually will unlock innovation rather than prohibit it. It will focus your research and make you much more effective. It also will help you make a good case to management in those situations where you really DO need more time for research. Maybe most importantly of all, it will help you be less stressed, happier, and more of a team player with your business partners.
LESSON #5: Balance business needs with user outcomes
Perhaps one of the biggest struggles many designers have is the apparent conflict between business needs and user outcomes. On one hand, business stakeholders (often sales, finance, or product leaders) bring up the perspective that we should focus on solving the needs of those paying the bills—our ‘customers’. The problem is that the approach they often take to this is just taking feature requests and signing an SOW (Statement Of Work) before anyone else is consulted. These are often very feature-focused rather than problem-focused.
On the other hand, we UXers usually take the perspective that we should be solving user pain points. That good UX is good business. We see hundreds of needed changes to make user lives better. The problem business leaders see with this is that often the users aren’t the ones paying the bills, so this approach doesn’t feel right to them.
So which perspective is most effective? In a word: both.
It IS absolutely possible to use customer needs to define the problems to solve, but do it in a way that improves user lives as well. This requires that business leaders define problems-to-solve (outcomes) for the team doing the work rather than feature-specific SOWs, and requires UXers to focus on improving user lives only so far as it will help achieve the desired outcome. (Everything else can wait for a future project.)
This is an entire article of its own—and I’ll be talking a little more about this in Part 2—but one other thing I’d like to mention here is that if you’re struggling with this problem, I’d encourage you to stop trying to convince stakeholders to help you solve your problems and start showing them how you can help them achieve their problems. Learn what they are most focused on right now and find a way to be a part of the solution.
LESSON #6: Pitching & ‘selling’ succinctly are critical DESIGN skills.
Like it or not, being able to ‘pitch’ and ‘sell’ your ideas is a critical part of being a designer. Something I didn’t understand well enough when I started out in design was that it was my job not only to design great experiences but to ship great experiences (or in other words deliver improved outcomes to my customers).
When you view your job as shipping, your whole outlook changes. You realize that every interaction with a team member, every design review, every demo is a chance to sell the value of what you’re trying to do. Through a LOT of trial and error, I’ve found the most value in selling the goal I was trying to achieve in a particular design iteration so if someone has a different idea for how I could solve that same goal that I might not have thought of, they can bring it up.
One other way you can get better at ‘selling’ and shipping great experiences is to become good at storytelling. People usually won’t remember facts and figures but they remember stories. Especially if they were told in a particularly meaningful way. Utilize a narrative structure with a story arc, and make the presentation memorable. If you’re presenting designs to a group of stakeholders, use the stories of real people from your research with their face, videos, and quotes where possible.
I had a professor in college who was teaching after a very successful career in the business world. She once told me that written communication, verbal communication, or both, played a major role in nearly every promotion she received or of which she was aware at every one of her employers. It’s one reason why I try to write as much as I can on professional topics. It takes practice to hone any skill. Selling and communication are no different.
LESSON #7: Focus on techniques, not software.
One of the biggest mistakes I see with designers—and it’s a very easy one to make—is that they confuse ‘tools’ with ‘software’. Part of this tendency I blame on schools and part of it I blame on recruiters. It’s so much easier to teach software over the myriad of design & research techniques, and many recruiters ask ‘what software packages’ candidates know because it is the logical equivalent of programming languages for a developer. This couldn’t be more misguided.
A great designer can solve design problems just as well on a napkin as in the latest software. I think I’ve learned a new software package (or more) at every company for which I’ve ever worked. This has affected my design approach very little. That’s because it’s the thinking that solves problems, not the tool you use to create the mockups.
I remember being surprised early in my career when I learned that roughly 80% of the effort of development work was ‘designing’ the code—or in other words figuring out how to approach a particular implementation problem. Once they have that figured out, actually writing the code is simple for all but the most junior software engineers.
Design is no different. Your time will be much better spent in experimenting with design & research techniques, understanding your users, and developing many of the other skills mentioned in this article, than by geeking out on the latest software package. Any good UX leader will assume you know or can learn software, but knowing how take a complex design problem with a list of constraints, lead the discovery work, rally your team around your research-informed vision, and make sure the desired outcome is delivered to customers, is much harder and much more important.
Just remember, success = outcomes, NOT mockups.
LESSON #8: There is no single ‘right way’ to do anything
I’ve wasted SO much time trying to fundamentally change the way companies do business. You hear a case study or presentation at a conference about Scrum, or Kanban, or Lean UX, or Design Thinking, or Design Sprints, or Jobs To Be Done, or the Spotify Model, or SAFe, or OKRs, etc etc and you immediately try to force your entire team or org to switch the way they’ve been doing things for years. When your experience in the real world falls short of the grandiose vision the conference presenter (or article author) painted, you get immensely frustrated and convince yourself your company just doesn’t ‘get it’. So then you move onto another company and the cycle repeats.
Why is this? Well at its core is the same reason why you can’t just blindly apply a design pattern you really like used by Apple, Google, Microsoft, or Facebook. Those were their answer to their problems, not yours. Joe Natoli once put it this way:
“Anyone that tells you that you’re going to radically change a company’s core processes — with convoluted, proprietary UX methodologies that require more time and more budget and complete authority—is flat out LYING to you.
Take the pieces from multiple approaches that work for YOUR situation, YOUR users, YOUR client, YOUR organization, and jettison everything else.
There is no single, correct way to do ANYTHING.“
— Joe Natoli, Give Good UX
LESSON #9: Design systems are about enablement, not enforcement
This is one so many of us get wrong the first time we design a Design System. It is very tempting to want to design a component library in a way that provides complete consistency, but that approach usually results in so much rigidity that other designers never really follow the patterns as much as you’d like. If it’s too rigid, they may not even use the system at all.
The argument over enablement vs enforcement in design systems is ongoing, but consider this: I’ve implemented 3 design systems myself and I’ve talked to design system designers at 10 of the Fortune 50—and they all have given me the same answer to the question “what would you do differently if you could do it over?” That answer without fail has been: “I would focus more on enablement over consistency”.
A design system is a product for other products, and like any product it has to work for its users and needs to be informed by research. Many design systems remind me of the old photo editing packages put out by Microsoft in the 1990s to try to compete with Adobe’s Photoshop which many found too complex to learn. So why are all those software programs obsolete and forgotten while Photoshop thrives? Because they were too rigid. In the name of simplicity they took away all effectiveness from the users’ hands. Many design systems today are no different.
The #1 thing that many design system designers forget is that there are many different ways to approach design and many different use cases (especially design systems for enterprise software). Consistency can be easy to maintain while the company or department using it is small, but once you try to scale it across multiple teams and tech stacks, it falls apart if it isn’t flexible. Designers and developers want to feel enabled, not constrained.
LESSON #10: Always question everything & be intentional.
This lesson is perhaps the most important lesson of all. The most powerful tool in a UX Designer’s arsenal is the question ‘why’? This is something many of us learn far too late after pulling out our hair in frustration. Just because someone asking you to do something outranks you by multiple levels, doesn’t mean you don’t have the authority to question them.
The core job of a UX Designer or leader is to comfort the afflicted and afflict the comfortable. One of my favorite phrases to use to soften the blow is “I’m just here to ask questions”. You can’t solve problems well that you don’t understand.
If an executive asks you to design a t-shirt, ask why. Is it to have something to give out at the next conference booth? Is it to say thank you to customers? Is it for employees to wear as free advertising? Is it to create employee pride & unity? Get to the bottom of what the purpose is, and then explore if that is the right medium to achieve the goal.
One of my favorite activities with senior leaders is to (politely) force them to sit down and frame their request in “How might we…” format. This does a couple things. First it gets them thinking in terms of a problem to solve, and second it carries with it a connotation that there are multiple solutions. I also like to use phrases like “we’ll get to the solution, but I’m just trying to understand the problem so I can solve it in the most effective way”.
As a design leader, whenever I get negative feedback about a designer by stakeholders or observe a lack of effectiveness in their ability to ship great experiences, almost always it’s at least in part because the designer has not done a good enough job at asking why.
Insatiable curiosity is one of the hallmark traits of great designers. One of my absolutely favorite techniques in working with stakeholders and in critiquing design work is ‘5 Whys’. Essentially the idea is to state a problem or idea and then ask ‘why?’ as many times as it takes to get to what you feel is the core cause of the problem. You can sound like a 5-year old child, but it is very effective.
Have something to add? Please leave a comment on the article or hit me up on LinkedIn or Twitter. Need a UX Leader to help guide your company’s UX Maturity? Need a speaker for your event? Check out my portfolio or contact me.
