Predictable behavior

One of the things UX/product designers do is predict the way people will use things. It helps us prevent errors and usability problems. It’s one of the core skills of a good designer, and one of the problems we must solve first; before we decide what it looks like, or how it will make you feel. I mean…unless you’re a bad designer. Then you design things for how they will look in the pages of your favorite design magazine (if those are still even a thing), or to placate your most opinionated stakeholder. I guess it depends on whose validation you crave the most.

Anyway. I digress.

We should be designing things based on how we expect they will be used. It seems simple enough, but it’s this very basic idea at which we fail again and again, especially when we design online systems. We consistently fail to predict, and design for, people using the systems we design inappropriately.

It occurred to me this morning, as I was reading yet another exposé detailing Facebook putting its thumb on the scale in order to avoid receiving criticism from right-wing media pundits while listening to a podcast wax comically about the nudity police on Instagram; that this failure is not a failure of design to predict the behavior, but a failure to accurately calibrate the idea of “appropriate.”

Or, said another way; the problem is not that we can’t predict the behavior and design for it, it’s that we don’t agree that the behavior is inappropriate.

In this example, we seem to all be aligned on the idea that online services that allow children to have accounts and post content should not allow nudity, but we’re not aligned on whether or not we should allow that same platform to be used to spread hate speech, organize domestic terrorism, or manipulate people’s emotional health.

When you think about it, especially considering the problems that a platform chooses to fix, versus the ones it chooses to fix (or fix poorly); what they are really telling you is which uses of their platform are appropriate or inappropriate. Or, at least they’re telling you which behaviors they’ve decided aren’t deal-breakers because they’re important to their most opinionated stakeholders.

If you want to go quickly…

There is an almost certainly apocryphal proverb that goes something like, “If you want to go quickly, go alone. If you want to go far, go together,” and I think of it often when trying to take on large/complex projects, because I see this thinking get a lot of teams in trouble.

One of the things we have to do when we, as designers, take on large projects is integrate complex sets of requirements; but that’s really hard to do with the “two-pizza teams” favored by adherents of this particular folk wisdom. Those teams are designed for speed, because (let’s face it) speed is almost always a requirement. That isn’t a bad thing. The longer a project goes on, the more likely it is to fail or get cancelled. Speed is a determining factor for most projects. The fault lies not in prioritizing speed, but perceiving it as a binary, and as a constant.

So, what do you do when you need to go quickly and go far?

I propose you oscillate between going together, and going it alone. Or, to keep things in the realm of apocryphal proverbs, you oscillate between Two-Pizza Teams and It Takes a Village. Recognize that there are times to go fast, skimming the surface and plowing through (or skipping off) surface-level disruptions; and times to slow down, sink in, and roll with the waves a bit. I know. My metaphors are all over the place.

This requires that you spend your time building a coalition of people who trust you and understand that there will be times that you will need their attention, and times when you don’t. There will be times when it seems like you’re ignoring them, and times where you will be joined at the hip. There will be times when you are asking them to weigh-in, and times when you are asking them to butt-out.

It takes an enormous amount of trust to get that last part to be okay; but that’s what it takes to do the big stuff quickly and well.

This, for what it’s worth, is why I end up being a proponent of facilitated collaboration methodologies like Design Thinking. At the points where you need to get input from that coalition, a well-designed workshop (or series) is a great way to get what you need from those people, while setting the ground-rules for asking them to get out of the boat so you can start going fast again.