UXperiences: A Quarter of Product Design Work
Three months of learnings, post-Designlab, in the real world
It’s been a while since I’ve written anything, and it’s because I’ve been super busy with work. Lots of people have been asking how the job has been, and while that’s an important question, I am way more excited to talk about the stuff I’ve actually used in Designlab in my actual work. (Background: I was in the Ive Cohort of UXA back in December 2016, and now I work at Udemy as a product designer after an internal transfer.) This is because I’m operating under this saying:
Be the person you needed when you were younger.
— A quote by someone from Twitter (credit attributed to Ayesha Siddiqi)
Framed a different way:
Please someone tell me if this UX thing is the right path and is it even going to be useful omg what am I even doing with my life and why are there so many different ways to learn it and why are all the definitions something like “WELL IT DEPENDS” and why is nothing straightforward
— Me, when I was first starting to learn about UX
As usual, there’s a TL;DR at the bottom, so if you want to skip to the summary, please feel free. And also as usual, disclaimer: this article details my own personal experience, and what worked for me is not necessarily going to work for you. Grain of salt, y’all.
So, what exactly do you do?
I’m a Product Designer at Udemy. I’m on the Enabling Platforms team, so yes, I am an enabler…of efficient workflows and building internal admin tools to help teams get their work done quickly while still minimizing security risks. It’s hard to explain this, since everything is NDA and I can’t show anything legally due to my contract. Imagine using a point-of-sale system, like a cash register; or the tablet app that a waiter uses to seat people in a restaurant. I’m building that sort of thing: tools to help get stuff done. If you’re interested, here’s where you can read the full story of how I got this job. I’m an internal transfer, so the process was different from going in cold turkey, so take that with a grain of salt.
In crits, I ask people what job they want after UXA. Some will say “product design”, and I wondered how many people actually knew what that meant, especially in relation to UX design, UX/UI design, etc. I’m working on a visual for this, but here’s an article that gives a short (and hilarious) explanation of product design and the expectations within it.
What skills did I end up using from Designlab?
This section is composed of: (I) Group crit facilitation; (II) all that PM/prioritization stuff; (III) a firm understanding of users and processes.
I. Group crit facilitation
We have 2–3 design get-togethers each week. One is on Monday to discuss what we did last week, what we’re doing this week, and if we have it, what we’re doing the week after. This stuff should be planned out quite nicely, because we have PMs that literally plan when they want to have certain aspects of a project done, often week by week. This is done by quarter, and that’s fit into the bigger projects that we hope to get out during the year.
The second is on Friday. That’s basically group crit time. If we need feedback from other designers, this is when we share our work. I’ve personally shared my UX research results with the intent of informing my colleagues what my work affects, because they may need to think about this as they design. We’ll sometimes ask for button placement, illustration questions, workflow, whether we’ve considered mobile, all that good stuff. The optional third one is every other Wednesday, and it’s the same as Friday’s except that it includes our remote team in Dublin, Ireland.
Am I biased? Yes, because I’m a group crit facilitator on the weekends and I freakin’ love it. But for real…this has become at least two days out of my week at work, too.
II. All that PM/prioritization stuff
This was a bit of a surprise to me, but I started when everything was in the middle of constantly shifting because of the usual tide of people coming in to a new role or leaving an old one, which makes everything crazy. I had no PM (but sometimes I had 2 to 3 at the same time), the director of my team was moving to a different team, we were getting a new director, and the Enabling Platforms team never had to work with designers before. To get things off the ground, my current PM (who, at the time, was balancing two full roles in the transition phase) asked if I could get some generative research off the ground so that when he started, he could have a resource to start defining problems and which ones to prioritize. That was the easy part.
But things don’t always work out as planned. My PM was trapped in his old work, desperately trying to tie up loose ends and hoped for a new hire to take his place, and soon. The director at the time understood this, but also asked me when meetings were meant to be set up to talk about our internal tools with engineering and stakeholders. So…guess who wrangled all of the cats from several different departments in order to get a kickoff meeting going? Yeah. Spoilers. Me.
Again, this all came as a surprise, but I was so glad I decided to make my own brief when I was in Designlab. That gave me a place to start, and I used my group crit skills to make sure that the meeting was going smoothly. Design, in this case, was there to ensure that everyone got a chance to speak, and that we talked about everything that needed discussing. It was also imperative that I could speak to the business decisions of why we wanted to approach these problems, and not just the why users wanted it.
III. A firm understanding of users and processes
I’m paired with a senior designer who used to work on tools for designers (which meant he was a great choice for building tools for platforms). Having him there has been essential in validating the use of some of the tools that I learned in Designlab. For example, as we were going through the empathy phase of work, he started explaining to me what empathy maps, personas, and journey maps were. The image below is essentially me:
He was respectful of what I knew, which I appreciated, and I made sure that I asked him about all the things I didn’t know. As such, we have a pretty good mentor-student relationship where he trusts that I will ask him when I need help, and I trust that he will help me when I ask for it. We were also able to acknowledge each other’s strengths (I’m insanely detailed with my documentation, so I always have an answer or know when I need to do more digging) and give feedback for what had to improve (I needed to remember to take a few steps back instead of focusing on what we were using, and focus on the when and why). It’s pretty great.
While our bigger projects are still really early in development — we’ve got the empathy down, but we’re still caught in between defining and ideating — there are quite a few “band-aid” projects I was able to tackle on my own. I worked on existing parts of the tools that had no design love, and specifically went for the “add/improve a feature” task. The challenge was ensuring that the changes were significant enough to make the users happy, but small enough that the engineers could crank it out within a short amount of time, since the whole old project would be scrapped for the new one in the future. The first three were always there: empathy, definition (provided by the PM), and ideation. There was often no time for formal prototyping and testing, but I did make time to at least sit down with stakeholders informally to show them what I had before shipping the changes.
What were things I learned on my own?
There’s a lot that you can learn within a course, but there’s a fair bit that you also need to learn either on the job, or by learning from people who are on the job. I attribute a lot of my success to being able to reach out to people I admired, which required me to learn how to talk to people. Talking has been 90% of my job so far.
Listening and understanding ALL teams = game changer
A fair bit of design sometimes feels like being a psychoanalyst. (This chapter from a UX Matters book sums this up nicely.) The success of many meetings I’ve been in have been highly dependent on the audience. Thus, it was extra important to ask myself if I was presenting something useful to them. Every. Single. Time. Am I talking with just the design team? A PM? Engineers? Stakeholders who have an OKR (objectives and key results) that they need product to look into if there’s time?
A massive part of listening and understanding your teammates is starting to anticipate what assets will be most helpful to share.
Here’s an example:
- Goal: I wanted to learn if the existing prototype was something the engineers could build within the short sprint time so that I could work on iterating and coming up with a final redline for the product.
- What actually happened: The engineers thought I was presenting finished work and spent most of the meeting time saying everything was not polished, and please come back when it is. I assumed my PM gave them the background, but either that didn’t happen or it wasn’t clear enough. Super uncomfortable for everyone.
- Outcome: I sort of got what I needed out of the meeting…feedback that it wasn’t polished enough and needed more work…but they also assumed I didn’t know what I was doing. I also sort of didn’t get what I needed, which was tech design direction, because of that miscommunication.
- Changes I made: Since then, I have made it a point to over-communicate why I’m in a meeting, what I am presenting, and what I want from them so that I can finish my work. I can trust my PM with this as well, but I will make sure I’m also giving myself cushion just in case. (As a side-note, but to be completely real: keep in mind that I do identify as female, which can certainly make things that much more complicated.)
Here’s an excellent article that’s meant to help PMs with storytelling, but was massively useful for me when putting together presentations.
Working with other teams and designers
This is something that pretty much all online education in design lacks: a team. As a student, I could try to emulate them all I want, but it’s no replacement for having actual people with actual skills that I don’t have to bounce ideas off of, negotiate, etc.
I’m lucky, because I live with a front-end engineer, a back-end engineer, and a tech lawyer. When I had questions during my UXA time, I could ask them for feedback and get excellent suggestions on future iterations. It was also great practice for being able to get into a discussion about design principles in relation to tech design (what engineers think about as they build); there were times when I would have to argue why I thought a design decision was important.
Working with a PM? Totally different from working with an engineer on the front end, which is different from working with an engineer on the back end. When jobs ask for “collaboration”, what they’re really asking is: “How did you manage yourself when group projects came up in high school?”
Okay, maybe not that verbatim, but that’s a pretty good indicator of collaboration. Were you the one who took charge? Did you help the person in charge by working together with what you knew? Or did you sit back and hope everyone else was going to do the work for you? My colleague recently shared the Six Thinking Hats system with me, and it’s a pretty excellent way to maneuver in any meeting.
Set boundaries early, and stick to them
This is something that I learned not in design, but in life. But it is really imperative that you do this in design, too. And yes, everything else in life. In terms of design, I learned this as a cautionary tale.
I was told that many designers, when they started out, did/do way too much work. As in, more than they were required to do. As in, they accepted a job with a very specific set of requirements, but then were expected to do a lot of other things on top of said requirements. There is a mindset that some people have where they think they need to say “yes” to everything asked of them, because they think that’s the way to get ahead in design. This is not okay for several reasons.
- If you take on too many things at once, your work suffers, which makes your mental health suffer, which makes your work suffer.
- You are the only one who can talk about your boundaries and what you can handle. If someone asks you to do something, get more information on why they have asked you and why they’re not doing it themselves (in a polite way).
- If you want to get ahead in design, consider your boundaries, and be proactive about asking for work. Specifically, the stuff you can actually handle in a given amount of time.
TL;DR
Skills I used from Designlab
- The most helpful thing you can do in a group critique is speak up. Silence does not help a design grow.
- The briefs on prioritizing made product design much easier, since I could communicate with my PM with ease in terms of timeline.
- A firm understanding of users and process goes a long way. Be clear about why you’re interviewing all those people, and what you’re using it for.
Things I learned on my own
- Being able to listen and understand all teams involved in the product design process. Sometimes it feels like psychoanalysis, but you really need to be able to read the room.
- Working with other teams and designers. This isn’t something online education can get you, especially if you’re learning on your own, so you need to be able to be scrappy, find those people, and ask questions about how they work with designers.
- Set boundaries early, and stick to them. Don’t burn yourself out by taking on every single tiny project under the sun, but don’t bore yourself by working on a project you don’t care about.
I meant to post this about a month ago, but clearly forgot, so I’m ending this here as my journey continues. As always, feel free to drop me a line!
