Design is long division

Let’s start with the basics: I am part of the design effort at Ushahidi. Ushahidi is a mostly distributed, mostly asynchronous organization. We are 30-ish people working in 10 different countries and, I think, 8 timezones. It is a wonderful, singular organization that has forced me to re-think most of what I knew about collaborating as a designer. First, I want to back up a bit and explain how I worked before Ushahidi.

The “big reveal” as the consensus-building technique of the “real” creative.

I learned early and often that a UX designer is not a ”Creative.” I got my first design job after grad school at a massive marketing agency in Toronto. Filled with naiveté and an impostor complex, I idolized the agency’s art directors. I never went to art school. I got a BA at McGill in Montreal. I learned German, practiced swearing in Quebecois French, read history books, learned to cook, how to drink, to think, to wear scarves, you know…Montreal stuff. I learned a lot of things, but design wasn’t one of them. At the agency, our little team of “Experience Architects” didn’t sit with other designers and writers in “the pit” downstairs. Those folks were the “Creatives.” I came into my design career in a context where I could be a designer and yet not “creative” at the same time.

We worked with the Creatives all the time, though, and I learned that they were partisans of the “big reveal.” As an example of the enmity between us, let me explain a particular client presentation with an art director whose name I’ve now forgotten. I sat down in a room with him, and I introduced myself. I think I used a title like “Information Architect” or “Experience Architect”, which seems quaint now. He sat there with a stack of crisp tabloid-sized printer paper face down on the table in front of him. I’ve since learned to recognize this as the shibboleth of the big reveal. The first thing he asked me was, “What do you even do here?” That word “even” said everything about the Creatives’ opinion of the us. In his defence, UX wasn’t even really a thing yet. We were calling meetings trying to teach our own devs about responsive design in those days. But there it was. With no witty retort, I sat down, shut up, and endured his inane client presentation.

The client arrived. Handshakes, pleasantries. He stood up, paced dramatically in front of the boardroom table, flipped the stack of paper over on the table in front of him, and boom: the big reveal. On the table were several pages of pixel-perfect, high-gloss, tabloid-size mockups. To this day, the agency had the best printers I’ve ever used. He’d spent weeks on these printouts. I can’t remember what they looked like, but I remember the client standing there there, stroking her chin for a few moments, tilting her head, and making some arbitrary changes to the designs. That was it. We moved on.

Secretly I wanted to be like that guy. I envied his confidence. In a way, I still do. He knew exactly what was expected of him, he had generations of famous designers as fore-bearers and accepted wisdom and art director lore as mental armature for that meeting. I think of it like an equation. Performance + charisma + beautiful work = authority. Some mystical combination of that authority and your client’s mood on that particular day would decide the fate of the work you’ve done. I can’t help thinking about Mad Men and Don Draper when I reflect on this style of consensus building (which is really what it is).

I would love to sit here and bash the big reveal, too, but the more I think about it, the more I convince myself that this is actually a great way to sell design work in a marketing context. Your audience will probably only see your work for a split second, and so your client should know in a split second whether or not it works. The persuasion needs to work like an ippon in judo. Your unassuming audience/client sees your work, and in a split second: wham you’ve floored their critical faculties and they want to buy whatever you’re selling. If you’re making persuasive deliverables to convince in an instant, it makes sense to sell the work in an instant, too.

I didn’t work that way, though, even though I wanted to.

“Put it on the wall”: Persuasion through ambient information

My first real design boss had a very particular way he wanted us to work. He never really explained why, but it makes sense in hindsight. The big reveal is a terrible way to sell complex software products. You need to align a whole village of stakeholders to make it work. Unlike the instantaneous brain-coup of persuasion required by an ad campaign, digital products require longer-term engagement and months or years to build. You need to prove the soundness a product’s entire conceptual foundation. Plus, we were a scrappy team of proto-UX-designers in a massive, traditional marketing agency. I suspect our boss knew that his tiny, rag tag team of pseudo social-and-cognitive science nerds cum design fans would never be able to command the same level of respect as the haughty shock-and-awe creative types downstairs. I think that if we went toe-to-toe with those folks, Draper-style, they would have eviscerated us.

So we worked differently. We “put it on the wall.” We read Lean UX, we tried to “get out of the deliverables business.” We covered big black foam boards with sketches and scraps of paper. I spent a day learning how to draw different kinds of arrows and pointing fingers. I read Bill Buxton. Post-it notes became our stock and trade.

Here’s the thing, the fancy mockups that the “real creatives” downstairs were making could get pasted up on the wall alongside my crappy sketches and feel like they belonged together. Now we were collaborating. I saw the power of laying out your entire thinking process, warts and all, as a way of claiming expertise and authority. It created transparency and humility. Clients could approach you like a normal human who thinks logically and deeply about problems instead of a mercurial “Creative” who plucks precious inspiration out of the ether. They could see exactly what they were buying into from the very beginning.

I realized that design is long division; you get points for showing your work.

This method of working served me well for years. I did it without thinking. It taught me the value of sketching. It taught me how to think with my hands, to think spatially, to think in materiel. Ethnographers have been doing this with field artefacts for centuries now. They understood the implicit persuasive power of stuff. As a practitioner, it feels like magic. You take ideas, make them physical, and distribute them in space so that the space itself becomes suffused with ambient information. By merely entering that space, a stakeholder seems to admit, at least a little bit, that the ideas on the walls are valid. A designer just hand-talks at the whiteboard to tell the story of how the shitty drawings or scraps of paper connect. Usually, it works. But it doesn’t work anymore.

Design in a workplace without walls

The entire outward-facing part of my design process depended on one thing: co-presence. A building, an office, a meeting room, where I could breathe the same air and look my collaborators in the eye. The space itself does the majority of the persuasion in the hand-talking at whiteboards school of UX design, but Ushahidi has no shared, physical space. Outside of a small office in our birthplace and spiritual home, Nairobi, we have no walls to steep in ambient design.

I went through a hilarious couple of weeks where I tried to mount giant sticky notes on the wall behind me, and I aimed a webcam at them. The folks on the other side couldn’t read them because they were mirrored in Hangouts and it was impossible to get the notes and my hand-talking in the same frame.

I tried posting my terrible sketches into a dedicated channel on Slack. This tactic, at best, evoked some hilarious GIFs, and at worst, was completely incomprehensible spam. The sketches only work with a designer there to explain them in real time, to contextualize them and connect them with the broader goals of the work.

Design is still long division, though. I still need to show my work, especially at Ushahidi. We use a holocratic, flat organizational model, and we make many decisions through broad consensus. I also have a far flung team of talented, critical people to learn from and collaborate with. We treat feedback as a gift. In this context, the transparency of design as long-division has become more important than ever. I’ve spent the last 8 months or so adapting my design process to this new reality.

Write

The short answer to where I’ve landed for now is that I write. I write a lot. What do Git Hub, Slack, Google Docs, and Gmail (Inbox) all have in common? They are mostly text. I learned Markdown (well, I bookmarked this cheatsheet). Hand-talking at a white board became, as much as possible, clear, concise writing. I like to think that I am becoming a better designer as a result. I read an essay by Barbara Ehrenreich a few weeks ago where she describes this power of writing,

“I had discovered that writing — with whatever instrument — was a powerful aid to thinking […] if you can condense today’s thought into a few symbols preserved on a surface of some kind — paper or silicon — you don’t have to rethink it tomorrow […] writing makes thinking easier.”

Writing has forced me to think through and organize my thoughts. It has introduced more clarity and concision into my thinking and, as a result, into my design practice. It used to be that a case study is something that I’d write to spruce up my portfolio, but now I write a pseudo case study for almost every new feature we build. This has opened some tricky new questions: what to write, where, when, and how?

Right now, the workflow looks like this: Put your design deliverables in a format that works well with your teams tools. I’m not going to use this to weigh in on the design tool wars, but right now an Adobe XD prototype link with another link to the design spec that Adobe spits out seems to be working. If I were a competent FED, I’d be outputting prototypes in code, but that’s another story for another day… You could use InVision and Sketch Measure to do the same thing. Attach those to a GitHub issue that dovetails with the dev team’s workflow. Brag about it a lot in the appropriate Slack channels. Write a succinct version of how you ended up with that particular design in the GitHub issue, link your user testing plan, and test results (for us, these live in Google Drive/Docs), as well as any iterations of the design as they come up. Invite feedback on the prototype itself (or anywhere where it won’t get lost). Explain repeatedly, to everyone you work with, that this is the latest iteration in a long saga of how you want to work, and invite their feedback / tensions.

For now, this seems to work for us, and if you’ve followed along this far, I hope you can take something from it, too.

The next chapter

The how-designers-work-with-everyone-else saga continues. The latest change is that another designer, Eriol, joined Ushahidi, which is fantastic, and we are both adapting our working styles as a distributed, asynchronous design team. We are also exploring what it means to design within the context of the open source community, and trying to figure out how to “open up” our practice to others in exciting, somewhat scary, non-exploitative, mutually beneficial ways. Writing, here and elsewhere, will become a big part of that exploration. Stay tuned…