A lot of industries have passionate professionals. A lot of those professionals like to hang around in discussion groups, asking for advice, offering it (frequently without even being asked), bouncing ideas off each other, and debating the ins and outs of a hundred different aspects of the job, whatever the job might be.
A lot of those debates—a lot—end up being about process. They end up being about the way you do things, what order you do them in, and how it all turns out at the end. Process, a lot of people say, is the key to success. To do anything well on a consistent basis, you must be able to repeat what you did well previously. If you can do something well twice, the thinking seems to go, you should write it down, wrap it up, send it off to the textbook writers, the authorities, the experts, and record it in the annals of history. You, after all, now have it all tied up in a pretty red bow. You’ve mastered process.
Trouble is, nothing about the success of process is provable. Not in soft-skill-focused professional work, that is. Not in office life, where projects come with so many variables it’s nearly impossible to find two that are even all that much alike. The number of people, the people themselves, their skillsets, everyone’s time constraints, the budget, the deadline, the reason for the deadline, vacations, health emergencies, holidays, technology, you name it—every last detail of a project is as variable as the last one.
In a couple of decades worth of projects, I’ve never seen a “repeatable process” that could truly be repeated, let alone to the same effect. The only two things consistently in common are the two principal constraints of time and money.
Also, this process thing has been studied. Turns out, it’s not successful at all.
Boxer Mike Tyson once said, “Everyone’s got a plan ‘til they get punched in the mouth.”
This is exactly what it’s like to work under tight deadlines and tight budgets. It’s like getting punched in the mouth. And when time and money rear their ugly heads, process is the first thing to go. People pick and choose what and how something will work, and they do it quickly. Forget process, they say. I have things to do.
Instead, they look around, pick up their proverbial tools, and start hacking away in whatever approach makes sense at the time. They take their tools, and they do something really cool with them.
A respected designer and design manager colleague of mine, Stephanie Troeth, saw this firsthand while working for several years with an otherwise very smart and talented team who couldn’t seem to avoid the pitfalls of process.
“Sadly, they made one major mistake,”she said. “They tried to put in layers and layers of formalized process. When you have a roomful of smart people, you have to acknowledge that they might be able to short circuit the process and arrive at a different way of working.”
I wrote about this in an article for UXPin called “When the Best UX Design Process Isn’t A Process At All”. Here’s a snippet:
Jared Spool has done some research on this. You know the guy—he’s the one who’s been running a design research company and think tank since the ‘90s called UIE. Few people have spent more time talking to designers and companies than Jared.
Know what process he’s learned is the one employed by the most consistently successful design teams? It’s the same one I find every time I walk into one of those conference rooms with a great team.
The improvised process. The one defined specifically for that project, and often not defined at all.
As it turns out, the teams that do measurably good work on a regular basis, with the fewest issues and the fewest failures, are the ones without a de facto process. They’re teams which devise a custom process for every project, and frequently go into a project without one at all. Conversely, the teams which most consistently accomplish the mediocre—that dirty, awful word—are the ones who live and die by their processes.
I know. It’s nuts. But is it? Think it through.
The teams who succeed the most are the teams full of people who work well together—who communicate well together—and who have a broad range of skills and tools they can apply at any given moment. They approach problem-solving in a way that works with the constraints of the situation. They have all the UX tools you can find—strategy definition, user research, UI design, prototyping, usability testing, data analysis, and on and on. To do their work, they pull out what they need, when they need it.
- At the beginning of a project, gather around and decide together what design activities will be appropriate for the situation, whether thorough user research combined with rapid usability testing with paper prototypes or some other combination of things that will give you the best insights.
- At every point of the project, hold design brainstorms and reviews so that everyone can continually keep each other in check with regard to the goals of the project and how well the team’s ideas support those goals.
- Ensure that everyone knows who has final design decision-making power, and that this person relies heavily on evidence and solid rhetoric rather than whim.
All that said, the incredible willingness of teams to forego formality and begin scrapping their way through a project is far from the best reason to let your team focus on tools rather than process.
The best reason is that it gives them autonomy, and teams need autonomy to feel good about their work. It’s crucial to a person’s sense of intrinsic motivation.
Daniel Pink talked about this in depth in his book, Drive (Riverhead Books, 2011). In it, he posits that autonomy is one of the three things needed for a person to feel fulfilled and motivated by a job or task, besides mastery and a sense of purpose (seeing how one’s work maps to the company’s larger intentions). The ability to make decisions—to choose how to approach a challenge, and to execute on it with a hand in the decision-making process, is key. Minus autonomy, people are just following orders. And that’s not fun for anyone.
Autonomy makes people better, which makes outcomes better. Nurturing this approach within your team can mean better results and a happier staff. Orders are for drive-thru fast food joints. If you want great work from a team, the people on it need the autonomy to use their tools in whatever way they see fit to achieve success.
Of course, this right to improvise has other benefits, too.
It means your team will be able to invent new ways to get things done, which goes right along with your new mission of finding ways to improve your profession (see the section about T-shaped people in the previous chapter).
I wrote about this in Experience Required:
Improvisation can get you more resources out of a slim budget. It can get you impromptu coding tests to validate someone’s guesswork. It can get you through a usability test with a crashed laptop by sketching screens on napkins and stepping through a task flow anyway.
Your ability to improvise doesn’t just help you. It helps the other people involved trust you. Depend on you. It makes them come to you when they can’t think up what to do next.
Psychological studies have shown it’s more difficult to have good ideas and make good decisions when you’re under stress. Staying aloof to a certain extent can give you the brain space you need to bust out a good idea under bad circumstances. Being able to improvise shows you can keep a clear head when a project goes wrong, and approach situations with a level of calm not everyone has.
It also gives the impression of experience, even if you don’t have any. So many designers leap to solutions devised in a panic. An experienced designer stays calm, shuts up for a minute, thinks through the angles and asks questions about the constraints and looks around for anything that might help in the moment, then pitches something no one else has been able to think up.
I worked with a programmer once who could do this.
I’ve always thought it takes a certain kind of mind to be a brilliant engineer. This guy was the poster child for it. When people got stuck, he’d sit next to them, stare at their screens for a few minutes, ask some questions, and then tell you to do something that sounded like it’d come out of left field and which worked on the first try. It was virtually the opposite of everything you’d tried. You’d spent five hours on the effort only to realize you’d been approaching it the same way the whole time and that your approach wasn’t going to get you anywhere. (Granted, I was a mediocre programmer. But even if I’d tacked up five more years of experience, I’m pretty sure he’d still have been faster than I was in situations like that.)
It was downright satisfying to watch someone do this. It still is. It’s the kind of thing that makes you sit back and ask, “How did you do that?”
After a bunch of years of experience, people might start asking you that question. In the meantime, you can fake it. And faking it will help you learn how to do it.
Improvisation shows competence. It shows situational awareness. It shows intelligence. It shows you truly have a grasp on a bunch of different concepts and skills, and are able to pluck them out of the sky at will, rearrange them, and make them into something new. It means you understand concepts over prescribed actions and can apply them to any situation, dire or stable. You’re not the kind of person who sees one way to build a table and runs to Home Depot as soon as it goes awry. You’re the kind of person who walks back into the shop, picks up a screwdriver, a piece of scrap wood, and some glue, and sorts it out.
You’re the one who gets things done.
This makes you especially useful when deadlines are tight. Which is most of the time.
There is one other reason to focus on what you do over how it gets done. It’s this:
What gets done is the only thing anyone really cares about.
In other words, there’s a public perception—the perception of the higher level managers, the execs, the customers, the shareholders, and everyone else—that matters far more than how you do something, and that’s simply that you did something. That you are actively doing something now. That you will do more in the future.
This is what people who sign checks care about. And as a new manager, it’s a great way to show them you’re focused on the business, not just whatever skill you’d gained competency in before leveling up. Now that you’re a manager, your job is to think about how the things your team does now will help the company later. Once the team does those things, your job is to go tell someone about what was done.
It’s rare that someone will argue against your methods for having achieved said outcome. If they even ask, it’s usually out of curiosity. Everyone else is winging it, too. They just want to know if you came up with something cool that they can try out on their own teams.
Odds are, absolutely no one is watching your every move to make sure you followed some strict process letter by letter. They have their own problems, their own work to get done, their own anxieties about whether or not they’re doing it well. All you need to worry about is being able to say you got the thing done. That’s what will demonstrate your team’s abilities. That’s what will earn you successes. That’s what will earn you the respect you want so that you can get in on more interesting projects later.