Anne Gibson is an Information Architect and General Troublemaker for a large financial institution. Anne spent the first seven years of her career at the Production Support end of the waterfall process, and the second seven and counting at the Design end of the Agile process. She was supposed to be a famous English-teaching neurosurgeon veterinarian author when she grew up, and still isn't quite sure what happened.
Anne lives in the suburbs of Philly with her husband, and with two terriers whose hobbies include synchronized conference call barking. She writes occasional musings about design and development at perpendicularangel.com and everything else at @kirabug.
Walk it off
In March of 2012 I had a genuine bona fide nervous breakdown complete with violent behavior and suicidal ideation.
I was lucky.* One part of that luck came during a a crisis call with an on-call psychiatrist. When I said, "I don't know what to do with all these emotions," he said, "Go for a walk. Keep walking until you feel better."
I am a couch potato. When my parents told me to go outside and play, I took a book. My fastest mile in high school was 9 minutes, and 16 minutes was nomal for me. The only time in my life I walked regularly was college and that's because everything was in different buildings. Besides, exercise is for jocks and sports people, not a geek like me.
On the other hand, what else did I have to do? And what else could I do? When in crisis, "follow the doctor's orders" is usually a good start. So I walked.
I walked about a mile a day the first week, and then it grew to two to three miles a day, and over the months it grew to walking half marathons. Some months I might walk 2-3 half marathons in 30 days (not in competition, just to walk) and other months I might walk 2-3 miles or less a week.
When I walk, I feel better. When I neglect my walking, I don't notice anything for the first few weeks and then I start to wonder why my anti-anxiety med isn't working, and then I come to my senses and start walking again.
When I start walking, I'm usually angry. Sometimes it's at whatever has me riled up. Sometimes it's at nothing at all. (Brain chemicals are fun that way! "Why are you so mad?" "Because that's what the brain chemicals are doing right now!") Many times I'm angry because I have to walk, and that means I can't sit on my butt eating Snickers bars and playing Minecraft, which is a lot more comfortable.
I hate walking -- well, I hate walking the first mile and a half. Sometime around the middle of mile 2 the brain chemicals in charge of "not hating everything" start to kick in and I actually start enjoying walking. By mile 3 I've hit my stride and I don't start questioning my sanity again until sometime around mile 7 when my hips and back are beginning to remind me that I am not a 16 year old. At mile 9 I hate everything that ever lives. At mile 12 I just want to be done and at mile 13.1 I am amazed it's over and I lived. (At mile 16 I want to cut my feet off, take a nap, and eat a burger the size of my head.)
I have never believed in the phrase "Walk it off", as uttered by macho gym teachers and boys who just beaned me in the head with a football / basketball / dodgeball / etc. or as a solution to skinned knees, sprained wrists, twisted ankles, etc. that come from being a klutz trying to avoid said flying spheroids.
And I hate -- hate -- that something as simple as taking a half hour walk and drinking a bottle of water can change my mood. My body's supposed to be in charge of my brain, not my brain in charge of my body. Even after three years I'm still not comfortable with the idea that "me" is defined as brain and body, and I'm not a computer lodged inside a meat suitcase.
But in matters of depression, anxiety, stress, anger, and other not-so-awesome emotions, I grudgingly and proudly admit it works way more often than not.
The fact is that the brain requires certain chemicals in certain ratios to work properly. My brain won't hold those ratios without some kind of intervention. Walking not only helps me reset things when I'm out of balance in big ways, it also helps me maintain good levels when my biggest crisis is "I got toothpaste on my shirt".
Here are some places you can walk if you need to:
- Outside around your neighborhood
- Outside on your corporate-provided walking path
- Outside in the yard or on the road (but for pete's sake do it safely).
- In your house or gym or office or whatever on a treadmill or elliptical.
- In your office building. (Walk the longest chunk of hallway -- it probably leads to a stairwell -- up the stairs, down the long chunk to another stairwell -- and repeat until you've run out of floors. Then reverse.)
- At the mall. My local mall is a 3-mile lap if I do both floors.
- In your house, from the basement to the top floor and back.
- From your kitchen to the living room to the dining room back to the kitchen. (If you don't think tiny ridiculous laps are a thing, talk to anyone who owns a Fitbit who had like 200 steps to hit their number for the night when it was 11:30pm.)
- Anywhere you want.
Here are some things you can do while walking.
- Play Zombies, Run! Despite the title, there's no actual requirement to run. **
- Read. Yes, you can read and walk at the same time, especially on a quiet sidewalk or track. I'm currently working through Steinbeck's East of Eden and if that can be read while walking pretty much anything else can.
- Listen to audiobooks or podcasts if you're so inclined.
- Dictate your Great American Novel to your smartphone.
- Talk to friends or family.
- Work out the plans for how to do something creative not related to whatever's pissing you off.
- Get ice cream at a place at least 2 miles from your starting point.
- Analyze why some landscape designs work and others don't.
- Count the trees
When walking for mental health, injuries are our enemy. Here are some tips for walking.
- Get good running shoes from a place capable of analyzing your gait so you get injured less frequently.
- Replace your shoes as often as you're wearing out the tread. If you've worn the tread out, you've probably also broken down the padding on the inside, and not changing shoes at that point just invites more injuries.
- Bring water. Always. Even if you think you're hydrated. Because hey, water!
- If you're walking more than 3 miles or 1 hour, bring a snack. Runner-types call this "fueling" and I call it "not being hangry or passing out".
- Tell someone where you're going and when you'll be back.
To be honest, walking is not going to solve whatever problems sent me out on the walk. They're also not a cure for mental health problems and nothing in here replaces talking to an actual doctor and seeing a counselor on a regular basis. But as "tools in the mental health toolbox" go, it's one I keep on the top shelf.
* Some day I'll write about all that luck but that's not today.
I will say that a big piece of my luck came in the form of certain members of my family who had been down similar roads and had confided in me, and given me strict instructions on what to do when Shit Goes Wrong. For the record, those instructions were "Call me. And if I don't answer, keep calling until I do. And if you can't wait that long, here are other people you can call."
We have a standing agreement we could call each other in case of mental health disaster That agreement includes "It doesn't matter what time it is or where I am", "No judgements during the crisis - first we get to where everyone's safe." and "When the crisis is over, everyone will follow up with the appropriate health provider".
I'm not going to say it saved my life, but it sure as hell threw the odds in my favor. So if you have the opportunity to make an agreement like that with someone you trust, do it. »
** Zombies, Run! launched the week I had my nervous breakdown. That was another piece of luck on my part. I had a new game that required me to go outdoors and get sunshine while exercising, and I had a doctor whose orders consisted of "go outdoors and get sunshine while exercising". Obviously I didn't know I was going to melt down when I backed the kickstarter, but I am incredibly grateful that I had the right tools on hand at the exact right time to help motivate me to do the right things for my broken brain/body. »
If you forget everything else I've written for The Pastry Box, that's the one thing I hope you'll remember. You matter.
You are a valuable person no matter your race, the gender you identify with, the country you're from, who you find attractive, what religion you practice, how well you practice your religion, or what your education level is.
Your value is not dependent on the kind of work you do. It is not dependent on the volume of work you do. It doesn't even depend on the quality.
Even if you quit your job today and spend the rest of your life on your couch picking your nose and watching Married with Children reruns, you have an intrinsic worth that no one can take away from you.
It is not dependent on how many of your body parts are working "as expected". It is not dependent on all of the expected ones even being present. You can have a chronic illness, a mental health issue, a disability, or a temporary injury. You are not broken. You are valuable the way you are. You matter.
It doesn't matter what your emotional state is. You can be stressed, angry, happy, terrified, or in mourning. How you feel, and how you present your feelings, do not determine your worth. You don't have to smile for a stranger to be a valuable human being.
You matter regardless of what car you drive, what operating system you use, whether you format code with tabs or spaces, what sports you follow, what teams you follow, what your hobbies are, what languages you speak, what cuisine you eat, or whether or not you use the Oxford comma.
No one matters more than you do, because you are the only you we have.
Welcome to Enterprise
You work in Enterprise Software. You work in Design.
Your goal is simple: please your client.
Who is your client?
Your client is the user.
Your client is not the business client, product owner, project owner, or whatever your company has titled them who brings you an idea, a project, and a budget. You and that person are a team with a single goal: make life better for the user, so they give the company more money. Your product owner might think they're the client. You might even need to stroke their ego and pretend they're the client. They're certainly a powerful stakeholder that holds the purse-strings to this specific project. You need to work with them.
But if the project fails to deliver what the user needs, it's not the product owner who suffers, it's your user.
Your client is not your boss. (It's not your boss's boss either.) Your boss probably also wants to think that they're the client. They give direction and advice about what the managerial branches of the company want to have happen. They provide constraints, identify (and hopefully clear) impediments, measure your performance, and quite possibly decide your bonus or raise.
But if your performance doesn't positively impact your user, you've failed your client.
Your client is not the Executive Management Team although they certainly think they've got a say in the matter. They set direction for the entire company, deciding what large scale initiatives are going to entice the user to give the company more money, and deciding how that money's going to be spent. You must understand the direction of the company to see forward far enough to understand how it will affect the user. You must also know how to speak concisely and clearly enough that the Executives understand your user's pain. If that means data, bring it. If it means persuasion, join Toastmasters.
But if the company fails to respect the user, no matter what the vision, the user will fail to respect the company -- and seek out those companies they can respect.
Your client is absolutely not the Owner. I don't care whether the company is individually-owned, family-owned, private stock, public stock, or employee-owned. Those people paid a single price for a product - the company - and they are reaping the rewards of their investment. That's a good thing; most of us would not have jobs if we didn't collectively invest in each others dreams. And yes, your executives' vision is tied to pleasing the owners, and yes, your boss and your product owner's raises and bonuses are tied to pleasing the executives, and yours is too, and what the owners really want is more profit from their investment.
But if the company fails to create what the user needs, the user takes their money elsewhere.
That tends to have a negative impact on stock price.
Your client is none of these very valuable people without which the company could not run.
Your client is the user.
Your client might be the Randolph who is buying a roasted ham he researched on the website you designed so he can take it home to his kids for supper.
Your client might be Jane in Procurement using a B2B portal you designed so that she can buy the factory machines necessary to spice a ham for Randolph.
Your client might be Tanisha, who is using the application you built to design the marketing materials Jane looks at to buy the equipment needed to make Randolph's ham.
Your client might be Jose in customer service whose job it is to use the internal software you designed to provide Tanisha with technical support.
Your client might be your boss who uses the intranet site you built her to discuss better management practices with other team leaders.
Every step is a client who needs a product or service. Every step is a UX Designer building that product or service. Every step is bringing a user closer to a goal. It's clients all the way down.
But not up.
When you need to find the person you work for, the one to whom you owe your allegiance, it's not the folks who rank above you, it's the ones who you serve.
The people above you are there to guide you, assist you, pay you, and join you in serving your client. And like all teams, you must work together to accomplish your goals.
Your goal is simple: please your client.
Six to eight weeks.
When I worked in tech support, that was the magic number. Six to eight weeks after the software upgrade, the support calls would drop off. Six to eight weeks after the elevation, the users would understand most of the navigation and tools, adjust to the typography changes, and understand the new processes. Six to eight weeks after we went live, we'd finally get to take a breath.
We'd catch the worst show-stopping bugs in elevation, maybe as late as a two-week warranty, but it still took six to eight weeks for the calls to die down.
Call it a reverse honeymoon period, if you will: the first 6-8 weeks after launch all the users hate everything. New logo? Childish. New navigation? Confusing. New font? Hard to read. New imagery? Asinine. The concentration of "your website sucks" messages during that time period is 10x that of a normal day.
People hate changing.
(They don't actually hate change. Well, they don't hate change that affects *you*. They hate change that affects *them*. They hate changing.)
After the reverse honeymoon period, something amazing happened: all the adjustment complaints melted away and the tech support calls that were left were all real problems. Usually not showstoppers. Usually subtle annoyances we overlooked when we were heads-down in the project. Usually easily correctable. But lost in the shuffle of the complaints and frustrations of the previous six to eight weeks.
As an industry, we used to elevate big changes once a year, and some companies still do. Apple releases one OS. Microsoft releases one version of IE. Everything else is bug fix.
The web world has moved from one major launch a year to one a quarter to one every sprint. Maybe not the same functionality - even the best designers take weeks to rebuild a wacky purchase process - but *something* goes up every few weeks.
We have an unprecedented ability to find mistakes, fix them, and elevate repairs, whether they're in the requirements, the design, or the execution of the code. As soon as we hear of an issue, especially a hot issue, we can be on top if it.
That's great! Except that our users haven't scaled with the times. It still takes them six to eight weeks from launch until they relax into a new design, and during that time, they've got all the vitriol and panic necessary to convince a product owner that the launch is a disaster and everything needs to change right now.
A few years ago, the product owner would call and say "OMG THE FONT THEY HATE IT CHANGE IT RIGHT NOW," and we'd say, "Well it'll have to go up in the next elevation in three months," and by the time we got around to actually coding the change, the users had relaxed, the product owner had relaxed, and hey, this really wasn't such a bad after all, it was much more readable than the old one.
Today, we don't have the luxury of the inflexible waterfall process to stop us from making reactionary changes. So we can change the font again, and again, or first the font, then the buttons, then the spacing…. because there's nothing to stop us from constantly reacting to our feedback.
So I suggest this: heed your reverse honeymoon periods carefully. Remember your six to eight weeks. If silo A of your product is being upgraded, then as soon as that launch starts, move your development team to silo B, and stay there for at least 6-8 weeks, so that when you launch B's changes, A has had enough burn-in that your tech support folks know what's really wrong. Let your representativess do their jobs before you try to address the noise. Let everyone get through the 8 weeks of silo A's problems before you launch silo B's new upgrade, so no one's taking a trip on two reverse honeymoons at once.
Respect your users enough to give them time to change.
And then when you're done, buy those tech support folks some pizza or something. They're getting yelled at about everything you screwed up, after all. And they're doing it for six to eight weeks.
Cultures of Learning
In his TED talk, Paper Towns, John Green talks about cultures of learning. He did not enter a culture of learning until high school, and from his point of view education until that point was a series of obstacles to overcome. For many, it seems, the culture of learning -- of desiring to learn -- starts at school.
For me it began at home. I can't say exactly how I know this, except that whenever I asked a question that was vaguely historical or scientific, my folks would do their best to answer it, and if they didn't know they'd call a family member who might. The TV ran much more PBS than it did CBS, NBC, or ABC. The bathroom magazine rack held a few comic strip anthologies, a book of bathroom humor I wasn't supposed to understand (and mostly didn't), and at least one copy of Reader's Digest.
Then, as now, the household bathroom was as much a refuge for five minutes peace away from the hustle of a household as it was, well, its intended purposes. You could get away with locking yourself in a room for ten or twenty minutes without question, even at the age of ten or twelve, so long as someone else didn't need that room's particular functions.
When I was old enough to understand the written word and humor, I started reading Reader's Digest for the quips that filled the space between the article's end and the page end. (There was no white space in a Reader's Digest. That lesson, which I absorbed unknowingly, has colored my design work in not-glorious ways ever since.) The problem was I'd often find myself reading the last paragraph of the article accidentally, then going back to the beginning and reading the whole thing. This led to reading whole chunks of the magazine. Although I never snatched one out of the mail as soon as it arrived, I was always relieved to see that a new issue was tucked in the magazine stand.
A condensed book at the back of the Reader's Digest got me interested in neuroscience and neurosurgery, and for a while that's what I wanted to be when I grew up. I'm pretty confident it also introduced me to Dr. Oliver Sacks, who in turn introduced me to all the ways a brain can go horribly, or humorously, wrong. Dr. Sacks was a neurologist and author who treated patients for everything from aphasia to Tourettes and beyond; he told stories of how the autonomous acts of the brain we take for granted sometimes stop working, changing everything about how we perceive the world.
I could write thousands of words on Oliver Sacks, but to do so, first I'd go reread all the books of his I own, then I'd go hunt down the rest and read those, and then I would write.
But Oliver Sacks died today, and my heart is too empty to do that. My ribs are on too tight, my chest hurts, and I wish Oliver Sacks was still alive so he could explain how a thought entering my brain about a stranger I'd never met could cause the physical symptoms of grief.
Dr. Sacks was an avid participant in a culture of learning. He opened his July 24 essay in The New York Times with a description of his thirst to learn:
I look forward eagerly, almost greedily, to the weekly arrival of journals like Nature and Science, and turn at once to articles on the physical sciences — not, as perhaps I should, to articles on biology and medicine. It was the physical sciences that provided my first enchantment as a boy.
He was, in short, a learner. But one of the common side effects of learning is teaching; the discovery of a particularly delicious sip of the universe must be shared with those others who thirst for its knowledge. A neurologist and author, Dr. Sacks' described the strange lands he explored to an audience with less knowledge than he in ways that they could understand and relate to. In their obituary of the man, The New York Times noted his desire to share not just the causes and symptoms of neurological mysteries, but how they affected the human beings who were involved.
Describing his patients' struggles and sometimes uncanny gifts, Dr. Sacks helped introduce syndromes like Tourette's or Asperger's to a general audience. But he illuminated their characters as much as their conditions; he humanized and demystified them.
This is a gift of learning that we in the User Experience world -- or really in any world where we represent the interests of others -- can share. It isn't enough to describe the quantitative effects of a poorly-designed form in terms of adoption rates and sales funnels and drop-out rates. We need to make our "users", the people we represent, feel real to everyone who shapes their experience. It isn't enough to draw up a persona that indicates what segment the user inhabits, which demographics they meet, and how the product or process fits into their goals. We need to illustrate how it should fit into the real person's life, and how it absolutely shouldn't fit into their lives.
Ultimately, we don't have "users". We don't have "patients". We don't have "sales leads". We have people. Dr. Sacks knew that, and he taught me that, though at the time I thought he was just telling me stories about patients and medicine and science and this weird universe we live in.
John Green explains that his culture of learning as an adult has shifted from the classroom to the Internet, from inquisitive people he's met in person to inquisitive commenters on Youtube (yes they exist) and the living learning space they inhabit.
For me, too, the culture of learning has shifted. I no longer discover new worlds of interest from the magazine rack in the bathroom. (I don't even subscribe to magazines.) I still read voraciously, probably a half dozen articles a day, but they come from blogs and journals and publications that almost exclusively publish online. (How much learning still occurs in the bathroom I leave to the reader to infer.)
I learned of Dr. Oliver Sacks in Reader's Digest. I learned of the good man's death this morning in my Twitter feed, where I learn almost everything these days that turns out to be important.
It's the phrase "I learned" that I hope he would have approved of most.
I was recently giving guidance to a new designer about a website’s navigational architecture. He’d run into both technical and design constraints, and I convinced him to abandon the complex structure he was trying to use for a simpler layout.
“I know it’s better,” he said, “but I’ve spent three days trying to get this to work. It’s a shame to abandon it.”
It’s hard to walk away from a project. Sometimes we don’t get a choice; projects get cancelled, funding get shifted, staffing changes, assignments get juggled, technologies change. Of the first five projects I was assigned as an Information Architect, only one made it to production. Other times the project was one of my own making, a complex mess of decisions that added up to a problem in the design or the development. Wishful thinking and stubbornness are a great combination if you want a result that doesn’t actually work for anyone.
Continuing to work on the wrong solution just because we’ve spent so much time on it is an example of a sunk cost fallacy, the phenomenon where we justify increasing investment in a decision despite evidence suggesting that the benefits aren’t worth continuing. Letting go of a commitment we’ve already made is extremely hard, even when it’s what we have to do.
I can remember making the same complaint about a cancelled project when I was a new designer that my acquaintance was making now. “It’s a shame to abandon it.”
“Yeah, but you learned something, and you got paid,” my mentor replied. “You did what you were asked to do, and you’ll be a better designer for the next project. There will always be another project.”
Eight years and dozens of projects later, it’s still true. A day’s work learning something - even if it’s learning what not to do - is money well earned. The privilege of getting paid to learn to be better designers, even when that wasn’t the intention, is a pretty good deal.
Today, I learned something and I got paid. Whether that means the project is cancelled or not, whether it ships or not, the time wasn’t wasted.
Let's talk about can't a moment.
A long time ago, when David Letterman still looked almost-young, Grace Hopper cut wires the maximum length an electron can travel in a nanosecond. She did this to illustrate to senators and other important people why a computer can't communicate with a satellite faster than the speed of light. It's a law of physics we haven't figured out how to break yet. When Grace Hopper says we can't speed up communications with the satellite, she means we can't speed up communications with the satellite.
If you tell me that we can't do something, my gut expectation is that you'll follow your statement with a mention of the natural law that we'd be violating otherwise. We can't break the speed of light. We can't prevent quantum tunneling. We can't mine more of a mineral than exists.
And yet lately, both in public discourse and my private life, I've heard a lot of people say "I can't [X]" and leave it at that, with no explanation.
We have so many more options to describe our actions, the vast majority of which make us easier to understand. Being transparent about why we're turning away a request or a requestor builds trust. It makes our priorities, needs, and goals clearer to those we communicate with.
That doesn't mean we should do everything we're asked to do. We shouldn't do things that are morally wrong, illegal, or stupid. I'm not redesigning the vendor product's interface because we don't own it.
There are other things we won't do, because of our own priorities, the priorities of our employers. I'm not working sixty hours a week for six months, because I prioritize my mental and physical health over whatever you're offering.
There are plenty of things we don't have the authority or don't have the resources to do. Oh, the things I could do if someone gave me both authority and resources...
Like Bartleby the Scrivener, there may even be things we prefer not to do. I prefer not to run focus groups, not because I don't have the skills, but because there are other kinds of work I prefer.
And please don't get me wrong: I'm not saying that we can't say "can't" unless we're talking about scientific or engineering problems It's part of our language.
I am saying that when we tell someone we can't do something, and offer no explanation for why a thing can't be done, we're selling ourselves short, we're selling the person we're talking to short, and we're selling the relationship short.
And we may be missing out on a great opportunity to illustrate a nanosecond.
The damned annoying truth about sucking at things
Someone asked the 90 year old why he still played the violin every day. He replied, "because I think I'm starting to make real progress!"
Just realized I have been programming longer than I haven't, and I still suck at it.
Back in 2004, I started drawing a webcomic. I had no formal training in design and art, and the last time I had drawn regularly was as stress relief in college. I sucked. It took four hours every night I drew, two to three nights a week, to render the simplest comic.
I wrote the comic pretty regularly for about four years. At the end of those four years, it still took four hours a night two to three nights a week to produce the comic.
Someone asked me, "why does it still take you so long to draw the comic?"
It took four hours because four hours is what I had. If I'd had six hours, I'd've used six hours. Drawing a comic, it turned out, wasn't something I could get faster at. Or rather I could get faster, at the expense of never getting better.
There are some things that have defined beginning and end states, and definite quality levels. Answering 100 multiplication questions is one. A speed run through Super Mario World is another. When we start to do these things, we can either do them slowly or we can do them wrong, or in many cases we can do them slowly and wrong. As we learn the patterns and the end states, we both pick up speed and quality, until we reach a point where we can run them at an optimal speed with near-perfect quality every time.
Then there are the things that have a defined beginning, "I know nothing," and no defined end. Coding is one. Drawing, another. Writing. Sculpting. Teaching. Designing. When we start to do these things, we do them slowly, and we do them wrong. We learn to accept "good enough for tonight" is the stopping point, because there is no end state of perfect quality except what we define. (Also, because at some point we need to eat and sleep and go to our day jobs.)
Within the task of “Draw a comic” are a thousand smaller tasks that we can master. I can learn the curve of the line that makes up a thigh muscle. Once I’ve mastered that line, I’m much faster at drawing it. But just because I can draw a thigh in one try instead of six doesn't mean the whole comic will be finished 20 minutes earlier. It means that now I have the time to move on to the next bad part of my drawing: calf muscles. They still take six tries or more. (Some day I hope to progress to fingers, the bastards of the comic world.)
After four years of drawing regularly, I still sucked. I still wasn't as good as the ones who had been drawing 10 times as often for 10 times as long. I could see that I was moving forward, but I could also see that I wasn't at the end.
On the other hand, I wasn't at the beginning anymore. It still took four hours to draw a comic, but that comic was significantly more complex. I had learned more about my tools, learned more about the craft, and had a much better understanding of where I was going.
In 2008, I shifted from using my free time comicking to writing. I suck at it, but I've been working on it regularly for four years now, and I'm a published sucky writer instead of an unpublished sucky writer, and that's a marker of progress. (Notably, it doesn't stop me from making up words like "comicking".)
Those who say they’ve mastered drawing, or coding, or writing worry me. They think they’ve reached the apex and there’s nothing else they need to learn. These fields don’t work that way.
If you look at your work in an unending discipline and say, “I suck,” that’s good. That means you can see room for improvement in your work, and you’re frustrated enough by it to want to get better.
Go forth and continue to suck!
Rendering intent, in all its incarnations
I’ve been reading science fiction and fantasy for as long as I can remember.
I’ve been writing sci-fi/fantasy since I was eleven, when my friends and I wrote the most age-appropriately-atrocious Piers Anthony fanfic a person can imagine.
(No, worse than that. Keep imagining.)
(There you go.)
(See, told you it was bad.)
Science fiction made me interested in programming. Programming led me to the web, and that, in turn, to the Design discipline of Information Architecture.
Throughout it all, I’ve continued to write. In fact, I’ve continued to write the same freaking novel. I also wrote most of another novel, some short stories, some middling stuff, and, of course, nonfiction works like those posted here on The Pastry Box.
This past weekend, I attended a writing retreat — a reward for the Uncanny Magazine Kickstarter I backed last summer. It was a seven-person hands-on workshop/conference in a not-actually-haunted cabin. The retreat included short-story authors, anthology and magazine editors, podcasters, a book sales and marketing manager, novel authors, budding cartoonists, a singer/songwriter, interviewers, and a literature curators/academic librarian… Like designers, writers tend to wear a lot of hats.
We talked about the industry, how to submit work professionally, how to improve our craft (both individually and as a whole), what kinds of challenges exist, and what kinds of opportunities drive us forward. We talked about our histories as writers, and our futures. We kicked around ideas that will never make it off the ground. We wrote a horror story on Twitter, live. We ate (boy did we eat, the food was fantastic), took walks, drank bourbon, told stories, and wrote.
The more I design, the more I want to write. The more I write, the more I understand how to design. If, as Jared Spool says, Design is the rendering of intent, then, for me, writing is the ultimate act of design: rendering intent using only the medium of the written word.
When I was an inexperienced designer, I saw a lot of posters like these that described the difference between art and design as the difference between interpretation and understanding, talent and skill, inspiration and motivation, and messaging. I don’t buy it. Maybe I’m doing the “art” of creating writing incorrectly. If my writing inspires, it’s because I intended inspiration; if it showcases talent, it’s because I honed that talent into a skill. A quality editor isn’t going to accept a poorly-written short story by a “talented” author any more than a quality creative director will accept a shoddily-designed web process. Too many of the traits we attribute to poor design we label as “art”, which is a disservice to hard-working artists.
Excellent writing requires all the skills that excellent information architecture does. It must be concise and clear in its intent. Only those things that must be said are said, and nothing more. Flourishes, if included, are intentional. The structure must be obvious in its use, but invisible to the audience. Whether the reader is intended to follow a single path or choose their own adventure, the wayfinding and labeling should be effective and efficient. Excellent writing also requires critique, polishing, iteration, and sometimes throwing the whole thing out and starting over once or twice (or six times). Excellent writers must know when to be professional and when to be personal, how to market their work, how to receive and deliver an effective critique, and how to avoid burnout.
These aren’t lessons I brought from writing to design. They are lessons I learned while designing that I was only peripherally aware apply to my writing. A good editor is no more likely to buy a poorly designed story than a good client will buy a poorly designed website. A good critique group can make the difference between publication and rejection, between hitting the goals and missing them.
In 2010, I went to An Event Apart in Seattle, and it changed my life. For the first time, I understood my role in design and how I could improve.
Last weekend I went to the Uncanny Cabin, and it did the same. I now understand how I can become both a better writer, and a better designer.
I’m fantastically grateful to Lynne (and Michael) Thomas, Deb Stanish, Michael Underwood, Sarah Pinsker, A. C. Wise, and Fran Wilde for the opportunity to do something I’ve always loved to do better.
As a designer, if you have the opportunity to improve your hobbies — whatever they are — take those opportunities and run with them.
Back to Basics: Differentiating Personas
I work in Big Financial, which means the software that I use, design on, and design for, is generally Big Enterprise. I also work on the company intranet. The Biggest of Big Enterprise Web Design for intranets is, of course, SharePoint, so, well. Yeah.
(Don’t worry, I get to do a lot of other things too. SharePoint isn’t even our primary intranet.)
In my world, virtually any one of over 10,000 people who work in Big Financial can request a SharePoint site, build it out with their own content, strategy, and tactics, then publish it for the other 10,000 people to see. The design quality can be… haphazard.
I’m the Information Architect on call for whenever someone says, “Hey, this SharePoint site, well, it isn’t working as well as we thought….”
The first step I take when a site isn’t working is to ask, “Who is your audience?”
The first answer is always a blank stare, followed by “Everyone.”
I have learned that my business partners find raucous laughter an inappropriate response to that answer.
As designers, we all know that no one can design for “everyone” for the same reason that no one can design for “a normal person”. People are just too diverse in their thoughts, needs, motivations, and expectations for a single thing to satisfy everyone’s needs.
Our goal is not to design for everyone. Our goal is to facilitate the process of discovering who the audiences for the site really are. We lead the research and analysis, so that our business partners (the people asking for help) understand and can engage with their own audience.
This is where personas, fictional characters we create to explore and identify different user types, help us decide exactly who “everyone” really represents (and who it doesn’t).
As Andrew Hinton reminded us in Personas and the Role of Design Documentation, it’s not the output of a written-down persona that makes the difference in our design activities, it’s the exercise in creating them. When we’re successful, we build better designs. We also develop a stronger relationship with our business partners, because we’re all working toward the same goal: satisfy our audience’s needs so our audience in turn satisfies our business needs.
Persona creation is as variable an act as people are diverse. (I bet you’re just shocked.)
On the other hand, I didn’t get labeled “the most process-oriented designer ever” at work by accident.
Here’s my process for getting from “everyone” to 1-3 primary audiences and 5-7 secondary audiences. Your milage may vary. (Still shocked, I know.)
In general, this takes from an hour for very small sites to four one-hour sessions for medium sized or complex sites. We’ve been mapping personas for the whole intranet for, um, ten months now, so “huge” is as expected.
Thing The First: Explain the process
Explain your role as a designer, what personas are, and how the team will use them. (Seriously, I tried skipping this step, it doesn’t work. Explaining the value of a design exercise gives you at least a ten minute head-start before the business folks might think you’re wasting their time.)
Thing The Second: Ask a ton of questions. Take notes.
Ask who the audience is. If they continue to answer “everyone”, name the most ridiculous example that shouldn’t fit as you can come up with. “The cleaning crew?” or “The customer service reps on the phones?” or “the CEO?” or “Me?” or “My dad?”
The goal is to help the team understand that “everyone” is not everyone, even to their stakeholders. (If on the other hand, the cleaning crew ison the list, hey, now you’ve got an interesting business problem. Keep going.) Cracking that nut once usually allows the rest to fragment.
Ask “Who are the most frequent or most important people coming to your site?” Write them down as your first cut of personas.
For each group of people, ask, “Why do they want to come to your site? What’s in it for them?” These are the persona’s goals, and also a list of tasks the site will need to accomplish or information the site needs to provide.
Be attentive and keep your team honest. “They want to come to my site to learn Thing Company Is Cramming Down Their Throat” is probably not true. Thing Company Is Cramming Down Their Throat is a business goal, and likely has to do with saving money, making money, or not getting shut down for legal/ethical/practical reasons.
The corresponding user goal might be “Not get reprimanded because I didn’t know Thing” or “Learn something totally unrelated and trip over Thing”. No user anywhere is excited to come sign the Corporate Communication Policy. They do, however, generally have a vested interest in not getting fired.
For each user group, ask about that group’s experience. Is there a difference between how new users in a group will behave vs people with more experience? Is there a difference between how people new to a job or task behave vs more senior folks? How does age or tenure fit in? Familiarity with the specific software? Familiarity with the topic? An MD who isn’t very tech savvy will have a very different experience on WebMD than a young adult patient who’s extremely tech savvy and has no knowledge of medicine.
If experience or tenure results in different behavior or different needs, split that group into two personas. (The reverse is also true: if the behavior and needs are the same, the user profiles might be wildly different but grouped together.) Sometimes my personas are based on roles or expectations. Sometimes my personas are based on “analytical thinkers” vs “global thinkers”. It depends on the project.
Avoid differentiating by gender, race, religion, ethnic class, accessibility challenges, etc. unless you have quantitatively justifiable user goals or behavior differences to account for. (Personally, I prefer to write my personas to be diverse, with as little out-group homogeneity as possible, so I assign gender, race, and accessibility concerns randomly after discovering the primary needs and goals of the users.)
Ask, “How much of their day is actually about [site topic or task]?” We should have realistic expectations of our personas’ interest levels on the subject. If Adam spends less than 5% of his workday using my tool, I shouldn’t expect him to visit my site six times a day and be in awe of its glory and wonder. If Ellen spends 80% of her time using my tools and forms, I’d better satisfy Ellen’s needs or she can’t do her job.
If the user does the task today, find out how (which is good research for scenarios) and also what their biggest loves and hates of the system are. What existing features would make Adam weep if you wrecked them? What does Ellen wish the system could do?
Find out what our users do with the rest of their time. What are their top priorities at work or at home? For example, the Customer Service Rep’s top priority is handle the calls in the queue as quickly and accurately as possible. It’s all about the numbers. They get really angry if you slow them down with your gorgeous three-minute instructional video. The Knowledge Worker in the next building, on the other hand, may find the video perfectly appropriate for their daily goals and needs.
Ask, “How do they feel?” In cases where emotion is a factor, it’s the most important differentiation between groups. For example, Eric Meyer explains, urgent visits to a hospital website aren’t the same as frequent visits. Designing for crisis is very different than designing for the ideal user in the ideal situation on an ordinary day.
Similarly, designing for someone who is nervous, anxious, afraid, distrustful, or angry is very different from designing for those who are at ease with the topic and the company. Intuit, I think, does a great job of designing for people who are afraid to do their own taxes. If taxes were a ho-hum no-risk topic, the process could be a lot more like a spreadsheet. The anxiety inherent in the topic benefits from calm, friendly handholding, and that’s what Intuit’s TurboTax site provides.
Thing the Third: validate, validate, validate.
By this point in the process, you have groups of user written down, how they feel, what they need, and all kinds of other details about them. You could write a profile or draw a picture of them (and in fact you shortly will), but you probably don’t have validation of this information. You have “gut” and you have business domain knowledge. Lots of groups think this should be enough. They “know” their users… until they find out they don’t.
We are not our users. In some cases we might be a user, but we’re no more our entire user set than we are designing for everyone.
If you don’t validate your personas through user research, you’re not designing, you’re writing fiction. Granted, it may be web-based interactive fiction, but it’s fiction nonetheless. Basing a business case on fiction is a huge risk. As designers, we owe it to our business to take as few huge risks as possible.
If like me you’re lucky enough to work in Enterprise Intranet and have a captive audience of 10,000 people, user research is surprisingly easy to do. Talk to people who are in your user groups directly if you can, and if you can’t, find someone else who can represent them honestly. Ruth Ellison’s Guerilla User & Design Research techniques are fantastic for internal projects or fast, small work with low risks.
If your audience is not a captive audience, the user research is harder, but the payoffs are higher. The size of the intranet’s audience is capped at the size of the company, but the size of the outside world is capped at the current population.
Involve everyone in the design team, especially the business folks who opened the request. It gives the team insight and ownership of their research. It’s easier for the team to become passionate in defending their users from bad experiences when they had coffee and chatted about the latest crazy trade Chip Kelly’s made for the Eagles with said users just yesterday.
Thing the Last: Formalize your deliverables, but don’t put them away
Finally, write your personas. There are plenty of persona templates out on the web, but I’m not going to tell you which one to use because by this point you know your users better than any template can describe. You’ll likely want to invent your own.
If possible, share the formal personas with the folks you worked with for research, to confirm they sound accurate. (Easier in intranet than world wide web!)
At this point you’ll want to start other design steps, like scenarios or capability strategy, if you haven’t already. You know your users. You’re ready. But don’t put that set of personas away. Hang them where the project team can see them. Pull them out midway through developing your other deliverables and ask yourself, “Am I meeting all of Bob’s goals? Did I forget about Amanda’s pain around this process?” Use your personas as references during big design debates. “Bob would hate that! Look, he told us so!”
Lastly, remember what you’ve learned. It’s always a good idea of going through the exercise of researching the audience types you have, but by the third project involving the Customer Service team, you probably have all the quantitative data you need to describe them for the ninth project. Reuse (and re-validate) your persona information on a regular basis where it’s appropriate, and you’ll make design more efficient and more accurate for everyone.
Embracing Your Work Wife (No, not literally.)
I stared at the question in the Gallup poll. "Do you have a best friend at work?"
Well sure. We're 14,000 people strong, I've been here 15 years, it was bound to happen eventually. I've got a bunch of best friends who work here, including two family members.
A little digging into various explanations on the intranet and the internet revealed the actual point of the question: in an attempt to identify root causes of employee engagement, they're trying to measure trust. Does someone have your back? Do you have theirs?
Oh. They want to know if I have a work wife.
According to Wikipedia, "work spouse" or "office wife" are the standard terms, although the second has the unfortunate connotation from the 1930s of meaning what my local area calls a "coffee bitch"  For reasons already cited, I'm sticking with "work wife".
Your work wife is your best friend at work, but that's not the same thing as your "best friend, who also happens to work here". For one thing, I, and most of my friends who have work wives, almost never socialize with them outside of work. It's not that we don't want to, it's just that our relationships, as deep as they may be, are in existence because of work, and they begin and end at the door — or the post-work happy hour. Contrast with my best-friend-also-works-here, who checks up me on weekends when I'm sick, invites me out to movies, and whose dog I will watch at the drop of a hat.
A work wife isn't the same thing as a mentor, either. As much as mentors love to espouse the "I learn something from everyone I mentor" thing, there's a power relationship there. One of you is trying to learn, and the other is trying to impart knowledge. Your work wife, on the other hand, isn't looking to give or get anything out of the relationship except friendship. It's possible to have a work wife from whom you would never in your right mind take career advice and to whom you would never attempt to teach new skills.
It's hard to describe a work wife in a single sentence, and I prefer storytelling anyway.
He's the one who will walk up and say, "I know you want to prep for your four meetings this afternoon, but don't you think maybe eating lunch will be better prep than showing up as Robin Williams?" And when you say no, he pesters you into at least going downstairs and grabbing some soup, and damned if he isn't right every time that 20 minutes away from the work fixes the whole day.
She's the one who will listen to you when you need to dump off this pile of stress from work — or from home — and who you'll drop everything at the office (except that damn meeting with the execs) to listen to when it's her turn to dump off a pile of stress. She's also the only one who would forgive you for ditching her for that damn meeting with the execs because she already knows why you're referring to it as "that damn meeting with the execs".
He's the one who will say, "Your fly's undone" or "let me take this loose string off your sleeve" or "spinach in teeth" or "whoo girl your breath, have a tictac" and you won't even get mad.
She's the one who sends you job postings for other departments because she's worried about the stress you're under (even though you both work in the same department) and she wants you to be happy. She'll prioritize reading your cover letters over doing "funded" projects. At the same time, she's going to tear your grammar and sentence structure apart, fill everything you ever wrote with red ink, and you'll be glad.
When you and he go out to lunch at a restaurant to get away from the office and someone reports back to his actual wife that "I saw him out with another woman", your wife already knows who you were out with, and she's grateful that you're the one taking all that stress off his shoulders so he doesn't bring it home.
She's the person you have the largest number of in-jokes with. You know just what to write or draw on their whiteboard or chat or email to make her grin when she's having a bad day. And you know when she's having a bad day without having to ask.
Because he said, "Sushi tomorrow?" you get out of bed, shower, and put on pants.
When you're furious about something and trying to decide whether a Jerry Maguire-style rant and storm out with the fish is appropriate, the fact that you'd be sticking her with the entire Dumbass Client account causes you to consider the relative merits of a sternly-worded email to your adversary instead.
He gets mad on your behalf when someone else does something stupid that hurts your feelings. Not just, "Ugh, glad I'm not her," mad, but actual, "Hey, do you want me to pull them aside and say something, because I totally will" mad, sometimes to Bring It proportions.
And when that happens, well, that's a damn good feeling.
Our work wives seem to be generally members of the opposite gender. Maybe that has to do with attractiveness and intimacy and things like that  or maybe it's more around men competing with men and women competing with women, or maybe it's something else.
Other things I have noticed but can't back up :
- There's a better chance both members of the relationship are already in stable relationships outside of work, so a work spouse is neither a potential date nor a threat to the actual wife/husband.
- The relationships are purely platonic and it may take years before a work wife will feel comfortable giving their partner a hug outside of a lunch before someone goes on vacation for three weeks. After all, these are work relationships.
- We tend to work close together — the same department, the same project, the same team — at least at the beginning of the relationship.
- Not too surprisingly, giant buckets of stress in the form of deadlines, heavy workload, or an emergency the team works through together, are often involved.
- Introverts seem more prone to work wife relationships than extroverts.
- Once forged, the closeness between these two people will be noticable to others. In the worst cases, rumors start.
- Even years after the inevitable break-up, there's a feeling of acceptance that is difficult to replace.
And there are break-ups, especially in big companies. Because proximity is such a driving force in forming these relationships, separation can tear them apart faster than a jack russel can tear the squeaker out of a stuffed squirrel.A long-term work wife relationship will survive one person changing teams, if they're still on the same floor and working roughly the same schedule. (I've heard of, but never witnessed, a cross-floor pair. ) Changing floors or hours so you no longer see each other at the usual times is often a deal-breaker, and changing departments or divisions or buildings is a killer.
It's not that you're no longer close friends, or your stop caring for each other, or anything like that. It's just that all relationships require care and feeding, and that's much easier to do when the subject is within eyesight or earshot most of your eight hours a day. Quick "How's it going?" conversations between meetings are much more difficult when you're not passing each other in the halls or at your desks between meetings. Grabbing lunch now requires planning instead of a poke in the shoulder and the phrase "Jeet yet?"  Now a relationship that was forged in fire and proximity requires work, real work, in a place where work is causing the fires in the first place.
I'll be honest, I didn't break up particularly well with my last work wife. When I took a new job, I thought we could make it work, even though I was a floor up. And we did grab lunch and chat for a while — but when they moved me a mile away to a different building, well, neither of us had time for the connections anymore, and the friendship eroded fast. When we met for lunch a year or so later and he told me he had a new work wife, well, I found time to get all sniffly in my car before heading back to my overloaded meeting schedule.
Gallup's poll question is trying to measure engagment via trust, but a work wife is a little bit more than trust. It's a real relationship. Sometimes at the beginning it can even feel like a crush. In the middle it often feels like a reason to go to work. On a bad day a scheduled lunch with the work wife might be the only appealing reason to go to work. We shouldn't expect the endings to be any different. When they're done, we mourn, just as we would for any other relationship. That's not trust, and that's not engagement with the workplace. That's the leap of faith we make for loving the people we work with.
The "engagement measurers" of this world would do better to ask, "Did you recently lose a work relationship close to you?" because when the person or people who go to work to spend time with leave, well, work doesn't just lose its shine, it suffers. Suddenly tolerable annoyances become intolerable. In-jokes don't work between one person. There's a sort of loneliness that's hard to shake. If ever there was a set of circumstances that screamed, "Hey get a new job!" it's this.
We give a lot of advice in the corporate world (web design and otherwise) to make sure to have good working relationships with our clients. We suggest ways to win over support from the groups we're not part of — business, development, design — as if they're foreign dignitaries that we must woo and write peace treaties with. Everyone should have a mentor, we say. Everyone should be a mentor.
All good advice. And if any one of those relationships sucks eggs, well, it certainly doesn't make the desire to go to work any stronger.
To this, we should add the advice to foster, celebrate, and cherish the strong relationships we already have.
If you have a work wife, take the time to say thank you and tell them you're glad for the friendship. Even if you don't, take a few moments today to tell the people that you enjoy working with the effect they have on your work day.  That moment may make another day at work worthwhile for someone, and damn, that feels good when it happens.
ENGAGE FOOTNOTE MODE:
1. For the purposes of this essay, I'm using "wife" in a non-gendered sense. Why?
- "work wife" is deliciously alliterative.
- I prefer the labiodental fricative of the /f/ in wife over the alveolar fricatives from the /z/ in "husband" or the second /s/ in "spouse". Those words just don't "feel" right to pronounce. Maybe it's because /f/ and /v/ are both labiodental fricatives and so "wife" physically feels more like the word "love". In other news, we need better terms for the male/butch partners in our lives because these physically feel icky.
- "Spouse" sounds too much like "souse" to me. Ain't nobody got time for a work head cheese.
- We use male-gendered terms as non-gendered all the time, so why not flip it?
- Alternatively, a "wife" is, in the usual set of biases, associated with nurturing. Who doesn't want someone nurturing in their most stressful 8 hours a day?
- I'm writing the essay so I can do what I want.
2. "When they advertised this internship, I thought I'd be doing some light office work and learning about the craft. Instead, the boss treats me like a coffee bitch and the staff think I should be chained to the copier all day."
3. You are reading the footnotes, right? These things are a bitch to hand-code.
4. It's worth noting that I work in a very cis and HR gets understandably twitchy when someone goes around asking the LGBTQIA members of the team "What gender is your work wife" so I haven't researched it. The Wikipedia story implies the same, though.
5. As @pikelet recently said, "They're not anecdotes, that's small batch artisanal data"
6. I just have to ask: how far through the article would you have gotten if I hadn't called you down here to the footnotes again?
7. Ten minutes.
8. I bet you're wondering why that parenthetical isn't a footnote. I don't know either.
9. "Did you eat yet?" for those of you not from Philly.
10. You may accidentally increase engagement in the workplace. My apologies.
Be kind to yourself.
There are billions of things to be afraid of in this world and in this lifetime. They can't possibly all come true.
There are millions of things to be angry and bitter and frustrated and sad about. You'll feel all of those things regularly.
You are going to fuck up at least one major part of your life royally at least once in your life. If you don't, it only means you died too young to get to it.
Apologize when you fuck up. Acknowledge that the people you hurt don't have to forgive you -- that's their choice, not yours -- and recognize that whatever you did will have lasting consequences even if it looked like a small thing at the time.
And yes, there is a space in life for being ashamed and embarrassed when you've wrecked everything. Own it. Acknowledge it.
But also, be kind to yourself.
The major blunders are not the every day, they are the exception. (Unless you live in a drama TV show a la House, then all bets are off.)
You can't learn to handle the big things if you can't learn to handle the little ones.
And oh, as web people, we have so many opportunities for the little ones. Responding too harshly to a client's criticism. Treating someone new to the field like they're an idiot. Judging whether our peers know what they're doing. Judging someone else's work on our favorite app or site based on our own personal use cases. Bashing that guy who's always late to meetings. Being that guy who's always late to meetings. Breaking relationships instead of building them. Being oblivious to how others are reacting to us.
And that's just at work.
That doesn't take into account the family relationships, commuting stress, weather, financial situation, or lives we have to live.
It doesn't take into account the things we cannot control.
What are my brain chemicals doing today?
Am I sleeping right? Is this insomnia again, or just too much caffeine?
Is this an illness or exhaustion or depression? Why can't I get out of bed?
Am I right to be mad about this or am I overreacting? Is it hormones or depression or anxiety? All of them? None of them?
It's so easy to let the deadlines and the pressure and the bugs and the miscommunications and the brain chemicals and the sheer act of living drive us to -- and beyond -- the breaking point. It's so easy to burn out.
But you are the only person you absolutely must live with for your entire life. No matter how long you live, you will be stuck with yourself.
So be kind.
Take thirty seconds to close your eyes and breathe in big gulping lungfuls of air and enjoy the feeling of being alive.
Turn on your favorite song and dance. Or cry. Sometimes the chance to cry is a kindness in itself.
Find ten minutes to read a short story or a book or an article from an author you admire.
Have an extra cookie.
Buy yourself flowers and revel in their scent.
Say, out loud, "I did okay today," and accept the compliment.
It's not a reward. It's a kindness. It's not that you've earned it or you haven't. It's the first step to love.
How to edit any piece
- Figure out what the point you're trying to make is.
- Relentlessly evaluate every word and every sentence until it supports this point for this audience at this time.
- Stop when it's good enough.
- #1 takes 90% of the time.
- #2 takes the other 90% of the time and usually requires redoing #1 multiple times.
- If you figure out how to do #3 reliably, please tell the rest of us the secret.
Lessons from the word trenches
Previously, on The Pastry Box, our intrepid hero was preparing for National Novel Writing Month, a grueling slog through 50,000 words of the novel she started when she was 13 and which, despite a half dozen rewrites, she had never finished. Let’s join today’s episode, already in progress:
So, it’s done.
Well, it’s as done as it’s getting until January. I put it aside (as recommended by smart people) and as much as I really really want to be editing it right now, it will wait.
Meanwhile, not-writing my book has given me a chance to think about writing my book. Specifically, about how, for the first time in nine years of NaNoWriMo history, I was not only on schedule with the books, but ahead of schedule. I was ahead of schedule despite working the entire month, despite a trip out of state for a pinball tournament, and despite hosting Thanksgiving. Obviously, this was a new state of affairs for me, one that, if I could harness its magic, could increase my design and development productivity as well.
- You decided you wanted to write.
- You checked the sprint account, where one of the sprint leaders would at quasi-regular intervals announce the beginning of a sprint, often with a word count goal and/or a prompt to give you an idea for the story (if you were running low).
Alrighty! Let’s get started. We’re going for 20 minutes. Optional Prompt: Birthday cake Dare: Poison WCG: 450 GO!— NaNoWordSprints (@NaNoWordSprints) November 30, 2014
- When the sprint started, you wrote like crazy, concentrating on nothing but writing. When the sprint ended, you congratulated yourself, took a breath, backed up your novel, went to the bathroom, etc.
That was it. Sprints ran, well, all day every day, with the occasional few-hours break when no one was available to host. In other words, if you couldn’t fit in a few ten-minute sprints in your day, it was your own fault.
When I started sprinting, I quickly found that concentrating on writing was the hardest part. The longer the sprint, the easier it was to get distracted by other things: research, social media, random butterflies out the window, whatever. The short sprints were easy. I was there to write, I wrote. It wasn’t always my best work, but it wasn’t my worst, either. It was enough to get the job done. And the more often I sprinted, the better I got at longer and longer sprints, until I was occasionally blowing straight through the sprint limits and write for up to an hour at a time with no breaks and no distractions.
It turns out, surprise surprise, that concentrating, like everything else we do, is a skill that requires practice. @NaNoWordSprints gave me anywhere from a few minutes to a few hours of practice a day. By the end of the month (which I was blissfully on vacation) I was averaging 5,000 words a day.
NaNoWriMo’s sprints are very similar to another time management method called the Pomodoro Technique. This method employs a kitchen timer to measure the length of the sprints. You set the length, and the goal, and the amount of time between sprints, or pomodori, as they’re called. If you don’t have a kitchen timer but you do have a smartphone, you can download a pomordo application.
The key is not the application or the timer. The key is building the skill of blocking out distractions so that no matter how small the window we have to work, we can get meaningful work done.
We often complain about not having the time to do our jobs or get work done, and it’s very true that design and development work, like writing, is best done when we have a big chunk of time to concentrate on a big chunk of work. At the same time, we don’t always get a big chunk of time. If you’re like me, you get a few breaks between meetings a day, and most days you’re happy if you can keep up with your email. So when a break comes, you’ve got to be able to dive in and just concentrate on what you’re doing. The Pomodoro Technique, or sprinting, or timeboxing, or whatever similar methodology you pick, teaches concentration, which in turn, results in websites. And websites are the ultimate goal.
Or site maps. Or presentations. Or code.
Or novels. Tasty tasty completed novels.
Playing to win
This is the earliest I've written a Pastry Box post for a deadline.
Today is October 25th, and I'm sitting in my favorite local bar playing a pinball tournament that puts new pinball machines in children's hospitals. I probably should be concentrating on my ticket, but the fact is that I am not going to win this tournament. I'm probably not even going to make the playoffs. There are too many high-ranked players here today.
I'm not here to win. I'm here to play. But ultimately, writing my column today is the priority.
November is coming.
November is National Novel Writing Month.
NaNoWriMo is important.
NaNoWriMo is a writing contest, of sorts. The goal is to write 50,000 words in 30 days. Essentially, a novella, but still well more than most of us have written in a single document for a single purpose in our lives. Like pinball, the "competition" isn't really against the other players. It's against your own mind and your own machine. Like pinball, there are people who are superstars, whose sheer talent and/or force of will allow them to do fantastic things. They will write a novel in 30 days, they will clean it up and edit it, and it will be published. I am not in their league.
Like pinball, I'm not here to be the top seed. (There are no rankings or prizes in NaNoWriMo. Everything is made up, and the points don't matter.)
I have to finish this book.
I started this book when I was thirteen years old, on a Tandy HX 1000 that predated the internal hard drive by about three weeks. I still have the twenty six page dot matrix printout of the horribly written tale of a princess retaking her kingdom from an evil king. She had blue hair and the story was called Sky Blue Princess and trust me when I say it was bad.
In 2005 I discovered NaNoWriMo and decided to dust off the old concept, which I had worked dribs and drabs of for years, and write the prequel, so that I could properly rewrite the original story. I lost that year, with something like 25,000 words written. But for the first time I had a direction (a functioning plot) and a goal (write 50,000 words no matter how bad), and I felt like someday I could be an Actual Writer.
I also understood for the first time what being an Actual Writer means. It means coming home from work at a reasonable time because I'll be logged into the computer every night trying to write at least 1,667 words. It means writing dreck when the words won't come. It means writing brilliant sentences that are so out of context with the real plot that they're bound to be cut. It means false starts, disaster, major interferences from life, confused and frustrated family who don't totally understand why you're hiding in a hole with a raft of paper for a month. It means figuring out how to keep a word count up while traveling for pinball tournaments, cooking Thanksgiving dinner, and keeping work happy during the busy season. It means a lot of damned hard work.
In 2007 I lost again. In 2009 I lost. In 2011 I won for the first time. I won again in 2012 and 2013. Sometimes I do the November event, sometimes the summer camps.
All told, I have cleared over 300,000 words for the book I started writing when I was 13.
And while I have rewritten and rewritten and rewritten, I have never finished a rewrite since I was thirteen. I write myself into a corner, and then can't figure out how to get back out.
So despite the fact that I'm traveling in November for a pinball tournament, despite the fact that I'm hosting Thanksgiving, despite the fact that I'm working out an hour a night and changing my sleep habits and just discovered Minecraft and let me tell you that is a time suck like nothing I have played since one-more-turn Civ IV, this year I'm going to finish the damn book.
I have six days to get my act together, prepare everything possible for the house, the meal planning, and every deadline that might cross my path in month eleven. Right now I'm filled with anticipation and excitement and confidence. When you read this on the 16th, I will be in the middle of the depths of despair.
And that is okay.
You can't win if you don't play.
Back to basics: handling negative feedback
It’s easy to say “don’t take it personally” when it comes to our work. It’s harder to do. “Don’t take it personally” is a skill to build, just like wireframing, presenting, writing solid code, digging ditches, woodworking, baking, or guinea pig farming.
If you work as an “innie” in a company that sells non-design products, your organization already has a department of bona fide professionals that would be glad to take you under their wing for a few hours a month. They’re called Customer Service Representatives.
CSRs are the folks that talk to your end-users and customers. They know what doesn’t work on your site or in your product, because they hear about it all day long. A CSR can be your best friend for usability reviews or heuristics when you can’t get access directly to your client. A CSR can save your bacon for gathering direct user feedback through recorded calls and logs.
A CSR can also be your number one mentor in learning how not to take things personally.
“Don’t take it personally” really means “Don’t assume it’s about you.” That assumption can happen for a few reasons. We need to short-circuit those thought patterns, when they occur, so that we can do the real work at hand.
You are not your company
To a customer, a company is a Borg-like hive mind whose CSRs are a tendril of the whole. When we serve as CSRs, people speak to us as if they’re speaking to our parent company. “You people suck,” some of them say, as if they had spoken to the entire population of us for more than fifteen seconds and know whether we are in fact the vilest human beings. “You screwed this up.” “Your website is broken.” “You can’t even build a login form right.”
When we talk to customers, we play a role like an actor in a show. We know we are are not the “you” in question any more than the guy in the big mouse suit in Orlando is a real talking mouse. “You” is the company. We speak and act for the company. When the customer says “you suck”, they’re talking to the suit.
The same is true of a design review. A reviewer may say, “Why did you build this navigation?” or “You ignored this research” or “You should be moving faster”. They don’t generally mean you-the-person. They’re talking to the suit.
Imagine if a little kid told the Big Mouse he sucked, and he took the mouse head off and berated the kid. Everyone would be shocked - the kid, the parents, other observers. No one will remember the kid’s actions, no matter how rude or immature. They will remember the mouse broke character, and lashed out on top of it.
When you’re in a design review, wear the suit. Take advantage of its properties: it presents the professional designer you want others to see, and it shields your “inner” self from the professional designer.
Everyone comes with baggage
CSRs talk to people all day, so when we go home and we have a problem, it’s not hard for us to call someone and deal with it. We speak the language. We understand the system. We also know how to be in the right environment to make a customer service call. (We do still think it’s a pain in the ass, but it’s not frightening.)
Our experience sets us apart from our customers. They may not know how to navigate a phone menu system, or when to elevate a call. They may be socially anxious. Asking for help or voicing an opinion to a stranger is a scary prospect, even over the phone. They may be trying to call in a loud mess of an office, or a car on the freeway. They may be in physical or emotional pain.
Then there are the “kick the dog” moments when we’re quite sure if we weren’t bring raked over the coals because of some minor problem, the caller would be taking their frustrations – whatever they might be – out on someone else. We were the pooch being punted.
We couldn’t take it seriously. It was clear that the anger wasn’t *really* aimed at us. They were just an opportunity to vent steam before addressing the very real problems the customers had called about.
What kind of conversation can we anticipate from this CSR environment? They accidentally hang up on us. They don’t follow instructions. They try to anticipate our questions, usually incorrectly. They waste our time discussing irrelevant things. They jump to conclusions that align with some agenda we’re not even aware of. And just when we’ve given up hope that anything useful will come of the conversation, something suddenly clicks and we’re communicating at a level that can get things done.
The same is true of reviewers. They may be inexperienced. They may be anxious. They may be mentally, physically, or emotionally unprepared or distracted. They may be furious at someone else. They may be embarrassed or hurt by feedback someone else had just given them. None of these things will stop them from giving feedback to you.
CSRs will generally assume a customer calling is not trying to piss them off. When we work with a team every day, it seems to be easier for us to attribute to malice what can be explained by lack of experience or misunderstandings. Don’t fall into this trap. Assume the best in people, even if they’re showing you their worst.
Have compassion for everyone you meet, even if they don’t want it. What appears bad manners, an ill temper or cynicism is always a sign of things no ears have heard, no eyes have seen. You do not know what wars are going on down there where the spirit meets the bone.~Miller Williams, “The Ways We Touch”
When we assume the best in people, we find that most of the things we used to react defensively to puff into smoke and disappear. The feedback we thought was negative becomes a pile of information to sift through and decode.
You are the only one who can listen
The most important skill a CSR has is active listening. Because our customers don’t always know how to tell us what’s wrong, we have to collect everything they’re saying and sort the relevant and irrelevant feedback so that we can ask the right questions or provide the right answers. Something they throw out that’s meaningless to them becomes a Eureka Moment for the active listener.
It’s our jobs to get people to open up. It’s our jobs to allow them to talk past their baggage and their frustrations and, when they give us just enough of the picture to make sense of it, to help them with their problem.
If you’re already separating “you” from “the company” and you’re separating your baggage (and your reviewers’ baggage) from the actual story, then you’ve got the environment you need to listen to the facts. When that happens, you need to be listening to the facts. Make notes. Capture relevant items. Capture semi-relevant items. Doodle in the margins during the irrelevant stuff, but keep listening.
Active listening is more than keeping your ears open and your mouth closed. It’s also about repeating back to the speaker what they said, so that you know you got it right. (If you don’t, they’ll tell you!)
Sometimes things get ugly. Don’t jump into the fray
Sometimes, no matter how hard we try, misunderstandings happen, people get snippy, and Attitude arrives. these are the moments we fear when we present. “What will I do if someone gets rude or antagonistic or sexist or something else? What happens if someone causes a scene?
Attitudes are like puppies at the dog park. Every one has one. But if someone else’s is gnawing on your leg, maybe don’t let yours off the leash.
As CSRs, we were thoroughly trained on how to handle the worst of the worst. Here are the instructions for a bomb scare. Here are the instructions for a verbally abusive client. Here’s how to reach a supervisor. Here’s what to never say.
As designers, yeah, not so much. There is no expectation that we will attract verbal abuse during a presentation, because we’re all professionals here. It’s understandable that we may feel woefully unprepared for the worst-case presentation.
First, a reality check: this doesn’t happen nearly as often as we fear, or believe. The majority of us can present or attend dozens of peer reviews or executive reviewed before there is a genuine bona fide scene. Most employers have Consequences-with-a-capital-Pink-Slip for bad behavior, and most people want to keep their jobs. Negativity bias and pessimism bias can lead us to believe before a presentation that this will be the worst. The odds are stacked against it.
That being said, yes, I have received some rough feedback on occasion. (I’ve given some too. Stupid happens to everyone.) The most effective defense I’ve found is to make a plan, shut up, and make a plan.
If you are not presenting at reviews because you think there’s going to be a scene, check yourself: are you planning to cause a scene? Do you know someone who has such plans? Chances are the answer is no on both counts. Problem solved.
If you do know someone who is planning to cause a scene, talk through the issues with someone you trust (preferably an authority) before the review. Make a plan. Maybe it means not presenting. Maybe it means having an advocate in the room. Maybe it means wearing your lucky underpants. Do what works.
Assuming that no scene is expected, what is your emergency plan for the worst case feedback?
I suggest you shut up. (Wow that looks wrong in print.)
Let the other person say their rude and stupid and uncalled for and horrible things. Let them get all that bile and garbage out onto the table where everyone in the room has to look at it. Stay quiet, even once they finish, until everyone including you and including the speaker has had a chance to not only hear it, but to process it, and most importantly, decide how to react.
You do not have to attend every argument you’re invited to. ~Anonymous
Often you’ll find you don’t have to say anything at all. Someone else in the room will take that person down so smoothly that you, who has skin in the game, literally could not do it better.
What if no one says anything? First, assume the rest of the room is not “on their side” or “assholes” Sometimes no one else will say anything because they’re embarrassed to be there. They’re embarrassed to be a witness, or they’re embarrassed that you were exposed to the vitriol, or they’re embarrassed that the speaker provided it.
Make a decision. Follow your plan.
- Was the feedback so poor or ridiculous that everyone in the room just sprained their rolling eyes? Take a deep breath and say, “Okay, noted.” Move on to the next thing.
- Was the feedback something you could tolerate (but shouldn’t have to)? Say, “We can discuss that offline. I’ll arrange a meeting.” Then ensure your supervisor or similar advocate attends the meeting.
- Was the feedback so out of line that you no longer feel safe? End the meeting. Thank the whole group for their feedback. Leave.
Regardless of your choice, if you’re polite about it – if you never take off the suit – there will be little that your adversary can take back to your supervisor.
After any of these instances, check in with a trusted advocate. Do it after you’ve recovered from the adrenaline rush of confrontation. Do it before you get called to their office. Work with that person to determine whether your approach was good, or whether you need to change it for the next time. Keep your notes with you. Stick to the facts. Adjust your plan according to their feedback.
The hands-down best book I know for handling these situations is Crucial Conversations. If you know these are skills you need to strengthen, this is the book I recommend.
When all is said and done
Learn to deal with upset people. It’s part of the job. You can learn how from a mechanic. ~Mike Monteiro
At the end of the day as a designer, you log the feedback you received in a spreadsheet, stripping it out of its emotional shell and reporting like an anthropologist studying the locals. These are the facts. These are the concerns. This is the feedback. This person has a good point. This person carries weight.
You close the spreadsheet, log out of the system, put away your sketch pad and your whiteboard markers and your sticky notes. You go home. Maybe you think, “I can’t do this forever.” You decide to get better. Maybe you do that by improving your design skills, because that feedback, while harsh, was right on the money. Maybe you improve your soft skills because even the CSRs go to regular trainings to improve their soft skills. Maybe you plan your next career move. Maybe you start building a guinea pig farm.
When all is said and done, negative feedback will still come, but you will be able to find the gems inside of it because you listened to your reviewers. You kept the suit on. You ignored the baggage. You shut up and followed the plan.
At the end of the day as a CSR, you log out of the system, put away your headset, and go home. You think to yourself, “I can’t do this forever.” You decide to get better at your non-customer-service skills. Maybe you pick a new career, like web design, where you can be at the front of the design process instead of the back, and maybe make things better.
And there’s a lot less yelling.
A small rant courtesy of your users
Here is the wrong way to respond to someone who says something on your website isn’t working:
“I’m not having that problem. It works for me.”
Here is the right way:
“It works for me but....”
“... That doesn’t mean it works for you. Let’s take a look.”
“... I hadn’t anticipated that we’d need video transcripts. Let me see what we can do”
“... I didn’t test that scenario thoroughly. What did you discover?”
“... Let me do it for you.”
“... I know who you can talk to that can help.”
“... [FILL IN USEFUL ACTION HERE]”
The first response indicates you have validated your website matches your expectations.
The second response indicates you have validated your user’s experience.
Your code does not pay you. Your user does.
As your user, I do not care that it works for you. I did not dream that your website failed. I did not make it up. I do not have the time to waste reporting things that never happened.
I do not caaaaare that it works for you. I am trying to use this process to get something done, and my time’s important. I’m trying to meet my needs, not yours. Either meet my needs or tell me you can’t, so I can give my time/money to someone else.
I do not caaaaaaaaare that it works for you. It’s the web. It should work everywhere, and by everywhere, I mean on my device. I already bought this [computer | tablet | phone | watch] and I am not going to return it just to make your stupid website work. I’ll use someone else’s product.
I do not caaaaaaaaaaaaaare that it works for you. I am so glad that you and your perfect ears can hear the damned video, but I cannot, and when you tell me you plan to take no action because your perfect ears are just fine, I wish to box them.
Even if it works for you, it works for all your co-workers, management, foreign countries, and the Easter Bunny, I do not care to hear about it.
Validate my experience even when it is different than yours. Help me reach my goals. Or get me to someone who can and get the heck out of my way.
Back to Basics: Peer Reviews
I’ve attended roughly one peer or executive review a week for the last six years. I average one presentation every five weeks. I’m nowhere near the best in the field, but I’ve noticed some trends among new folks (and tenured folks out of practice) that are basic, yet easily missed, steps. And while there seem to be lots of guidelines for managers and team leads and those in the audience for how to make a space safe and how to give good feedback, I am having a lot of trouble finding guides for how to take good feedback.
Nobody likes getting criticism. If you’re nervous or insecure about your work, it’s that much harder not to hear every “did you consider…?” as “you suck.” The easy way out is to avoid presenting. I’m here to tell you that if you want to be a good designer, you can’t avoid design reviews forever.
At some point someone’s going to ask you to stick your neck out and present your work to someone so that it can be reviewed by people who have the authority to correct the course of your project. Depending on your setting, this might be called a critique, a peer review, an executive review (*gulp*), a pitch, a sprint review…. The name doesn’t matter.
Conducting yourself professionally matters. Understanding that you are not your work matters. Learning how to disposition the feedback you get matters. Getting the right results for your clients matters. Getting the right results for your client matters more than your skills, your ego, and your talent all rolled into one.
You don’t suck. But you could get better. Every one of us could get better.
Here’s how to give a presentation of your work:
Assume there’s at least one person who doesn’t know you. Introduce yourself, your role, and where you work, for their sake. You’d be shocked how many presenters assume that everyone in the room knows them.
Give a short summary of your project and why you’re presenting it. Who do you work for? What’s the goal of the project? What is the goal of the process or section you’re presenting today? How long is the project, and how far through are you?
Finally, set expectations for what kind of information you’re looking for. Do you want advice on strategy or detailed design? Visual design or structure? Is a section locked down? Is there an area you haven’t thought about at all yet? Give your reviewers some guidelines.
Introduce your primary persona and their goal.
In one to two sentences, describes the user you’re going to role-play and why they’re using your webpages.
For this first scenario, I’m Caroline, a defense contractor who was just moved across the country, and I need to update my office address before my neural probes ship in three days.
If you and your project team can’t summarize a scenario in one sentence, that’s a red flag for the project.
Start with a screen everyone recognizes.
Start with a page you’re sure your audience is familiar with, even if it means taking them out to the corporate homepage and walking them all the way into step 4 of your process.
Yes, your critique members will suddenly notice all kinds of totally unrelated links, images, and features on the home page that have absolutely nothing to do with your project. Politely but firmly keep them pointed toward the goals you set out in your introduction.
Since I’m Caroline, I’m going to come to the defense contractor homepage, then click Accounts and log in… yes? I’m not sure why the log-in button is disabled until the password is entered. That’s Team Hound’s work, but I’ll make a note of it and have them get back to you. We’re going to stay with Team Terrier’s work here, getting logged in, and then clicking Account Profile, and here’s where our new screens begin.
Review your pages
Walk through the scenario. Explain how Caroline’s decisions are consistent with her persona. Point out structural elements, organization, and design decisions your team made. Be prepared to answer questions with the data you gathered during user research. (You did do both quantitative and qualitative user research, right?)
Just as you don’t describe the woods and then mention how Red Riding Hood, Snow White, and Cinderella traipsed through them tree-by-tree, don’t tell your users’ stories by reviewing each page and how your four personas will use it. Connect cause and effect. It’s better to show the same page four times from four perspectives in context of the user’s actual behavior than to make it stand on its own.
Listen and take notes
Be polite. Even if the person speaking is being impolite, or stubborn, or dense as petrified wood, don’t interrupt, and don’t be snappy or impatient in your response. A bad attitude on your part can discourage your reviewers from asking a critical question or pointing out a flaw for fear that they’ll get the same rude treatment.
It can be difficult not to respond to every piece of feedback defensively. Let your work speak for itself. If it can’t, then you do legitimately have work to do to improve it. Decide if this is the right time or place to address the feedback. Is this a hill to die on? Read up on handling criticism. Take classes on it if you can. Stay professional. You choose how to respond, and no one else can choose for you.
Remember that everyone’s listening to everyone else. You can’t fix the problem Joe brought up. Emily wasn’t aware of the problem before, but she can fix it. By allowing Joe to (succinctly) say his piece, you’ve solved a problem for your client that you didn’t even know about.
Take notes or have someone else take them. Make it obvious that you care enough to follow up. Don’t show up at a peer review with no paper and spend the whole time inspecting your fingernails or leaning your chin on the desk. Be an active listener. Respect your reviewers’ time and energy.
The people giving you feedback are doing so to help you improve your work for your client. Make them feel like you’re listening. If you discourage feedback, you’re actively suppressing your own ability to improve.
Thank your audience
Close the meeting as cleanly as possible. Try to be on time or a little early. Thank your audience for their time. If you’ll be following up with them outside the meeting, give honest estimates about when.
Review your feedback
For each of your projects, keep a spreadsheet with columns for date, meeting name, feedback comments, result, and whether the item is open, closed, deferred, or in progress. Review it with your business contacts (to make sure they heard the same things) and assign out work as needed.
Reflect on your own performance, the schedule, and the pace. Did you deliver quality? What could you improve? Is the project still on track or do you need to chat with your boss or your business to update time estimates based on the feedback?
Reflect on your presentation. Did you set the context, as described in the first four tips, in a way your audience could understand? Did you tell a good story?
The last three tips are about accepting other peoples’ stories and feedback. Were you patient with them? Were you able to listen, while still moving the meeting forward? Did you hit your goals? Did you get the kinds of feedback you can act on? How can you make it better next time?
Finally, if you come out of the meeting with more problems than praise, don’t take it personally. Design is iterative, it can constantly be better, and the goal posts are always moving. Remember that “this page is awful” doesn’t mean you are awful. You are not defined by your work. You do, however, define your work, so you may need to iterate and improve on it.
Every one of us does, every time.
An Alphabet of Accessibility Issues
A is blind, and has been since birth. He’s always used a screen reader, and always used a computer. He’s a programmer, and he’s better prepared to use the web than most of the others on this list.
B fell down a hill while running to close his car windows in the rain, and fractured multiple fingers. He’s trying to surf the web with his left hand and the keyboard.
C has a blood cancer. She’s been on chemo for a few months and, despite being an MD, is finding it harder and harder to remember things, read, or have a conversation. It’s called chemo brain. She’s frustrated because she’s becoming more and more reliant on her smart phone for taking notes and keeping track of things at the same time that it’s getting harder and harder for her to use.
D is color blind. Most websites think of him, but most people making PowerPoint presentations or charts and graphs at work do not.
E has Cystic Fibrosis, which causes him to spend two to three hours a day wrapped in respiratory therapy equipment that vibrates his chest and makes him cough. As an extension, it makes his arms and legs shake, so he sometimes prefers to use the keyboard or wait to do tasks that require a steady touch with a mouse. He also prefers his tablet over his laptop because he can take it anywhere more conveniently, and it’s easier to clean germs off of.
F has been a programmer since junior high. She just had surgery for gamer’s thumb in her non-dominant hand, and will have it in her dominant hand in a few weeks. She’s not sure yet how it will affect her typing or using a touchpad on her laptop.
G was diagnosed with dyslexia at an early age. Because of his early and ongoing treatment, most people don’t know how much work it takes for him to read. He prefers books to the Internet, because books tend to have better text and spacing for reading.
H is a fluent English speaker but hasn’t been in America long. She’s frequently tripped up by American cultural idioms and phrases. She needs websites to be simple and readable, even when the concept is complex.
I has epilepsy, which is sometimes triggered by stark contrasts in colors, or bright colors (not just flashing lights). I has to be careful when visiting brightly-colored pages or pages aimed for younger people.
J doesn’t know that he’s developed an astigmatism in his right eye. He does know that by the end of the day he has a lot of trouble reading the screen, so he zooms in the web browser to 150% after 7pm.
K served in the coast guard in the 60s on a lightship in the North Atlantic. Like many lightship sailors, he lost much of his hearing in one ear. He turns his head toward the sound on his computer, but that tends to make seeing the screen at the same time harder.
L has lazy-eye. Her brain ignores a lot of the signal she gets from the bad eye. She can see just fine, except for visual effects that require depth perception such as 3-D movies.
M can’t consistently tell her left from her right. Neither can 15% of adults, according to some reports. Directions on the web that tell her to go to the top left corner of the screen don’t harm her, they just momentarily make her feel stupid.
N has poor hearing in both ears, and hearing aids. Functionally, she’s deaf. When she’s home by herself she sometimes turns the sound all the way up on her computer speakers so she can hear videos and audio recordings on the web, but most of the time she just skips them.
O has age-related macular degeneration. It’s a lot like having the center of everything she looks at removed. She can see, but her ability to function is impacted. She uses magnifiers and screen readers to try to compensate.
P has Multiple Sclerosis, which affects both her vision and her ability to control a mouse. She often gets tingling in her hands that makes using a standard computer mouse for a long period of time painful and difficult.
Q is ninety-nine. You name the body part, and it doesn’t work as well as it used to.
R was struck by a car crossing a busy street. It’s been six months since the accident, and his doctors think his current headaches, cognitive issues, and sensitivity to sound are post-concussion syndrome, or possibly something worse. He needs simplicity in design to understand what he’s reading.
S has Raynaud’s Disease, where in times of high stress, repetitive motion, or cold temperatures her hands and feet go extremely cold, numb, and sometimes turn blue. She tries to stay warm at her office desk but even in August has been known to drink tea to keep warm, or wear gloves.
T has a learning disability that causes problems with her reading comprehension. She does better when sentences are short, terms are simple, or she can listen to an article or email instead of reading it.
U was born premature 38 years ago — so premature that her vision was permanently affected. She has low vision in one eye and none in the other. She tends to hold small screens and books close to her face, and lean in to her computer screen.
V is sleep-deprived. She gets about five hours of bad sleep a night, has high blood pressure, and her doctor wants to test her for sleep apnea. She doesn’t want to go to the test because they might “put her on a machine” so instead she muddles through her workday thinking poorly and having trouble concentrating on her work.
W had a stroke in his early forties. Now he’s re-learning everything from using his primary arm to reading again.
X just had her cancerous thyroid removed. She’s about to be put on radioactive iodine, so right now she’s on a strict diet, has extremely low energy, and a lot of trouble concentrating. She likes things broken up into very short steps so she can’t lose her place.
Y was in a car accident that left her with vertigo so severe that for a few weeks she couldn’t get out of bed. The symptoms have lessened significantly now, but that new parallax scrolling craze makes her nauseous to the point that she shuts scripting off on her computer.
Z doesn’t have what you would consider a disability. He has twins under the age of one. He’s a stay-at-home dad who has a grabby child in one arm and if he’s lucky one or two fingers free on the other hand to navigate his iPad or turn Siri on.
This alphabet soup of accessibility is not a collection of personas. These are friends and family I love. Sometimes I’m describing a group. (One can only describe chemo brain so many times.) Some people are more than one letter. (Yay genetic lottery.) Some represent stages people were in 10 years ago and some stages we know they will hit — we just don’t know when.
Robin Christopherson (@usa2day) points out that many of us are only temporarily able-bodied. I’ve seen this to be true. At any given moment, we could be juggling multiple tasks that take an eye or an ear or a finger away. We could be exhausted or sick or stressed. Our need for an accessible web might last a minute, an hour, a day, or the rest of our lives. We never know.
We never know who. We never know when.
We just know that when it’s our turn to be one of the twenty-six, we will want the web to work. So today, we need to make simple, readable, effective content. Today, we make sure all our auditory content has a transcript, or makes sense without one. Today, we need to make our shopping carts and logins and checkouts friendly to everyone. Today, we need to design with one thought to the color blind, one thought to the photosensitive epileptic, and one thought to those who will magnify our screens. Today we need to write semantic HTML and make pages that can be navigated by voice, touch, mouse, keyboard, and stylus.
Tomorrow, it’s a new alphabet.
“What do you want for dinner?”
“I don’t know. Not chicken. What do you want?”
“I don’t care. Not pizza. Come up with something.”
“I came up with it yesterday.”
We just bought a new home and we’re prepping our condo for sale. We spent two weeks in the old place with a rapidly-shrinking inventory of food because we didn’t want to have to move it. We’re a week into the new place and haven’t had time to food shop yet. We’ve eaten take-out from every restaurant and fast-food joint in town for three weeks.
We’re tired of deciding what’s for dinner.
We don’t have these issues at breakfast. In the morning, we wake up, stretch, get cleaned up, and someone buys breakfast armed with specific lists of choices. The difference isn’t the number of choices or how picky we are. The difference is that when we first wake up, we don’t yet have decision fatigue.
Decision fatigue is the inability to make good decisions because you’ve been making decisions too long. Essentially, the brain is tired of making decisions, so it just stops, the same way that the body gets tired of running and refuses to take another step.
As an Information Architect, I struggle with decision fatigue almost every day. Which projects take priority today? What on this project needs work first? Is this workflow accurate? Should this be a button or a link? Should this be a layer or a new page? Does this design align to our corporate specs? Is it a variance worth changing or fighting for? Do I tell this developer about this tiny bug that’s not hurting anyone? How do I encourage my mentees to do better work? How do I repair this relationship with this business person? Is this an issue worth elevating to my boss? It’s a miracle I can choose what to have for lunch most days, much less get to dinner. If my GPS didn’t tell me which route home had the least traffic, I might not be able to leave the office.
The consequences are real. Poor decision-making ability leads to the inability to compromise, bad financial decisions, bad eating habits, and arguments. When we’re fatigued by too many decisions, we’re more likely to do things with high short-term gains regardless of the long-term consequences, like snacking on candy or telling your boss what you really think.
Since decision fatigue isn’t likely to suddenly stop occurring, I’m doing a few things differently right now than I have for the past few years. I’m trying to make them habits — we’ll see how well I do.
Make decisions that involve other people early in the day. Figure out what’s for dinner at the same time we decide what’s for breakfast. Schedule meetings for critical design decisions as early as possible so that everyone involved is still fresh. Prevent arguments when everyone’s too tired to decide, and prevent mistakes caused when one person’s too tired to recognize that they’re making a bad decision.
Let go of perfect. Acknowledge that the new owners are going to replant the garden no matter what I do at the condo, so I don’t have to “fix” it. It’s OK to sell a house with a thirty-year-old sink even though I swore I’d replace it someday. If the difference between two design elements is a dead tie, just pick one and move on. Tell my developers that something’s a “working copy” and they should expect small tweaks later, so they can start building. Put off decisions about things that don’t matter and stick with the important choices.
Pick whatever is closest to my values. There are two ways to rewire the kitchen so it’s up to code. One of them is “by the book” legal, but carries a slightly higher fire risk than the other, more expensive and more complicated solution. I’m not a fan of fires — we’re going with the safer solution. There are two ways to develop a workflow for a transaction. One makes it easier for my customers to make mistakes than the other, more expensive and more complexly coded solution. I’m not a fan of causing errors — we’re going with the more effective solution. Make it easy to look back on my decisions and say, “it was the right thing to do.”
Build an environment where making good choices is the default. When the refrigerator is filled with cans of soda and the cups are still packed, it’s much easier to drink soda than water. When there are carrots in the fridge and no chips, it’s much easier to munch carrots than chips. When the personas for a project are hanging on my cube walls, it’s much easier to think about their needs. When the company has a defined specification for how to lay out forms, it’s much easier to build good forms. This step takes some up-front work, which makes it easy to put off, but the gains are worth the time spent.
We are our first users — we’re using the workflows and environment that we set up for ourselves to make good decisions on behalf of ourselves, our families, our clients, and our users. We know the consequences of decision fatigue and poor choices better than most. We’re never going to eliminate decision fatigue from our own lives, or from anyone else’s, but by changing our own habits and lessening our own decision fatigue, we can make better choices more consistently throughout the day, which leads to a better experience for everyone.
Tonight we’re having Thai food — pretty much the last restaurant we haven’t visited. Tomorrow we’re making a menu for the week and going food shopping. It’s time to make some good decisions that will make it through the week.
The Ancient Art of UX War
My first year as an Information Architect, I worked a financial dashboard project for a client with the reputation of being “difficult”. The client wanted a specific but complex chart, which their support staff would have to regularly explain to the users. The users wanted a less-robust chart they could understand without asking for help, but it didn’t deliver all the information the client valued. I took the two charts to peer review, convinced that if I could get the backing of some senior IAs, I could force the client to switch to the users’ preferred chart.
Instead, my leaders and mentors viewed the chart problem as minor. “You have a huge gap in your structure in this other area,” they pointed out. “You need to get the clients to agree to fix that first.”
“But the chart-” I objected.
“You have to pick your battles,” one of them told me. “This is a minor problem they’re willing to deal with. That is a labeling and content strategy issue that will affect the whole design. The chart is not the hill to die on.”
Every design project requires striking a balance between user needs and business goals. As User Experience professionals, we’re responsible for representing the messy world of users. We land in adversarial situations, where what we recommend as the best approach conflicts with what our clients or sponsors prefer. Sometimes this happens because our clients don’t understand what we do or the research that backs our recommendations. It may be that we’re unaware of business goals or needs. It can be a result of bad communication. Sometimes we just don’t like each other.
The first step in resolving the conflict is to decide how big a conflict you’re willing to fight. Where is your energy best spent? How can you best represent the users’ needs? You can battle with clients over every detail, or you can choose to work with clients for the things that made the most sense.
You have to decide which disagreements represent a hill to die on.
A few years ago, I created a set of wireframes for a tool redesign project. My proposal made the front end easier to understand by tenfold, but made the back-end more complex (and expensive) to develop. The interface was critical to success. We were in agreement on almost everything else in the project. This was definitely my hill to die on. I researched. I prepped. I rehearsed. I made sure I could tell the story about why this would be money well-spent.
As soon as the meeting began, I charged forward with data-driven and effectively presented ammunition, only to have my legs cut out underneath me immediately by my client’s declaration that there was absolutely no way we were going with that design. End of story. She even called my manager to tell him to tell me we weren’t doing it.
As I lay on that hill that I chose to die on, I found myself wondering how with all my preparation work, I had landed there.
I later learned my client had just arrived from a meeting where the project budget had been slashed for the third time. She felt powerless and frustrated and angry. It didn’t matter that the company was making the hard but correct choice. It didn’t matter that the client actually agreed with me on the project needs. The client felt disrespected, and she weren’t going to take it any more. If I had asked for a quarter for the soda machine, I was going to get mowed down that day.
It wasn’t her emotional state that caused my failure. It was my lack of empathy. I landed on that hill because I had neglected to ask, “How are you?” and “What’s new?” before I ramrodded my opinion down her throat. I forgot that my client was a person. I saw her as a dramatic foil against which I was going to reflect my enlightened Design opinion. Had I asked, I would have better understood the business problem, and we could have worked out a compromise or I could have simply asked for time to do a more appropriate (if not as effective) design.
You don’t have to just pick your battles, you have to make sure you’re choosing a good day to take on the challenge of climbing that hill. It doesn’t just have to be the right hill, it also has to be the right weather.
I had a project that went poorly early in my career, mostly because I am slow to learn when to keep my mouth shut and which hills are worth dying on. Years later, I was assigned a project for the same business client. He was working in a new department and so was I. We had both grown in out soft skills and we were both much more professional than our initial meeting. I wasn’t even working with him directly — I worked with the project manager who reported to him, who I got along with famously. It didn’t matter. When I presented at the first tollgate, I was grilled to within an inch of my life on details that didn’t matter, issues that didn’t exist, anything he could do to try to trip me up in front of the team.
I’d like to say that I was the consummate professional. I wasn’t. I took the bait, and the meeting became a verbal sparring match. I came out “victorious”, if such a thing existed, only because the development and project team backed my designs. It was not my shining moment.
As the second tollgate came around, we knew we had a problem. Some of the work we were presenting would be a hard sell for our budget in the best of cases. The team believed in the work, and didn’t want to change our approach just to avoid conflict. Even though the project manager had never given a design presentation before, she volunteered to present the work.
I hesitated. This was my work, it represented my research, and it was my responsibility. If it needed explanation I felt I was the most qualified to address the questions. If it was lacking, or the sponsors didn’t approve it, I felt I was the one who should take the fall.
But my project manager had been at every major decision point, understood the logic and research behind the decisions, and “got” design. The only thing standing between a guaranteed bad presentation and a possibly good one was whether I was willing to give someone else the responsibility I felt only I could shoulder.
Ultimately, a friend pointed out that my battling with the client sponsor didn’t actually benefit the project. It didn’t benefit my project manager’s relationship with her supervisor. It certainly didn’t benefit me. It was, in short, not in the best interests of my users.
My project manager gave a fine presentation and we were approved to go to the next step even with the hard-sell design.
When you’ve picked your battle and you’ve ensured it’s the right hill to die on and the right weather to do it, make sure you send in the right general. There comes a time for each of us when we may be the most qualified to do a job, but not the right one to do a job. We owe it to our users to ensure the right decisions are made, even when that means we have to hand over the reigns to someone else.