Consulting Designer Survival Guide 101: How to Adjust to Consulting After Enterprise Work

When I started at Atomic Object in early 2026 (at the time of writing, this was only half a year ago), I was excited at the prospect of working for a consultancy. Previously, I’d only worked in enterprise environments, on a very specific part of the software, making only small adjustments to an already established product for years. There were no chances to complete the entire design cycle – the double diamond – that designers are so often taught in school. In a consultancy, however, there were more short-term projects, and many more chances to go through the entire double diamond, especially the Discover and Define phases, which are often the most interesting.

I was right about getting to do more of the entire design process, but what I did not expect was the sheer speed and volume of work that is the day-to-day of a consulting designer. Though the work itself was familiar to me, it was shockingly difficult to adjust to this new pace. And I find now that it’s a fairly common experience for Atoms, especially those who come from non-consulting backgrounds.

Here’s what I learned about how designing for consulting is different from enterprise, and how to survive your first few months as a consulting designer. It definitely gets better!

1. Design reviews: not only for sign-off, but discovery and discussion.

In my experience in enterprise, design reviews were where things were locked in and chiseled into stone– you were showing something after an internal design review within the design team, and presenting it to the decision-making stakeholders. The design reviews were about explaining something for the final signoff, to about three different groups of decisionmakers. The decisions happened slowly, and after a few weeks of work.

In consulting, however, the timeline from starting a design and design reviews were extremely short – in the current project, two to three days. I had a slight panic moment in the first few weeks – how was I supposed to match the depth and level of completion I’ve come to associate with design reviews?

With the help of more seasoned AO designers, I realized that the role of design reviews in consulting was slightly different – yes, it’s for decision making, and yes, your designs should have sound rationale. However, the design reviews in consulting were more of a discussion – sometimes putting things in front of clients to clarify requirements, and to reach an understanding. It was less of a presentation, and more of co-design / micro discovery session. The design can change after design reviews – in fact, most of the time, they should!

2. Design annotations: more lightweight, and more in person communication.

In my past enterprise roles, I used to heavily document my design annotations – they were like product manuals for new electronics, where every single detail is explicitly documented and explained via text so that it could not be misunderstood. This was because we contracted out the engineering team, so I could not work too closely with them and there was a few months’ lag between designing and implementation. My design documentation had to be self-standing, without me filling in any gaps.

At Atomic Object, however, we emphasize in-person collaboration, and my design annotations can be much more lightweight – explaining the limitations of something, or clarifying interactions, and there are lots of opportunities for developers to ask questions and poke holes into my reasoning.

3. AI-powered Knowledge Base can be a helpful reference to navigate a huge volume of information.

For me, the most difficult part of the speed of consulting is keeping accurate track of our design decisions. I will remember the big decisions we’ve made, but I won’t always remember smaller decisions like “what’s the language change for this button?”. But now, I can rely on our Knowlege Base of design review video transcripts and ask AI to pull relevant information for me.

Because I’m still skeptical of the summarizing power of AI, I’ll usually ask, “What did we decide on ______? Pull all quotes that mention it.” I can check the AI’s reasoning, and make sure it’s not making incorrect conclusions. This helps me put more time towards making actual designs and not hunting through notes.

Read here on how to set up a project knowledge base.

4. Obvious but not obvious: really respect your own offline hours.

This is probably fairly common among Atoms, but I go full throttle at work – it’s probably healthier to use about 70% of your energy for work, for long term sustainability, but I’ve never been able to do that with any part of my life. This means, however, that I’m pretty vulnerable to burnout. I know this tendency of mine, though, and have developed lots of strategies to prevent it. There’s no big secret to preventing burnout. As is all essential truths, it’s quite boring – you have to rest enough.

When I started at Atomic Object, I saw the intense pace and quality of work, and realized that I’d have to really respect my own offline hours like it’s someone else’s. If I can’t recharge, rest, and sleep properly, I can’t do a good job at work.

Final thoughts

Though my first few months at Atomic Object were somewhat overwhelming, I did find a good rhythm and balance with work that is sustainable long-term. Reflecting on and focusing on the core of what is needed for the designs and cutting out the distractions helped me streamline my process, and make quick, impactful decisions in my day-to-day. I hope you can also find a good rhythm within your work.

What are some things you do to maintain quality and speed of work? If you have an enterprise background, what are some key differences you see between being an enterprising designer and a consulting designer?