Month: June 2018

It’s almost 1am EST and I’ve just finished the late shift. That’s the term for those nights that, despite the best of intentions or planning, I’m logged in well past quitting time, cranking out wireframes or prototypes to hit a deadline.

Some folks say that procrastination is a form of anxiety, and that’s true for certain tasks. Not being able to drag myself out of bed in the morning to go to work is 100% my anxiety disorder (and so, for that matter, is not being able to drag myself to bed at night). Anxiety keeps me from leaving on time for social events, it keeps me from going to the doctor occasionally, it keeps me from opening the mail.

Anxiety does not keep me from cutting my wireframe deadlines razor thin. I love wireframing. Hell, I sort shit for fun.

Other folks say that procrastination is your brain telling you that you don’t have enough information to complete the task, and that’s much more the case for my wireframes (and my fiction). If I’m missing something, like a business requirement or an understanding of a piece of functionality, or even a basic concept, my brain will balk like a thoroughbred being loaded into the starting gate at the Kentucky Derby. Nope nopety nope nope nope.

My team’s been working on tonight’s project for, oh, at least a month, and most of that has been gathering research and requirements. The tool we’re building will have a customer view and an administrator view.

I’ve been literally sitting on the knowledge that I was going to need 50+ pages of wireframes to present the internal view of this behemoth for weeks, while I tried to figure out the user flows and the testable scenarios. I haven’t been sitting idle — I have process flows, content maps, spreadsheets out the wazoo, three fits and starts of related wireframes, a UX Designer and a UX Researcher also on the project, a bazillion Slack conversations with my PMs and my development team, and even a whole new set of Sketch libraries for this thing.

But not the wireframes. They sank into the swamp, repeatedly.

Last week, two things happened.

First, the development team got the vendor software running to the point that I could see what the back-end was expecting, and get a glimpse at the mental models the people who’d come before me were peddling. Finally I had a foundation upon which I could build with confidence.

Second, I looked at the calendar and went, “Oh shit, the usability test is next Wednesday night.”

And I was immediately reminded of the 10 page paper I wrote comparing a Shakespeare play and a play my friend wrote for a 400-level English class in 4 hours the day before it was due, for which I received both an A and a reading hangover that lasted two days.

And I realized that this was going to be one of those projects.

Sure enough, despite bashing my brain against the side of a bus-sized problem for two more days, I didn’t make any progress until Monday morning, when, for some unknown reason suddenly I knew the layout and structure of the site, how things were going to go together, and what patterns I was going to use. And from then until today around 12:30am, I spent almost every waking moment that I wasn’t in meetings stitching together the story that finally decided to rise from the swampy morass of my research and analysis and be something.

Huuuuuge tracts of plans.

Or if you prefer the racing metaphor, I ran away with it like Justify at the Belmont.

Admittedly, it’ll all change six ways from Sunday before it’s fully implemented. That’s the way of a first draft. You build it so you can edit it; you can’t manage what you don’t have.

But it’s done, and I’m done, and it’s still two hours earlier than I knocked off last night. And it’s not due until 3pm this afternoon so I’m finished more than 12 hours from my deadline (for a change).

And as much as #LateShiftUX is not sustainable, there’s something incredibly satisfying about raising a castle in the swamp and having it stand up, then handing it over the team with a hearty, “And that’s what you’re going to get, lad, the strongest wireframes in these isles.”

Yeah, I think it’s time for me to sleep now.

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.