How to deal with an Engineering team that is outpacing your designs
How “Slow Productivity” taught me to deal with people rushing me for designs
Cal Newport’s new book, Slow Productivity, helped me during a time when everyone wanted to rush my design process.
This is one scenario every designer will encounter in their career. Whether it’s the Product team trying to rush you or a super-productive Engineering team, someone will always want to rush your design process.
This is because of two universal truths about any Design job:
Design takes time
There are more Engineers on the team than Designers
Learning to deal with this pressure is necessary to grow as a Designer, but it wasn’t until I read Slow Productivity that I understood how to help others deal with it.
Slow Productivity and a quiet revolution to how I approach work
Reading Slow Productivity has essentially been a capstone towards a slow transformation I’ve taken towards work.
It has been stressful suddenly becoming a UX team of one (in a team of a dozen Engineers) and trying to launch a course on Data-Informed Design. There’s this hidden pressure that makes me feel guilty that I’m not working extra hours, late nights, and weekends to get everything done quicker.
However, as a father of two young toddlers, my time isn't flexible. Every day, I have 1–2 hours for my course, 7–8 hours for work, and the rest is spent with the family. Whether it's a holiday, weekend, or a workday, my schedule hasn’t changed in 6 months (aside from not working on weekends).
According to Cal Newport, that’s enough to get quality work done. Slow Productivity centers on 3 major lessons that have helped me re-contextualize and make slow progress with everything I want to achieve:
Do Fewer Things
Work at a Natural Pace
Focus on Quality
Making those 3 lessons the heart of my design work, along with how I think of my limited time, has allowed me to address user problems and create great designs, even when there’s a ton of pressure to “not fall behind Engineering.”
The first step is to go against your Design training.
Do fewer things: Chunk Design work to match Engineering output
One of the things that many teams may do when Engineering is outpacing Design is to start to ‘work ahead’. After all, while the UI may be upcoming, some Engineers may be worried about questions like:
Does the Back-end Code support this type of work?
Are we getting the sort of data that the UI will want to visualize?
Is the data structured in the correct format?
What interactions can we support?
Etc.
As a result, Engineers think differently about pages than Designers do. Designers are often taught to think about the entire workflow: We consider not only the particular page we’re designing but also how it’ll affect the rest of the pages (and be consistent with the rest of the application).
However, Engineers often consider these tasks (and subtasks) to be broken down (and put into JIRA tickets). After all, the Back-end Engineer will ensure the data is ready before handing it over to a Front-End Engineer.
One thing that sounds counterintuitive is asking questions to uncover one thing: What UI elements do they need to see first? The easiest way to think about this is by sub-features.
Imagine that you were designing pages about creating certain Policies. As a result, you might break the entire page into several sub-features:
Adding a Policy
Editing a Policy
Deleting a Policy
Referencing a Policy on a different page
etc.
As it turns out, Engineering needs a general overview from the Add a Policy workflow to get started. So, this is what you would prioritize first.
Does this mean you’re not thinking about the other features on the page? Of course not. All it means is that the “Add a Policy” workflow gets the extra polish.
Rather than working to create a fully polished “Policy” page, Make sure all the interactions and alignment for “Add a Policy” are ready first so that Engineers can start with that. When they’re working on that, that’s when you figure out the other features on the page.
Limiting the scope of your design focus to what the Engineer needs (to get started) is a way to ensure that they can at least get started with what they need on a page.
Yes, it would be ideal to tackle everything at once, but you must keep the second lesson—working at a natural pace—in mind. For some people like me, it’s the hardest lesson to adhere to.
Work at a natural pace: Designers aren’t superheroes
One of the myths contributing to being pressured is one we tell ourselves.
As designers, we often tell ourselves we’re problem solvers (and superheroes). We’ll arrive on the scene, gather some context and research, and then design something out of nowhere that will solve all of our user’s problems (after enough rounds of iteration).
It’s an idyllic version of design thinking, but believing in it too much can often lead to vulnerability around being gaslit.
After all, if you’re the problem solver and the team is waiting on you, doesn’t that mean it’s your fault the problem isn’t being solved? As such, you might be tempted to work nights and weekends to try and fix this problem because you’re the superhero who will solve everything.
I speak about this from experience: I would stay at the office until 10 PM, arrive at work at 6 AM, or work weekends throughout my career. Only after the birth of my first kid and the pandemic did I begin to reassess these things.
Yes, it doesn’t feel great when everyone’s waiting on you, but the fact that you do not have the final say helped spark a mindset shift. At some point, you need to re-group with a Product Manager or Executive who makes the decision.
When you realize that, you realize that everything doesn’t need to be perfect. All you need to do is get to a ‘good enough’ stopping point for them to decide.
Depending on the type of Product Manager (or where you are in the design process), it might take the form of 3–5 sketches of solutions for the first round of approval or a limited subset of features hooked up for interaction.
Whatever you do, ensure you’re not doing too much work (and wasting effort) on the earlier stages before you get buy-in for the actual design solution.
But what if you don’t want to give up imagining yourself as a superhero? You can still do so if you embrace AI-based tools for tedious work.
Focus on quality by having AI handle small and tedious tasks
Batman has his Alfred, and businesses hire assistants for one key reason: to tackle other, less important tasks so they can focus on the things only they can do.
Designers should learn to use AI-based tools in the same way. Whether summarizing meeting notes, compiling user research, or generating design artifact drafts, automating the tedious aspects of your job ensures that most of your time is spent doing the deep work that companies hire you for.
Even if you only have a few hours to spare, if you can devote those hours to Deep Work (another highly recommended Cal Newport book), you can produce a lot of quality work.
After all, design is often about quality rather than quantity. Digging deep to understand users' problems and designing solutions that address them can take dozens of hours normally or a few focused ones otherwise.
Otherwise, design workshops meant to uncover a project's fundamental problems (and goals) would take weeks instead of days.
However, by focusing our attention, we’ll truly be able to meet our team's needs and design a great solution.
Designers will face this pressure to hurry at least once in their career
There will always be more engineers than designers on a team simply because not all of them work only on the UI.
In addition, while teams might like Designers, they prioritize Engineering productivity when necessary. I’ve been bluntly told that we cannot have the engineers sitting around waiting for you because it’s expensive to do that.
So, part of being a designer is navigating the pressure to do quick, shoddy work to get something done. Product teams will give you promises like “Of course, this is just temporary, and we’ll go back and fix it,” and then promptly forget to do that.
This would normally be why I often spent extra time, long nights and weekends, to ensure everything was good, but I can’t do that anymore. So, if you can’t (or don’t want to) do that, following Slow Productivity guidelines may offer a potential solution.
Working slowly but deeply is a way to make great progress in design and address many concerns an organization will have around Engineering sitting around with nothing to do.
So, if you are feeling this sort of pressure, take a moment to re-group and see if you can structure your design towards slow productivity. This may be the counter-intuitive boost in efficiency that you desire.
I’ve revamped my Maven course to teach Data Informed Design. If you want to learn this valuable skill, consider joining the waitlist.
Kai Wong is a Senior Product Designer and creator of the Data and Design newsletter. His book, Data-Informed UX Design, provides 21 small changes you can make to your design process to leverage the power of data and design.
This is the exact pain point I have been experiencing. Thank you so much to write this down and sharing the same with some solutions. The amazing thing is the whole article resonates with me and make me conscious of the pressure what every Seniors designer might be going through throughout the world in tech lead companies.