I started as a self-taught web designer and attended many seminars, workshops and conference over the years. While each of them were helpful to varying degrees, many critical lessons were learned on the job. Here are a few.
Every project presents new challenges.
Every project has it's own combination of business needs, user expectations, team dynamics, tech stack, deadlines and various constraints. For that reason, I don't believe there is ever a point in a UX career where one can say they know it all. There are always new challenges and unique problems to solve.
Feeling nervous sometimes is normal; some call it impostor syndrome. I have mixed feelings about that label, but when I get that nervous feeling I know that I'm approaching a learning opportunity. I give myself grace and lean in.
Guidelines alone can't address most design challenges.
If anyone ever suggests you can effectively do UX work by simply knowing design guidelines, give them the side-eye.
For some questions, guidelines are all that's needed. For the question "Is the text color on this button legible?" The guideline from WCAG states, "Ensure that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text." You can easily find a color contrast checker, adjust your color if necessary, and viola!
For many questions, guidelines are merely a starting point. For the question, "How should we label content on this hospice care website?" The guideline from NN/g states, "Speak the users' language, using familiar words, phrases, and concepts." This is an excellent and fundamental guideline, but you are still left questioning what labels to use and how to word the copy. The only way to avoid guessing and get answers to questions such as these is to talk to end users.
Clients rarely know what's best for end users.
The client, customer, product owner or anyone who makes decisions about what is being built, are rarely a good source for learning all that the end users need and expect. Even if they are an end user themselves, their perspective is biased by their vested interest in the business needs.
Let's say you're hired by a wedding photographer to build their website. Yes, they interact with the end users all the time, but their perspective is clouded by their focus on promoting their most expensive packages and getting potential customers to share their email address.
Meanwhile, the excited spouse-to-be is focused on comparison shopping and getting a vibe from the photos and tone of the content so they can decide which photographers might meet their expectations. The last thing the spouse-to-be wants, in the first few seconds of visiting the website, is a pop-up asking for their email address.
Talking to some people who are looking for, or recently looked for, a wedding photographer can provide a wealth of insight about the users' motivations and what led them to choosing a particular photographer.
Skills are more important than tools.
I started out as a web designer and used Windows notepad to write HTML and CSS. It was years before I switched to web development software. Because I mastered the core skills, it was relatively easy to transition to Dreamweaver, Wordpress, MovableType, Joomla, and now Webflow.
Don't laugh but, for about a decade, I used PowerPoint to create my prototypes. During and after usability testing, participants commented that thought they were interacting with a real website. But nope, I'd plop my JPGs or PNGs onto the slides, then use animation and internal linking to make the images interactive. I've since moved on to Axure and just started learning Adobe XD.
Tools come and go, but skills are transferable. So, it's immensely helpful to learn core skills before (or while) learning to use particular tools.
All UX work boils down to understanding people.
When aspiring UXers ask me what they should learn to get in the UX field, I always suggest they begin with learning design psychology. Ultimately, design is solving problems and communicating with people who use a product, which requires understanding people.
First, understand people in general. Knowing human abilities and limitations in perception, memory, attention, learning, and decision-making is foundational to all design decisions and at the root of every design guideline.
Next, understand the specific people who will use the product. This is where user engagement comes into play. Talking to users to learn their goals, needs and expectations enable us to make informed design decisions.
Last but not least, we must understand ourselves. We all bring our biases to work with us. After we acknowledge we have them, we can make a conscious effort to counter them and not design solutions that alienate, offend or harm.
Other's design ideas are always worth discussing.
Everyone brings different perspectives to the project. Although, some explicit design suggestions don't account for the various requirements and constraints, what they spotlight is a problem to be addressed.
A request to, "Make the list exportable to a .csv file." could come from a person who is accustom to using spreadsheets and unaware that sorting and filtering might meet their needs. Whenever a user, peer, or stakeholder gives an explicit design suggestion I ask, "What problem are you trying to solve?" The discussion that follows is always very insightful.
Designs are rarely just handed-off.
I often hear people talk about "the design hand-off." I have yet to experience this. Perhaps works as a consultant and a design recommendation package is the final deliverable.
In my experience, what they refer to as "the design hand-off" is when a design is ready for implementation and the beginning of the next phase of designer-developer collaboration.
When the developers start coding, I work with them throughout the process to resolve unforeseen challenges and discuss design tradeoffs. Some things we discussed mid-coding have included, details of building a custom UI component, nuances of form field validation, and accessibility concerns.
The backlog is where UX work turns into UX debt & dies.
There was a time when I would hear, "Ok, we'll do that post-launch, move it to the backlog" and I thought the person shared my level concern about the problem but were offering a consolation because it couldn't be addressed right now due to time constraints. However, post-launch when I'd mention the UX debt, it was often met with eyerolling, sighing and gaslighting.
I quickly learned that discussing a design solution with the developers and finding out their level of effort was beneficial. Oftentimes, UX solutions are resolving an issue that has high user value and low level of effort. Presenting the issue, solution and the level of effort has helped me keep some UX work out of the backlog.
It's important to always be learning.
A few things that were NOT around when I started in UX: Nielsen Norman Group, Smashing Magazine, Stack Overflow, Career Foundry, General Assembly, Coursera, Bootstrap, Angular, Figma, jQuery, GitHub, Web Content Accessibility Guidelines (WCAG), Agile Development Methodology...
Things, people, and processes will continue to evolve. In order to maintain competitive skills and meet the needs of the job, we must continuously be in a state of learning and adapting.
Final Thoughts
This is a short list. I could write a book with all the things I've learned over the years. I won't, but could.
Takeaway: approach every day with an open mind, question your assumptions, embrace change, and go easy on yourself. No one has all the answers. Find a UX mentor or join a UX community and always be learning.
---
Thanks for reading. If you know anyone who would find this useful, please share. If you have any questions or feedback, feel free to contact me.
