Designing in the Open
Recently I was contracting as a UI designer/front-end engineer with the team at Hearken. The team is remote-first, headquartered in Chicago; and I’m in New York. So, like many teams who work remotely, we spend most of our days on Slack.
This story begins in a familiar way: their web app’s interface was built on the Bootstrap framework, and it was time to build a custom UI system to replace it. I’d done similar work with previous teams, but a few factors made our situation different.
We’d decided to do the work during December; most of our customers would slow down for the holidays and we’d have some time to focus. In order to get done by the new year, though, we had to begin integrating with the codebase by mid-month. And at the end of November, design work hadn’t started yet. We needed a way to get it done fast.
Corey Haines, the CTO, surprised me with a process idea: why not do the design work in a Slack channel, thinking through the problems out loud, and delivering mockups in real time?
Corey has a lot of Agile experience, and he recognized a major factor that would determine how quickly the design stage could complete: the time it would take before we could get feedback. It’s a core idea of Agile software development, and the benefit is so clear it reads like common sense: the sooner you can get feedback, the less you can have strayed from the goal; and, accordingly, the fewer corrections you need to make after each deliverable.
If you’ve done design work or spent time around designers, you know that they don’t generally work this way. In fact, I’d never heard of anything like this being done as part of a design process; maybe collaborative work within a design team, but not in front of stakeholders. Creative work, many will argue, requires a criticism-free space for exploring possibilities; and a design direction needs to be fully realized — to avoid “design by committee” — and presented cleanly to stakeholders with each decision confidently justified, so they’ll buy in.
Corey’s proposal was promising in terms of project management. But I had my share of hesitations about presenting each half-baked design idea, as I had it, to the group for thorough scrutiny. And was this really supposed to be faster than cranking out a solution with no distractions? These are very common first reactions to Agile processes, by the way, and ones I was familiar with. But since the topic was design and not software, it was harder for me to recognize them for what they were.
My experience as an engineer, on the other hand, agreed with the practical bent of his idea. With our timeline, we didn’t really have any other choice. I decided to take the leap. Here’s what happened:
It helped. I found designing for an audience of stakeholders clarified my thinking and sharpened my communication. I had to justify decisions that were so small, they would have gone unnoticed if I were working alone, and I think that strengthened the direction. It took focus to communicate this way, but because the process was visible, it was easy to put techniques and proposals into context. Before long, talking through it with the team was second nature:
And, very helpfully, it collapsed the tasks of feedback and requirements-gathering into the design context. If I needed information about a feature’s priorities or the use cases it served, I’d ask the group, and a quick discussion could form around it:
Here are a few things that helped it work successfully:
1. “Feedback is a gift, not a demand for change”
We planned to make sure feedback would be helpful, but wouldn’t derail the momentum of the design work. We made it clear to the team that I wouldn’t always be available to start a conversation on a given topic, since we were under pressure to complete the project on time. In return, I’d summarize my work at the end of each day, and make time to have discussions on specific topics.
2. Team attitude of generosity
When I needed feedback or insight, I reached out to @channel or to a specific teammate. The team were fantastic at giving design feedback. Their points were always well-reasoned, constructive, and, most of all, generous; I think they knew how much I was risking making a fool of myself. As promised, I got a lot of good ideas, that I never would have come up with, by sharing and seeking their input early.
3. Produce code as soon as possible
Since this was mainly a visual design project, it made sense to deliver at high fidelity. I did my work in the browser with HTML/CSS most of the time. We set up a fast, simple deploy process to a staging server, so that the team could see and use the pages I was building as soon as possible in the browser context, even if they weren’t finished yet.
I’ve continued to use what we now call an “in the open” process for every effort with the team since (I joined Hearken full-time shortly after this project was done). If your team uses Slack and works well together in design review, I highly recommend stepping out of your comfort zone and trying it.
For more about Duncan’s work head over to dmalashock.com.
