I’ve learned from my HCI training that part of my role as a designer to take ambiguity and clarify it into solutions. But where is the line between stepping up and adding value, and where you’re doing other peoples’s jobs for them?
Designers wearing all the hats
Over the past year my organization has been going through a ‘digital transformation’. What does that mean? For the org, it means shifting from a model where digital experience was an afterthought, to where design is at the forefront of what we do.
Meanwhile, the internal design team has shifted from embedded designers in product teams to an agency model, where each of us is spending less time on a single product.
The combination of these 2 things means that our design team has shifted to an almost constant reactive mode, where:
- we spend energy on fielding requests — checking what is actually a legitimate request that should be worked on, finding polite ways of saying no
- managing all of our tasks gets complicated quickly, since as a small team of 4–5 that often partners with each other on projects (ex. a person stronger in ux with someone stronger in ui), we need to be cognizant of availability and deadlines.
- we have less built-in knowledge of product strategy, since we’re not as embedded on product teams.
Meanwhile, product managers haven’t had time to suddenly take on the tasks of what embedded product designers would help with, like:
1. defining product goals
2. defining product requirements
3. gathering user metrics
4. creating stories
5. writing acceptance criteria
6. general project management — ex. scheduling meetings for get enabler work on other teams’ radars.
So, designers are still wearing many of these hats.
Asking for help with all the hats
Over the last year, we’ve been asking in different ways for:
- better project management tracking, or a person who can better handle that work.
- better intake process, so we aren’t spending energy and time at an individual level to field these requests.
- less porous boundaries for incoming work, so that we aren’t constantly absorbing new asks or pivoting.
Does wearing all the hats help the organization?
A new design leader joined our team and brought a perspective I hadn’t considered: Many of the solutions we were asking for were about patching up leaky holes in a boat, but not fixing the boat itself. They were bandaids to treat a cancer. And us building the muscle of project and product management to treat this problem was just enabling this problem to continue. In fact, we were facing the brunt end of the larger problem of working for an enterprise company whose revenue was never tied directly to design or user experience, and only recently has started to try to shift to a user-focused model. Business leaders were suddenly throwing examples of Airbnb and Instagram as standards to emulate, without necessarily understanding that these companies have very different structure, people, and culture than our company.
Personally, I realized that over the past year, many members of our team had developed the ability to manage, track, and move projects along, and I considered this not only necessary but valuable. Because I thought it helped us from prevent the thousands of pieces falling in between the cracks. But while I’m sure it was helpful in the moment, I hadn’t considered how the design team being proactive all the time, turning zero requirements or a single haphazard sentence into real work was actually enabling business partners to ask for work that was not intentional or thoughtful. And I was finding that playing both product and design worked fine for smaller projects, but quickly broke down when we had large multi-department projects with external partners.
How to not wear all the hats (while keeping projects moving):
So, how do you know when you’re stepping up versus enabling? And how do you NOT step up when you know the work won’t get done if you don’t?
Drawing a clearer line between what designers should do and what business should do is a newer muscle for me, and I’m still not sure where exactly that line is.
BUT, when in scenarios where I can see the line clearly, here is the advice I received on how to handle the problem of the work not getting done if I don’t do it myself:
State exactly what you need.
ex) “Can you please phrase the notes in this email chain as user stories in the form of ‘as a [user], in [status], I need to [action] so I can achieve [goal]? so that I and developers can understand what feature this aligns to?”
Do the work (if it won’t get done), and show how you did the work
ex) “Here is an example.” or “I’ve done this for us here, please check.”
Simple, but I looking back I realized how infrequently I made these sorts of requests.
Summary
Of course, with every project and every company the line between stepping up and enabling will be different, but I do see now that while a design team developing tools, skills, and hacks to enable a consistently flawed organizational process can be immediately helpful and necessary, this process isn’t sustainable in the long term. In other words, we can get new tools or people to patch the leaky holes in the boat, but will be patching holes forever instead of doing other things, like steering the boat.
