My 1st 365 Days as an In-House UX Designer
(after finishing a design bootcamp program, like so many of you)
When I finished my design bootcamp program, I thought that the job I land would have me ideate-sketch-prototype-test-iterate-test all day, every day.
Well, maybe not every day.
But, the tasks would more or less happen in that order. This order was somewhat drilled into my head. And it was re-confirmed by the tens of portfolios I stalked before making my own, which highlighted this process map, or some version extremely similar to it.
My focus at the bootcamp I finished was on User Experience (UX) Design, and research was at the crux of good UX. The assumption was that research comes at the beginning of every project, and I assumed that I’d be there to do it.
That’s not always true. And that’s just one of the big things I learned in the past year working as an in-house UX Designer.
Insight 1: The truth is you won’t always have the luxury of being at the table from the inception of an idea to the implementation of the product.
If you get hired to work in-house, you’ll most likely be jumping into the process for existing products, or you might be jumping into the mix during a redesign. In my case, I joined my product team during a redesign when the majority of the design work had already been done. And done very well.
So now what? Going back to the drawing board is certainly tricky when everyone else on the team strategized at the drawing board in your absence. Sure, the fresh perspectives you bring will be helpful, but it is tricky to figure out which of your contributions will be relevant or beneficial at this stage.
If you join your product team at a time similar to this, what you end up doing has everything to do with which stage your individual product team and your overall company might be at with implementing UX practices into their product cycle. Individual product teams, and the company as a whole, may be at different stages of understanding, implementing or defining UX practices as it best fits their goals & needs — all of which might differ slightly from what you’ve learned are UX priorities at your bootcamp. That leads me to the next thing I’ve learned.
Insight 2: It’s very hard to prepare for what work you will actually be doing for your team.
When I did my design bootcamp, starting the project off with rough flows, sketches and then moving into low fidelity prototyping were quintessential elements of the UX training. Client projects moved at a fast pace, and the high fidelity mocks and prototypes were left for the visual designers on the team. The emphasis for UX Designers was to advocate for rapid prototyping early and often, to eliminate ineffective solutions fast before folks on the team moved onto creating high fidelity prototypes. Creating high fidelity prototypes was simply not a part of my training. My training had me thinking I’d be making lots of annotated wires that helps discussions between team members, and dedicating a lot of time to research before diving into user testing when I land my first UX job.
Reality was much different. When I joined my team, teammates were way past even the high-fidelity prototyping phase. Folks were waiting to build. So, the tasks that I expected to be working on simply were not priority tasks, nor did they really make that much sense at this stage. Industry standards have also changed; whether or not low fidelity prototypes provide value has also become questionable given the immense array of easy-to-use high fidelity prototyping tools.
So what happens now? Well, you have to learn how to best adapt. The pace of projects and the order of tasks are very different in the bootcamp world and in the real world. It takes time to figure out how you should start diving into different elements of your project in the post-bootcamp-and-at-my-first-job phase.
This also includes figuring out team dynamics and figuring out how you fit in, as well as how you articulate what you contribute to the team. If the product team you are with does not have experience working with UX designers, you and your team might wobble around for a little bit before feeling a bit more synced in terms of creating a smooth work flow between one another.
In fact, don’t be shocked if your team has no idea what you do, and why you’re there, even though you’ve been hired. I incorrectly assumed at my first job that everyone on my team not only has a clear understanding of what UX is but also understands the need for a UX designer on a product team. That was not true. I learned that sure, somebody clearly thought hiring for UX is a good idea, but that didn’t necessarily mean that the team had the same understanding as that somebody. People’s perception of UX exists on a very wide spectrum — from it’s-a-magical-solution-to-everything to what-do-you-do-again? That reality set me up for the next big thing I learned.
Insight 3: You may struggle with a case of the “Imposter Syndrome”. Mentorship from other UX designers may be the antidote to that terrible affliction.
The imposter syndrome is bound to creep up on you at some point — for legitimate reasons.
Over saturation of young-fresh-bootcamp-graduate UX designers and a high demand for filling senior UX positions makes the job landscape a bit tricky. On top of that, there’s this thing of being told that you are an expert in UX now that you have finished a program, have put together a portfolio and found a paid role. Everyone knows this is absolute bullshit but they go along with this idea anyways. You can’t be an expert in the thing you just started doing. Certainly, you are prepared for this role but it’s important to realize that five years ago the term “UX” was barely common. Many (most) people still don’t know what this role means, definitively. Being an expert in a field that is nascent is an odd claim. Again, everyone knows this, but it’s hard to find spaces where people will openly admit it.
This conundrum might set you up for a confusing path to navigate. And this is when feeling like an imposter creeps up. Is what you’re working on really the right thing to be focusing on? Are there things that you’re completely overlooking? Are you framing the problem in the right way? Is your process the most efficient way to tackle the problem at hand? Are you wasting time? Do you even belong here? Are you going to be fired tomorrow?
Those thoughts aren’t fun. We have a weekly UX hour at work that was set up by the Senior UX Designer within my department. It was at this space where I was able to fully explore my ideas, discuss the challenges I faced as a UX designer, solicit feedback on how to collaborate with my product team more effectively and learn how to advocate for my ideas more strongly.
When both the role and the field is nascent, it’s difficult to acquire a strong backing from stakeholders and even teammates about the utility of certain UX practices. I often worked on my own trying to frame a problem in a different way so that we could think of solutions in a more user-centric manner. The folks on my product team may have thought the approach was interesting, but they may have also thought that there are more important fires to put out. The truth is, you may work on things that your team may not value at all in the beginning, but a UX team will not only see the value but help you strategize on how to better articulate why what you’re doing is important. I truly don’t know how I would have gotten through this first year as a designer without that space of mentorship.
Conclusion: Success is measured by comparing where you (“you” as in the individual & “you” as in your product team) were a year ago versus where you are now.
When you’re finally at the job that you’ve been anticipating on getting after you’ve finished your grueling bootcamp, you may not be doing a lot of the stuff you thought you were going to do. You might also not be that fantastic at the things that you need to do (based on your team’s needs). This means being patient with yourself as you continue learning and being ok with figuring things out as you go.
There is a trend in product teams where designers are pressured to complete tasks as fast as possible because of resource limitations, while at the same time having to be really patient with seeing their work actually get implemented. The pace of project completion is one of the biggest differences from bootcamp to job world. When things move slow, measuring success can be a challenge.
So how do you do it? For one, it could mean comparing where the team & the department was with implementing and understanding UX a year ago versus now. Is there a little more in place to incorporate the user’s voice? Are people on the team taking that a little more seriously? Do they find that helpful as they design and build products? If the answer to any of those questions is a “yes” whereas a year ago it may have been a “no”, that means success. It’s indicative of crossing over an immense hurdle through consistent advocacy.
Teammates working with less friction is also a measure of success. As the UX designer, your skills in empathy are not limited to the end-user, but also to the dynamics of the team. Things won’t go far when everyone, including UX designers, behave as though they are the solo expert on a particular issue and their respective expertise is the most important element of the product. It sounds like a no a brainer but working with each other’s talents, instead of competing with them, lends to a more enjoyable process. The morale of the team as well as how folks on the team feel about working together will absolutely affect the quality of the product at hand. Improvement on that front, certainly, is an indicator of success.
