10 UXDERS, 10 QUESTIONS, 10 WEEKS

Week 2, Wish they knew: 10 UXDers, 10 questions, 10 weeks

Learn what our experts wish they knew before getting their start in UX.

PatternFly Team

Published in

PatternFly

12 min readOct 13, 2021

The title card for this week’s question, “What do you wish you knew before you started in UX?” featuring headshots of all 10 contributors.

Hindsight is twenty-twenty! Last week, we learned how our experts got their start in UX. For week two, we’ll ask about past insights to learn what they wish they knew.

Whether you’re a UX newbie or a seasoned vet, we hope these reflections help you on your UX quest.

What do you wish you knew before you started UX?

Wes: Research Operations Coordinator

When I started, it wasn’t necessarily clear to me that there’s a difference between research in academia and in industry, the world we live in at Red Hat. Academic research moves at its own pace. It’s more scientific and regimented, in that you’re looking to prove your hypothesis and turn it into publications. In industry settings, there’s a faster pace. You have deadlines and people waiting for you to translate your data into recommendations to make real changes in real products. Your results and how you present them impacts not only UX, but also engineering and product management — everybody is looking for them, so there’s more pressure. I don’t know how you really understand that without getting actual experience, so that’s where the value of an internship comes in. Search out those opportunities!
I heard this from a mentor, and it’s the most humorous and useful thing I learned in the industry world: Think about your audience. Think of your research presentation like a kids book. There’s a picture of a bear, and underneath it says “brown bear.” Identify what you see. When I was talking about translating your data from spreadsheets to research results and what that means to a product, how you tell that story depends on your audience. If you’re talking to your close team (designers or PMs, people closely involved in the research), you can go into as much detail as you want because they’ll want to dive deep. As you expand your audience, you really need to condense your style. You’ll want to have a graph, maybe a photo or screenshot of somebody using the product, and some bits of information that go with that visual. So you have a big animal picture, just like a kids book. It doesn’t mean you’re oversimplifying things, but you’re condensing it to the most meaningful point: What your results mean for the product.
If you have a question, ask it! If you are worried that these people will call you out for not knowing something, you are not in the right place — whether it’s a team you’re on, a meeting you’re in, or the people you’re surrounded with. Initially, I was very hesitant to ask questions when I needed clarification, didn’t understand the concept, or didn’ understand why a decision was made. I thought that asking would show some kind of weakness (it doesn’t). When I see people ask questions, it just facilitates the conversation. Everybody comes out better on the other end.

Beau: Principal UX Designer

Challenges are different in different verticals, like banking vs. retail vs. enterprise. Red Hat is a perfect example. Throughout the last two years, the biggest challenge has been getting customer feedback. The last project I worked on before Red Hat was a cell phone. You can just walk down the street and ask strangers if you can get feedback on your app. Everyone can give pretty valid feedback. When I started at Red Hat, there was a difference in product design, meaning the products we work on are tools that users use to do their job all day. These tools are their productivity tools. I think everyone should try working on a little bit of everything.
Within UX as a career, there are lots of different roles! You can be a UX researcher, visual designer, interaction designer… When you work with a bigger team, you start to realize there are even subroles within those, and you can find your sweet spot as you figure out your career. For example, there are designers on our team who really like screen design, advocating for everything from accessibility to some sort of consistency or standardization across the UI — I think of that as a PatternFly role. Then there are interaction designers who just love creating visualizations. For me, it’s zoomed out interaction design: How a user moves through their journey or products. I am happiest doing my work on a more abstract level, just thinking about how the user stitches together their experience from the first day they land on Red Hat’s website.
Take opportunities to pivot and be agile. Maybe you want to try screen level design. I don’t think we should ever get too rigid. It’s good to realize there are different sweet spots you could settle into throughout your career.

Roxanne: Associate Manager, User Experience Design

I wish I had a stronger development background. I did learn to do light development work and code. But I think, specifically for us in enterprise applications, adding an even stronger development background can never hurt. It will only aid in achieving your design goals.
Confidence. Just because the UX industry might be newer doesn’t mean that the experience I’ve had as a visual designer, or as a graphic designer, don’t apply. Avoid imposter syndrome and know that all that experience you have is leading you toward being a stronger user experience designer. Selling our ideas and designs we’re proposing is a big big part of the job, you need confidence for that.
Don’t be afraid of risks. I remember when mobile design was new, the other designers wouldn’t do it. So I did it, I thought it sounded cool and new. It actually was a huge bonus for my career and built new skills. The industry and technology changes so fast. Nothing’s set in stone. There’s always a new area of the map to discover. Change isn’t really risky, it’s part of what we do.

Alan: Senior Director, User Experience Design

I would have loved to have come in with better design skills. Things like ideation, for instance, you can’t get from doing a PhD in linguistics. For people who are trained in design, things like sketching are second nature. For me, I did take a drawing class and a painting class in the evening after work to gain at least some level of visual training. I did get good at putting flows onto paper and taping them to the wall, when we used to work in person, anyway. And of course we have digital tools to do that now.
Research is a great background for user experience work. I happen to have that because of the human-based research and studies that I did for my PhD.
I didn’t have a good sense of what it would be like to work in a group environment in an industry. I didn’t have a clue what that meant because my work in the psychology department would involve seeing hundreds of students a day, scheduling classes, talking to professors. The academic environment differs so much from industry. Knowing what that pattern looked like would have helped me when I was getting started. Working at Children’s Hospital didn’t give me a mental model of what it would be like to move into a 9-to-5 job. But it was all serendipitous — I all of a sudden had this opportunity to try working in a human factors group and I liked it.

Matt: Principal Interaction Designer

It’s a hard question to answer because I’ve been working a number of years and I have a lot of accumulated experience. In retrospect, I would have gotten into software and design earlier on in my career because I think that’s really where you have an opportunity to create products and applications that directly impact people’s lives.

Joe: UX Developer

There’s so much online content out there to learn from. It can be equivalent to a formal education or going to university depending on the course structure. And at this point, since most universities are online anyway, there’s not much of a differentiation. There’s so much focused content out there and a lot of the content provided is made to be easily digestible. Having that knowledge available is really important in opening doors to anyone who wants to participate in open source and coding in general. I like when I have time to take some sort of online course about something that I’m interested in, but don’t know enough about. Lately, I’m trying to get a little bit more CSS savvy. I’m a little bit heavier on the React side, a little bit later on the CSS side. In OpenShift, we use BEM naming for CSS variables. That was something I didn’t know too much about, but am learning.
Talk to other people in the industry to get a better understanding of it, because it’s not just about coding. There’s really more to it: collaboration, accessibility, focusing on design and testing, and being flexible with the outcome. You quickly come to realize that there are many other cooks in the kitchen when building an application or a platform. So you have to relinquish control, and let the process do its job and, as such, let the magic happen. Having other opinions is actually going to improve the overall product. So learning to be open to change, suggestions, and being open to input from different stakeholders is very important. Coming out of school, that’s not something that you understand.

Shiri: Senior User Experience Designer

Failing is part of success. It’s very important to understand that in the beginning you’ll fail because you don’t really understand the process yet. And that’s okay; it’s part of success. Knowing that would have helped me a lot in the beginning, because I was working as a sole UX designer, I had no one to consult with. I wish I had a pool of mentors that I could have asked for help.
The whole structure of the high tech company is hard to grasp at first. I arrived at Red Hat not really knowing what types of roles that the company has, and how they all combine into the UX design experience. Before you join a technology company like Red Hat, get familiar. Spend some time learning about the roles that will surround you.
When I started, I knew how to build simple websites or mobile apps. I went directly into a complex system, and I had absolutely no idea where to start. So if you go into this kind of UX design, don’t go in blind. Try to figure out a structure to get started.

Marie: Interaction Designer

I wish I knew that you don’t always get all design requirements upfront. As a designer, I’m the person who needs to take action and create a story from that information collected from other people.
Tools aren’t the most important thing to know. Start with at least one tool to learn the basics — you can start with Sketch and that’s it. I would recommend starting with something free like Figma. And then just if you get Sketch at work, continue in Sketch. There’s no difference. It’s not about tools, it’s about you. It’s about your brain.
If you have a great manager or leader on your product, don’t be afraid to lean on them. At the beginning, I was insecure about making decisions, but I could share my feelings with them. They helped me understand other people’s behavior, and taught me not to take anything too seriously.

Allie: Senior Interaction Designer

I wish I had a little more understanding of visual design, which I mainly learned on the job. Actually, in high school, I had to take an art class as a requirement and I did poorly in it. That teacher knew that I was trying my best, and I was planning to go into engineering, so she gave me a pass. She told me that if I were an art student, she would have failed me for the work I turned in. I still don’t consider myself artistic but I have at least learned enough to be a passing student.
I didn’t realize most of my job was going to be managing the relationship between stakeholders and developers. I sometimes have to prove why the things I’m doing matter. Maybe it takes longer to do another design cycle, but the end product is going to be better. Managing relationships and justifying the benefits of design from a business perspective was something I didn’t realize would be part of my design job, but ended up being a big part of it. The team I’m working with now has never worked with a UX designer. I understand their initial mentality of, “We’ve been doing it this long without you.” We compromised a lot in the beginning. Finding that middle ground built trust. Now, they don’t push back as much on designs that might change what they’re used to because they trust that I’m advocating for the right thing, our users. We’re all on the same side!
I needed to learn to trust my own instincts. I thought every project was going to start with user interviews and that there would be constant access to users. Unfortunately that’s not always (or usually) the case. I had to learn to trust that I have the user’s best interest in mind, and whatever I do is going to help make things better. For a long time, I was always striving for the best. But I have to be comfortable with just better.

Margot: Interaction Designer

Every project, every task is going to be different. Some are going to need more ideation, some won’t, because there might already be an existing project where you’re just adding a feature or a page to something already well-established. In school, there’s a step-by-step process you follow through to get to your final design. Real-life design rarely ever follows that specific path. I’ll sketch concepts out, but then I usually go straight into the high fidelity mocks. And I think that maybe partly is because, at Red Hat, we have PatternFly, so it doesn’t take us very long to create a hi-fi design. It’s not that what I learned in school wasn’t useful, it just takes on a different form now.
How much you work with other teams and developers wasn’t stressed enough when I was in school. I didn’t really ever think about who I’d be working with. I don’t think I realized how closely you, as a designer, are working with your developers directly to make sure that what you design is actually implemented. Or how closely you work with product managers. I don’t know where I thought those requirements came from as a student, but I’ve learned how flexible you need to be on a UX team. Sometimes you wish you could design something a certain way but you can’t because of technical restraints. It’s not just, “Oh, design whatever you want under the sun.” You have to make sure, with your team, that it’s going to work. And to do that, you have to spend time with developers to make sure you’re not designing something for hours that can’t be possible in the actual product.
Adding specifications and callouts in mocks is really important. No one’s going to get all the details from a mockup right off the bat. You need to point things out or they go unnoticed, and that’s something I could honestly do even more of in my own work.