Make sure your own project will have stellar UX before helping others
A great reputation as a UX Designer matters more than an okay product release
Sometimes it’s necessary to watch your company release badly designed products rather than trying to help them. If you don’t, you might sabotage your chances to make a real impact.
Most UX Designers I’ve encountered tend to be enthusiastic about helping people. Our job revolves around empathy, understanding users, and creative problem-solving. As a result, it’s tempting to help projects that not only need our help, but ask for our services.
Maybe it’s a project other team members are working on that isn’t going well. Maybe it’s your work friend’s first time leading something. Or it’s a project you find interesting and want it to succeed.
But you can’t always help who you want. Trying to do that can land you in some hot water, as I almost found out. Despite your best intentions, it can be more damaging in the long run if you decide to provide help before considering what this means.
This is for two reasons. First, well-intentioned stakeholders might use the wrong language in describing what you did. This can lead to troublesome misunderstandings and a lot of extra work. Second, doing this extra work to end up with two okay projects is usually less helpful than one project with stellar UX.
An essential yet often ignored organizational resource is behind both of these reasons. It’s one of vital for getting others to adopt UX practices and advocate for UX: your reputation as a designer.
How fuzzy language can land Designers in hot water
Some of you have probably encountered team members who use different and inexact terms to describe what you’re doing or building. I’ve had my design mockups described as “Prototypes,” “Screens,” “Pages,” and “Designs” as a simple example.
Most of the time, it’s not worth it to interrupt meetings to correct them on the terminology. Using this vague language can quickly get you in hot water if you lend a helping hand. Last week, I talked about how something polished can often trick stakeholders into thinking something is further along than it is. However, this concept can also apply to lending a helping hand. And it’s because people don’t necessarily know how to describe what UX does.
Imagine that you wanted to help out another project, so you agreed to take a look at a project’s design and provide some input at a few scheduled meetings.
When that happens, you’re kind of stuck. You’ve stuck your name and your reputation to a project accidentally, which may need a ton of time and effort to be good. You then either have to throw work-life balance out the window to balance the projects you’re funded for and this new one or have you and your team now associated with a bad project. Neither of these situations is ideal. But the real damage comes from what happens afterward.
The invisible yet valuable resource that Designers have
Once a lousy product is released, and your concerns about the UX are accurate, there tend to be two parallel trains of thought going at the same time:
Who do we blame for this poor release?
What can we do to make it better?
The first train of thought is unproductive, and teams try their best to limit this type of thinking, but it still happens. Was it one person in particular? Were meetings not going well? Do we need to hire consultants? If you’re associated, as a UX Designer, with a project that has a bad design, you’re the first stop and most likely to get blamed. This can result in negative performance reviews, bad reputations, perceived incompetence, and more.
These are, of course, substantial downsides. But what’s sometimes worse is the follow-up: you know the problems this project faces, and you might have some idea how to fix the issues. But now nobody wants to listen to you or let you contribute: after all, with that bad reputation as a designer, stakeholders wonder if they can trust your input or if they should take your suggestions. In addition, other exciting projects that you offer your help to may turn you down.
Am I saying that you should never help anyone? Of course not: evangelizing the value of good design and UX often means we should be a helpful resource and take on side projects, especially in low UX maturity organizations. However, there is a massive difference between what UX could do, and what UX should do.
UX could review the mockups or even high-fidelity prototypes of a project going badly and offer suggestions to address the most significant issues in a piecemeal setting. This might cause the product to have fewer Usability issues.
But UX should position themselves to be in a place to effectively help so that if you have the opportunity, you have a chance to create a product that offers a great User Experience.
How do you position yourself to be in a place to help effectively?
I blundered into this answer when I almost found myself in hot water because I was fascinated by another team’s project. But I was saved by my (very angry) mentor, who should be your starting point.
How to position yourself to help effectively
Show interest and screen projects through your mentor or manager
I previously discussed how the first person you should talk with when you want to help should be your mentor.
The reason why is simple: you’re being funded (and approved) to work on a specific project.
Sponsors, like Product Owners and Managers, manage payroll, not to mention time, access, and other resources, to make sure that the project you are assigned to has a great User Experience. So you don’t want to be making them angry by dragging down the quality of your priority work.
One of the most common ways that people run into trouble with these projects is not knowing the cadence of how projects work. It might seem like you have a ton of time in the early stages of the project, but it might be that the release date for both projects might be on the same week. As a result, there’s no way you could be available for both projects simultaneously.
Managers or mentors are more likely to know this, and this is a great way to make sure you’re not overloaded. However, sometimes managers (or other team members) are the ones that are trying to introduce you to these other projects. What should you do then?
Explicitly spell out how you’re focusing your time and effort
People sometimes aren’t aware of how much work goes into user research, design, and iterative testing. As a result, sometimes your manager (or product owner) may suggest working on another project.
One example of this is working with multi-team projects. A project may be so big that multiple teams (Team A, Team B, etc.) are working on different aspects of the larger project. If there’s a lull in one part of the project, someone may request your services in another. But sometimes, the reason that they’re requesting your services is that one aspect of the project might essentially need a fundamental redesign.
So one thing that you can do to make your life easier is to take the UX case study approach with your manager to spell out how we should allocate time and effort explicitly. For example, you should spend 75% of your time on project A, with project B only taking up 25% of your time.
Having a meeting to discuss this (and possibly generate an e-mail) can help provide some guidelines and a reference if the other project starts to require more of your time. This way, it’s clear to leadership exactly how much time and effort you can devote to helping with this project.
However, there is one more approach that we can use in conjunction with these methods that can be effective, even if it’s painful. Sometimes, the most helpful thing for designers is to let a lousy product be released.
Bad product releases can help push design forward at your organization
I mentioned that there were two parallel trains of thought once a bad product is released:
Who do we blame for this poor release?
What can we do to make it better?
Having a good reputation can make you the first person they contact for that second train of thought. If you (or the UX Design team) have a track record of excellence with the products they work on, you may be the first people they turn to (and fund) to help address some of these issues.
This not only avoids the previous problems of working on non-funded products: you may go into the project with several UX Advocates in the making. After all, some of them may have been on the team where everything failed. If that’s the case, if you show how the design process helps make things better (just by doing your job), they may advocate for UX being part of larger and more critical projects.
So while it may be a little painful at the moment, sometimes it’s better to let a bad design release. Doing so might allow you to have a significant impact in the future.
Kai Wong is a UX Specialist, Design Writer, and Data Visualization advocate. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.