After receiving my master’s degree in Human Computer Interaction from University of Michigan in 2014, I landed my first user experience (UX) role at VMware AirWatch as a UX designer. While I’ve enjoyed seeing my hard-earned degree put to good use over the last several years, I’ve also been confronted with a variety of unexpected challenges that many UX designers in my position have faced, all of which have helped me grow and continue to learn as my career develops.
While many UX professionals like me have no doubt run into many of these same obstacles, falling into bad habits can sometimes seem unavoidable. In this post, I’ll discuss the three most common missteps that I think any capable UX designer should steer clear of, regardless of their experience level or specific discipline.
[Related: Inside the Mind of a UX Designer]
After reading several articles about the mistakes UX “beginners” often make (and how to avoid them), I noticed a trend. Almost every article focused on design. Mistakes such as not paying enough attention to the mobile experience, designing with too many colors and using over-the-top typography seemed to be a recurring common thread.
As a UX designer for AirWatch, I’ve run into similar pitfalls. While I do get to work on a wide variety of high-priority, high-visibility projects that require my full attention, I’m typically involved in many complex projects, all of which I get to collaborate on with my fellow UX team members and various product managers. On most days, you’ll either find me in meetings with colleagues working as a “UX consultant,” or at my desk developing UX design solutions.
As I go about my business each day, I’m confronted with seemingly harmless scenarios. And somehow, no matter how much experience I’ve gained over the years, situations like these have a knack of sneaking up on me when I least expect it and derailing my progress on projects. So, when you think about your busy day and the situations you’ve run into, how would you the handle the scenarios below if they happened to you?
A product manager comes to your desk and asks if you’re available to work on a new project. Would you:
[tabs slidertype=”left tabs” fx=”fade” auto=”yes”] [tabcontainer] [tabtext]A.[/tabtext] [tabtext]B.[/tabtext] [tabtext]C.[/tabtext] [/tabcontainer] [tabcontent] [tab]Greet them with a positive attitude and immediately commit to the project? “Sure, no problem. I can work on that.”[/tab] [tab]Immediately reject the request and tell the product manager that your manager didn’t mention this project to you, so it’s not your responsibility?[/tab] [tab]Tell them you need to meet with your manager before committing, but meet with the product manager to get a better understanding of the project and its scope? Then, find out from your manager if this is something you should be working on full time, as a consultation or not at all?[/tab] [/tabcontent] [/tabs]
When I first began my career, I definitely would have chosen A because being helpful is simply in my nature. I wanted to be seen as a valuable resource that my colleagues could rely on. But, sometimes when I would tell my manager about a request like this, I would learn about other projects that had a higher priority that I didn’t know about, which meant I wouldn’t be available to support the request. As a result, I’d have to go back to product managers to tell them I couldn’t do it. So much for being seen as a valuable resource.
In my opinion, the best approach to this situation is C. You can still meet with the product manager to understand the project and then report to your manager about what you’ve learned. If your manager has time, you can even invite him/her to the initial meeting to help you prioritize and determine your role in the project.
Partnering with key stakeholders is critical to the success of any project. The last thing you want is to develop a reputation as the department of “no.” Avoiding option B is definitely a good idea. Not only does this approach exhibit a fairly passive-aggressive work ethic, but also it puts unnecessary stress on your relationship with product managers, which is never a good thing.
[Related: Building Great Technology Starts with Building a Great Team, Part 1]
You’ve just had a successful kickoff meeting with a product manager. You’ve received requirements, competitive insights, preliminary user flows and use cases and agreed on a timeline. Two hours later, the product manager suddenly tells you the project has become a rush and needs you to deliver wireframes three weeks earlier than originally agreed upon. Would you:
[tabs slidertype=”left tabs” fx=”fade” auto=”yes”] [tabcontainer] [tabtext]A.[/tabtext] [tabtext]B.[/tabtext] [tabtext]C.[/tabtext] [tabtext]D.[/tabtext] [/tabcontainer] [tabcontent] [tab]Agree and start working on wireframes immediately? “Sure, I can meet that deadline. No problem!”[/tab] [tab]Tell them you’ll get back to them, but you’re not sure when?[/tab] [tab]Say you don’t have time to work on this project for this sprint because you work better when you’re able to focus on one project at a time?[/tab] [tab]Explain that you need more time to work on the Information Architecture and flow diagram first to figure out where to place this new feature in the workflow?[/tab] [/tabcontent] [/tabs]
Everyone loves the rock-star glory of meeting a tight deadline. But as UX designers, the value we have to offer goes far beyond just creating wireframes, as in option A.
Diving right into design without any context is like heading on a long journey without a map. It’s important for us to get a firm grasp on user flows, do some research and get feedback on preliminary concepts from customers to develop a solid Information Architecture.
With condensed project timelines and competing priorities, it’s easy to see why so many of us fall into the trap of creating wireframes immediately. But, it’s important that we don’t lose sight of all the other things there are to consider before creating the layout of a page.
To offer up our best solution, we don’t want to completely avoid the predicament by being aloof or non-committal, like in scenarios B and C. But, we do need to give ourselves the space we need to do the necessary research to make sure we’re doing the right things at the right time and in the right way by taking a similar approach to option D.
At VMware, we always stress the importance of shipping products with the confidence that we’re delivering the quality and value our customers actually need. Without conducting any research or talking to customers, we’re simply designing solutions in a vacuum without any consideration of the real-world problems we’re seeking to solve.
[Related: Breathing New Life into UX Research]
Congratulations! You’ve made it to the wireframe-creation phase. Now what?
[tabs slidertype=”left tabs” fx=”fade” auto=”yes”] [tabcontainer] [tabtext]A.[/tabtext] [tabtext]B.[/tabtext] [tabtext]C.[/tabtext] [tabtext]D.[/tabtext] [/tabcontainer] [tabcontent] [tab]Completely immerse yourself in the creation of wireframes? It’s just you and your wireframes. You spend your days looking at wireframes from every angle and try to make them better and better, while waiting to get feedback from the team at the next sprint meeting.[/tab] [tab]Research similar pages in the category and the field overall? You develop a few conceptual directions and share them with other designers, engineers and product managers to get their feedback. You keep iterating, meet with the project team to review your wireframes and look for opportunities to show your wireframes to customers to get insight, too.[/tab] [tab]Create wireframes that solve the path of least resistance, then wait for the product manager to set up a meeting to review with the team?[/tab] [tab]Create high-fidelity wireframes with as much detail as possible? It almost looks and feels like the final product. This way you can avoid too much back and forth with others on the team, since most tend to view high-fidelity design as nearly complete or finished.[/tab] [/tabcontent] [/tabs]
Did you choose A? Been there, done that. It’s easy to get consumed with your work, but a lack of communication results in a lack of input and feedback from other cross-functional stakeholders. The reality is your design will be more much thoughtful after incorporating other points of view. After you’ve thought about every aspect of the design, share it with others, and you’ll almost always learn something new.
A common mistake we make as UX Designers is the approach taken in option C. If you only focus on the happy path that you know most people would prefer or is politically correct, you may neglect potential error states and unexpected detours that may exist. It’s important to think about every possible outcome that could happen on screen, because guess what, it will. Always try to take a proactive approach to help users recover from errors in your design. Think about what it’s like to be in their shoes and consider the options that would make your life easier if you were.
And, if you thought that jumping right into a hi-fi design, like in approach D, was a better way to get ahead of the curve, what if you happen to be way off base? At VMware, we avoid this approach. Instead, we begin with low- or mid-fidelity wireframes and allow other key stakeholders to weigh in with their feedback as much as possible so we know we’re heading in the right direction. We keep iterating, and when the team has reached alignment on the overall approach, our visual design team begins work on the hi-fi mockups.
The correct answer on this one is B in my opinion. Noticing a trend here? Be collaborative and do your homework. Being inclusive of other stakeholders’ points of view and researching the best possible solution to satisfy your customers’ needs has the best chance of resulting in end products that will truly make your customers happy, and that’s something the whole team can get behind.
[Related: 2017: The Year of the Digital Workspace & User Experience Technology]
Just because you’ve finished reading my post, doesn’t mean you and I will never make mistakes like these again. My best advice is to be self-aware of how you approach scenarios like these in your day-to-day interactions. Reflect on what you did, why you did it and how you can do it better so every day you feel like you’re making progress to becoming the best UX designer you can be.
[Related: Building Great Technology Starts with Building a Great Team, Part 2]
Want to tell others about UX pitfalls you’ve encountered? Share your UX missteps below in the comments area.
