Code Sketching – A Stretch Goal for Your Design Superpower

“Eventually, we stopped showing our design comps by projecting them from a desktop machine onto the wall.” That’s how Ethan Marcotte described the process behind one of the first big responsive design projects, The Boston Globe’s new web site. “Instead, we’d bring in a big bag of assorted devices and let everyone hold our ideas in their hands.”

By having the comps on a variety of devices, Ethan and the rest of the Filament Group could show their Boston Globe client just how the experience across different devices would be. “No two people in the room were having the same experience.”

This repeated demonstration helped Ethan and his team hammer home the importance of supporting multiple devices. They didn’t build a lot of technology to make this happen.

Instead, they created some quick sketches of how they imagined the new site would work. The Globe’s team could give them constructive feedback and ask interesting questions. They could compare the design across the different devices, from Blackberry’s to feature phones. They could see first hand what that experience would be like.

A Cross-Platform Design Essential

Our designs flow and move. Expressing the subtlety and nuance of how we imagine our designs is hard to do with a static sketch. Microinteractions are essential for a good experience, but difficult to imagine by just looking at a picture.

We compound by desiring to express how the design will change as we move across platforms. We need to see if we’ve made something too complicated. Maybe we’ve left something important out? Maybe it’s too clumsy when there’s no keyboard?

Building the entire design to discover an important flaw is a time-consuming and expensive process. We want to get our ideas out there for review and reflection. How do we make it easy to do and cost effective?

Example: Interactive Site Map

In her UX Thursday talk, the American Cancer Society’s Melinda Baker talked about a reorganization of the research content on the non-profit’s website. After several struggles trying to explain to the organization’s various stakeholders, she brought out the interactive site map her team had whipped together. Suddenly, everybody was on the same page about how they saw the research organized.

In the past, a static, paper-based site map would have been enough. However, with a static site map, the entire hierarchy is always visible. It’s not easy to see where labels, out of the context of what’s hidden below them, might not make sense.

By using simple coding techniques, Melinda’s team created a site map that could be expanded and collapsed. She could show the entire hierarchy, hone in on just the top level, or show a likely path a user might take.

The stakeholders could play and see what felt natural and what felt forced. From this interaction, the team received much richer feedback and quickly got to an information architecture that made sense to everyone.

Seeing Your Design Through Their Eyes

On the Boston Globe project, Ethan and his Filament Group team members were comfortable throwing a little code together. That meant they could make something that would pretend to work on multiple devices. They could show the Globe’s stakeholders and executives what a cross-platform design could be.

Ethan and the team then got to see their design through those Globe’s executives’s eyes. It was easy to see what was working across all the devices and what still needed improvement.

Getting this feedback early in the project gave the designers tremendous flexibility. They could make huge shifts in direction. They could experiment with a variety of approaches. Each time, they got more feedback and learned more about what the design wanted to be.

That’s how a sketch works. A code sketch is no different than a static napkin or whiteboard sketch, except that it shows these interactive elements. It provides the team with a way to collect constructive and affirmative feedback from the client and stakeholders.

Example: The Microinteractions of Refresh

Getting the design of a microinteraction like an application’s refresh behavior is really tricky. It’s hard to get it just right.

There are always a ton of questions: What’s the best way to give a clue to users about the function’s presence? How far does the user pull it down? How fast does it snap back? Is there a spinner during the refresh process? Is it asynchronous or does the user have to wait until it finishes? What does the app do if there’s a communications error with the server? Does it put a dialog that the user has to dismiss? Is it just a message that appears momentarily? How long is enough time for that message?

All these questions can’t be easily answered with a static sketch. But you could build little simulators that get to the heart of each one. Behind the scenes, the interactive sketch isn’t doing anything. There is no real refreshing happing. There is no communications with a server to suddenly sever.

But to the user, you’ve created the illusion that all those things are happening. And because of that, you get to see if the design is going to work. You might even be inspired to try something different, to explore alternative approaches.

And that’s where the real insights and innovations happen. By mastering your code sketching skills, you can try out these ideas.

Overcoming the Fear of Code

It’s common to see a designer pick up a marker and sketch out an idea. This has been a core skill of UX designers for a while. Many carry notebooks filled with ideas and variations on the possible.

Yet there’s no faster way to get some UX designers to freeze up than to say they may want to learn a little programming to get their ideas out. Picking up programming skills for simple user interface sketches is quite easy.

For most, it won’t take more than a dozen or so hours. It’s a combination of basic HTML, CSS, JavaScript, and jQuery. (At our conferences, we teach the JavaScript and jQuery bits in less than 6 hours.)

This isn’t in-depth study. It’s enough to produce ugly, but functional code.

Maybe that’s where the fear comes from? That designers are afraid they’ll be judged on the quality of their coding? Yet these same designers aren’t concerned about the artistic style of their napkin or whiteboard sketches.

Sketches need to communicate the idea, whether on paper or in code. That is all.

Practice Makes Mastery

Anyone who starts writing code is uncomfortable at first. But that’s solved with practice. (Those same designers were probably uncomfortable sketching on paper at first, but years of practice have worn that discomfort away.)

Practice is different than project work. When we practice, we focus on the process, not the outcome.

To practice code sketching, we need to start mastering the basic coding techniques. Come up with different ways of rendering ideas. Look at the source code of others and see how they do it differently. Play with the available plugins and libraries. Constantly try to expand what you can do.

Practice can be more effective when we practice with others. We can see how they tackle the same idea as we do, but with a different approach. When we’re stuck, we can get their assistance. When they’re stuck, giving them assistance helps us understand the underlying concepts better. (You don’t really learn something well until you’ve taught it someone else.)

Code sketching isn’t an innate talent that only a few will ever be effective at. It’s a simple skill that takes practice to master.

Once you master the simple techniques, you’ll have one more tool in your toolbox to share ideas. And getting your ideas out there for retrospection is the best way to get to delightful designs.