Deep Work - Lessons I will apply to UX Design
Last week, I finished Kal Newport’s Deep Work. I started out reading the book, but about halfway through realized I’m getting a lot of value from it and purchased the audiobook of it as well. This not only increased my retention of the material, but allowed me to listen to it while doing other things. I got through the book at least twice within three weeks, a relatively fast pace for me.
Deep Work had many takeaways for my career as a whole, but it seemed especially useful for running design processes. A key concept in the book is the title, Deep Work: it is both the state and the ability to concentrate on knowledge work, and is the opposite of a distracted state. Kal argues that deep work is becoming more important and more scarce in the current economy.
There is deep work in UX design
The first thing I considered was, which parts of my and my team’s jobs deep work applies to. Does my entire day need to be deep? When is the best time to schedule “shallow” vs. deep tasks?
One key activity where I see the most need for deep work is the Discovery phase of a project. Specifically, the second half - once we’ve opened up the playing field and outlined all the possible ideas and directions in which we could potentially focus our effort, we must narrow down to get to a realistic product definition. Kal describes this process as operating with many variables and considerations in our active memory. To keep this focus, we must perform deep work. Distraction at this point is very costly, because it requires a long time to get re-started even after a quick break.
Another key activity where I know deep work is needed is the wrap-up of a project. The last week of design work (let’s say we’re talking about a 5-6 weeks total) involves making detailed changes and refinements to designs, as well as looking at the big picture to ensure all needs are covered. The combination of detail focus and the “big picture” in the active memory is quite taxing as it is. Even a quick switch of focus to answer a question on another project will impact the quality or speed of the wrap-up.
There’s a time & place for less-deep work
In planning my and my team’s time I also need to consider activities which can be performed in a more “shallow work” mindset. While we could ideally have full focus all of the time, we do need to prioritize. Here are some things that would suffer less from a shallow focus mindset, and potentially even benefit from a relaxed, improvisational atmosphere, where group chatter and distraction can actually lead to new ideas.
Every project has some component of “poking around” or initial research into visual style, the industry, or typical interactions of a given type. (Do not confuse this with the deeper research and strategy efforts, which are focused on getting very specific, hard-to-find answers.)
In the middle of the visual design effort, with tasks and priorities lined up and activities somewhat predictable, shallow work may be acceptable. It’s still beneficial to keep sustained focus, but the cost of focus switching is relatively lower.
Collaboration and critique (also called design reviews) can be a great “shallow” activity. For example, when I check in with the team to see how their day went, I might actually benefit from having a shallower focus on their specific project. From this outsider perspective, I can catch “obvious” things they may not have noticed due to a deeper focus on the details, but avoid micro-managing and let folks be professionals and own their own work.
You may already be scheduling deep work
As I looked back on the way DockYard Design operates after reading Deep Work, I noticed that we’re well on our way to creating a system that supports deep work where needed. For example, when running design sprints, we go “offline” - meaning we’re less available on Slack or by email - for large chunks of the day. We also schedule time to catch up on shallow tasks around those focused times: a typical in-person collaboration would be scheduled 10–noon and 1–4, leaving an hour of our workday in the morning and afternoon to catch up, document and regroup with the team.
I also noticed (with no surprise) that a schedule heavily focused on management cannot be fully tailored to maximize deep work. There will be times when meetings, or urgent questions will take priority and the amount of deep work I can schedule around them will be decreased.
The main takeaways
If I were to summarize the key takeaways from the book, here’s what you’d see:
Schedule deep and important work in large, unbroken chunks of time first. Then, schedule shallower tasks together in batches around that.
Most people don’t consider their availability purposefully. With modern communication tools, we’ve become available by default, and it is costing us the ability to focus. If nothing else - question this assumption, and consider the consequences of allowing yourself to be distracted.
One interesting strategy to manage shallow work is to schedule a specific, limited portion of your work day to tackle shallow tasks. This way, the less-important tasks may not get done, but they will also not prevent you from achieving the truly important goals, which require deep work.
Kal proposes to measure the depth of any given task by imagining how long it would take a bright and energetic recent college graduate to train up to do the task for you. If the time is relatively short (e.g. taking a couple of weeks to learn how to manage a social media presence) then the task is shallow. If the time is long (e.g. taking several years to learn how to create original academic research or acquire insight to write a book) then the task is deep.
In conclusion - Deep Work questions many assumptions about the way we run our work lives, and proposes specific alternatives. The book is structured as such a clear logical argument (perhaps, owing to Kal’s background in the theory of computation and his academic writing) that it’s hard to ignore the advice. It felt a bit repetitive as I was listening to the introductory chapter (in a Dale Carnegie kind of way) but I’m now reaping the benefit of that repetition by being able to recite the argument back to anyone who’d care to listen. This is great book for any knowledge worker, and I’ve confirmed that it’s useful for anyone in a design role. I highly recommend it!