I find myself of late working on two different categories of work: deep problems and social problems.
Deep problems (and this is totally my own definition) are the kinds of things that I tend to do solo. They involve strategic thinking around building a structure or a prototype or a hierarchy for something. Examples include:
- Site maps
- Detailed wireframes
- Short story writing
- Storyboarding
Deep problems are the things that I do where I have to do it before I can show it to someone. It’s almost impossible to pair-design a site map or a detailed wireframe, and while I know some authors can write stories or storyboards in groups, I’m not one of them (so far).
Social problems (once again, my own definition) are the kinds of problem solving that was designed for groups. They involve strategic thinking around building consensus. Examples include:
- Choosing a content strategy for an intranet (including scheduling, responsibilities, etc.)
- Gathering and prioritizing user needs and business goals
- Selling a product, idea, or solution
- Working out the differences in responsibilities between overlapping groups of stakeholders
Social problems, by definition, require me to work with others. I could specify a content strategy or outline user needs and business goals on my own, but there’s a really good chance I’ll get more wrong than I’ll get right. And selling or negotiating require another party to be present.
The differences between the two kinds of work are pretty obvious. Whereas one can be most easily completed if I lock myself in a room and buckle down, the other can most easily be completed if I surround myself with smart people and we take regular breaks.
The similarities aren’t as obvious. They are both strategic – both require a long-term vision of what needs to be done and where we’re going. Both are haaaaard with a capital haaaaard. Both require the brain to be fully engaged. Both are exhausting after 2 or more hours. And both require the other to exist; there’s no point in a deep wireframe if there’s no one to build consensus with (unless you’re building a product for yourself), and there’s no point in building a content strategy for something that doesn’t exist.
Both are showstoppers for the other type. Specifically, if I’m in the middle of a deep problem and I need consensus (“what is the highest priority for this set of info?” “What’s the long-term approach to this problem set?”) I’ll probably have to stop what I’m doing (or work around it) to move on. And we’ve all been in meetings where we’re still discussing consensus on something and failing because dammit, someone needs to draw a picture of it now in detail.
I find both kinds of work to be the good kind of challenging.
I’m pretty good at both of them.
If I have to pick a favorite, it’s deep problems, but even I like a good consensus problem once or twice a week.
The transition points, though, kill me.
Today I spent four hours in a social work meeting, building a content strategy and high-level information architecture with a set of close to a dozen stakeholders. When I came out of that meeting, I was supposed to dive right back into a deep information architecture for a new product.
And my brain said “Nope. Not in that mode. Please reboot and try again.”
The opposite has happened frequently, too. If I spend the morning building a site map for site A, and then enter an 11am meeting for the content strategy of site B, my brain will spend a half hour knocking on the inside of my skull yelling, “I AM TRYING TO THINK ABOUT A, WHAT ARE ALL THESE PEOPLE DOING HERE?” before I can change contexts effectively.
In fact, the only time I can successfully navigate the gap between deep strategy and social strategy is if I’m going into a social meeting to discuss the deep work I was just doing for the same project (or vice versa). Then the switchover is actually energizing, because I probably have a bunch of questions that need to be answered, and getting answers to those questions make me feel like I’m making progress on both the deep problems and the social problems.
I’ve learned to (try to) sort my calendar by project so that a given day will be dedicated to that project and that project only. Monday is project A, Tuesday is project B, Wednesday and Thursday are A, Friday is B.
When I’m successful, I can stay in the context of a single project all day, and the transitions between deep problems and social problems for that project are smoothed out.
When I’m unsuccessful, every meeting is a fight against my brain’s desire to go back to the deep project it just left, and every visit to my desk is a fight against my brain’s confusion that we’re exhausted and alone now.
Ultimately, I’d love to only have one project at any given time, but that’s so far out of my control (as an enterprise UX designer) that I consider it impossible. And maybe that’s okay too, because while the transitions are painful, the variety can be sort of nice too.
