JZ Jeff Zych

Icons are the Acronyms of Design

In The Elements of Style, the seminal writing and grammar book by Strunk and White, the authors have a style rule that states, “Do not take shortcuts at the cost of clarity.” This rule advises writers to spell out acronyms in full unless they’re readily understood. For example, not everyone knows that madd is Mothers Against Drunk Driving.

Acronyms come at the cost of clarity. “Many shortcuts are self-defeating,” the authors say, “they waste the reader’s time instead of conserving it.”

Icons are the acronyms of design. Designers often rely on them to communicate what an action or object does, instead of simply stating what the action or object is. Unless you’re using universally-recognized icons (which are rare), you’re more likely to harm the usability of an interface.

Do you know what the icons on the left mean? Do you know what the icons on the left mean?

So as Strunk and White advise, don’t take shortcuts at the cost of clarity. “The longest way round is usually the shortest way home.”

Tags: design

Designing Backwards

Action is the bedrock of drama. Action drives the play forward and makes for a compelling story that propels the audience to the end. And an engaging play is just a series of connected actions, according to David Ball in Backwards & Forwards.

Like a play, the user’s journey through your product is also a series of connected actions. Every click, tap, and swipe is an action users take. But unlike the audience of a play, which is just along for the ride, your users are in the driver’s seat trying to reach a specific goal. If you, as the designer, don’t make the series of actions to reach that goal clear, your users will get lost and your product will fail.

To help authors write engaging plays, David Ball recommends starting at the end of the play and identifying each preceding action, all the way back to the beginning. By looking backwards, you can see the specific steps that led to a particular outcome. “The present demands and reveals a specific past. One particular, identifiable event lies immediately before any other,” he says.

Looking forward, on the other hand, presents unlimited possibilities. The outcome of an action can trigger any number of other actions. You can only know which specific action comes next by looking backwards from the end.

This technique applies just as well to designing user experiences as it does to writing plays. Start by identifying the user’s goal, then walk backwards through each action they must take to get there.

An example makes this clearer. Before we launched native mobile A/B testing at Optimizely, my colleague Silvia and I re-designed the onboarding flow using this technique. (Silvia wrote about the onboarding flow on Medium.)

We identified the user’s goal as creating their first A/B test. We arrived there by understanding the problem that A/B testing solves for our customers, which is to improve their app and ultimately make their business more successful.

If we had started at the beginning and worked our way forward, it would have been easy to stop once they installed our mobile SDK. But installing an SDK isn’t the customer’s goal. There’s no inherit value in that – it’s just a stepping stone to getting value out of our product.

Then we walked backwards through each step a user must take to reach that goal:

  • Goal: create your first A/B test.
  • To create an A/B test, you must install the SDK.
  • To install the SDK, you need to download it and add an account-specific identifier to your app.
  • To download and set up the SDK, you need an account and a project ID.
  • To create an account and a project, you must sign up by entering your info (name, email, billing info, etc.) in a form on our website.

Just by writing out each step like this, we eliminated excess steps and didn’t get distracted by edge cases or side flows. We had a focused list of tasks to design for. And at the conclusion of each task, we knew the next task to lead the user to.

Using this series of steps as a skeleton, we were able to design an onboarding flow that seamlessly led users to their goal. The experience has been praised by customers, and none of them have needed any help from our support team to create their first test.

So next time you’re designing a complex flow, start with the user’s goal and work your way backwards through each action they must take to get there. This technique will put you in an empathetic mindset that will result in user experiences that are clear and focused.

“Of such adjacent links is life — and drama — made up,” says David Ball. And so is product design.


Play the Right Note

Like many Americans, I started learning guitar back in high school. I began where everyone did – strumming basic chords and melodies and building up my finger strength. I got a little better every day, and could eventually play simple songs.

I kept practicing and getting better and pushed myself to learn advanced techniques. I wanted to know how to play all the notes — every scale, every chord, alternate picking, sweep picking, tapping, and so on. I didn’t want my technical proficiency to limit what I could play.

Over time I built up a repertoire of techniques to use. Even though I could play a lot of technically advanced parts, I didn’t necessarily know how to play the guitar well.

When he was developing as a writer, David Foster Wallace (author of Infinite Jest) had a similar focus on the advanced stuff. In his multi-day interview of the author, Although of Course You End Up Becoming Yourself, interviewer David Lipsky asks Wallace what his younger self would think of his new work, and if he thought things like character were pointless. Wallace responded with:

Not pointless but that they were easy. And that the hard stuff was more, you know, front of the head. It’s never as stark as pointless or not pointless. It’s, you know, what’s interesting, what’s advanced, what’s next? It’s gotta be — right? Not what’s true, but what’s fresh and novel and whatever. It’s very difficult to get out of that.

In his early work, David pushed himself to produce advanced work that would be considered “fresh” and “novel.” Not because that helped him communicate a larger truth to his readers, but because he wanted to push himself as a writer.

I’ve observed this focus on technical mastery in every creative field. Young filmmakers care more about getting the perfect lighting and shooting on film (rather than digital) than they do about story (check out the HBO series Project Greenlight for great examples of this). Digital product designers create slick UIs that look great on Dribbble, but aren’t usable or feasible or valuable. Programmers build technically impressive solutions to problems that don’t exist.

It’s easy to focus on this “hard” stuff because it has a clear path forward. Just practice what you aren’t good at and you’ll improve. And by learning the “hard” stuff, you’ll distinguish yourself from amateurs and beginners. When I was in high school, this is what I thought it meant to “master” the guitar.

As a result, I overlooked the “easy” stuff. The “easy” stuff is knowing when to use advanced techniques, and when to do something simple. It’s using your skills in service of achieving a higher goal – writing a song, communicating a truth to the reader, telling a good story, building something useful for people, etc.

I’ve since learned that to truly master your craft, you need to know the “hard” technical skills, and how to use those skills. So don’t just focus on learning all the notes. Learn when to play the right note, too.


Color Saver

This weekend I built a quick Mac screensaver that displays the current time as a color. The hour is mapped onto the red channel, the minute onto the green channel, and the second onto the blue channel.

I was inspired by What Colour Is It, which converts the current time into a hex value (e.g. 11:02:47 is #110247). But What Colour Is It doesn’t map to every hex value. Its range is limited to #000000 (midnight, AKA black) to #235959 (11:59:59 PM, a darkish blue green), which misses brighter colors closer to white (#FFFFFF). Instead, Color Saver maps the time component onto the full range (0–255) of each color channel.

I experimented with mapping the time components onto hue, saturation, and lightness instead, but that resulted in more ugly colors more often. For example, when seconds represent the color’s lightness, the color will go from completely black to white in the course of a minute, every minute of the day. I found this to be jarring and unpleasant. Mapping onto the RGB channels instead is more calming and mesmerizing.

Download Color Saver from Dropbox. Note: I didn’t code sign the screensaver, so when you double-click to install it you’ll get a warning that it’s from an untrusted source. You’ll have to make an exception in the “Security & Privacy” section of System Preferences to install it.

Feel free to check out the source code on Github.

Tags: projects

Things I Learned in 2015

I learned that writing helps clarify my thoughts. It makes me much more articulate. It forces me to engage with a topic and wrestle it to the ground so that I understand it much more deeply than I did when I started.

I learned that writing is hard. But like design and code and tennis, it’s a skill that can be practiced and learned.

I learned that blogging consistently is hard. Coming up with ideas and pushing them out into the world takes work, and takes practice to form into a habit. I learned that I’d rather focus on quality and writing about what I think is interesting, even if that means I don’t publish as often.

I learned that even when I have a lot of ideas to write about, not all of them are worth working on. I’m okay with letting ideas go rather than trying to force myself to work on them. I’ve learned this is a good litmus test for knowing what’s worth spending my time on. The most interesting topics will naturally drive me to work on them.

I learned that it’s just as much work, often more, to promote your writing, as it is to do the writing itself. I learned what it feels like to have a post at the top of Designer News. And I learned what it feels like when people misinterpret what I was trying to communicate.

Just like writing, I learned that dating takes a lot of time and energy (even when it’s online). I learned that I can’t put in that time and energy unless I’m attracted (both mentally and physically) to a woman. I can’t force it. I learned that even with online dating, or because of it, it will take a lot of dates before finding someone who feels “right.”

I learned that most single people of my generation, both men and women, are frustrated to some degree by dating. Online dating has made it easier than ever to meet people, but the increase in quantity has not increased the quality.

I learned that an abundance of choice — in products to buy, shows to watch, people to date, articles and books to read, etc. — increases the pressure of making the “right” choice. There’s always a nagging question of, “Is there something better?”

But I also learned that perfect is the enemy of done. There is no perfect. I need to continue practicing making a decision and moving on, without stressing about whether or not it was the “best” choice. There will always be a better choice, despite my best efforts.

I learned I enjoy management, more than I expected. Including the people management part (career development, promotions/raises, etc.). I learned transparency, candor, and empathy go a long way towards quelling people’s anxieties, especially amongst organizational change. And especially when delivering “bad” news, or giving critical feedback. This is as true for personal relationships as it is work relationships.

I learned that providing context, the “why,” behind a decision is more important than the decision itself. It helps people understand it, and accept it, even if they don’t agree with it. And it engenders trust.

I learned that I don’t miss designing and coding much since becoming a manager. The bits and pieces I get to do here and there, in and out of work, is usually enough.

I learned that just telling someone a lesson you’ve learned through experience is not likely to change their thoughts or behavior. Experience is the best teacher. This can be painful when you see someone making a mistake you could have prevented, but I’ve learned to accept this. (This is a good lesson to know if I ever have kids 👪 ).

Similarly, I learned that giving people information in an effort to increase their knowledge, or change their behavior, isn’t the most effective way of achieving this goal. It’s much more effective, albeit harder, to ask questions that lead a person to “earn” this knowledge themselves. By getting someone to come to their own conclusions, they’re more likely to internalize and act on that new knowledge. And they can apply the framework for gaining that knowledge to new situations. This is an art as much as it is a skill, and takes practice.

I learned that my top 5 strengths, according to the Clifton StrengthsFinder, are: 1. Learner; 2. Intellection; 3. Achiever; 4. Individualization; and 5. Analytical. Nothing too surprising, but cool to see nonetheless.

I learned that product development is hard, even when a person’s been doing it for a long time. Especially with teams, and as a company grows. I learned that as clueless as I might feel about how to run a team or build products, no one seems to have it completely figured out (even if they’re experienced and, from the outside, seem to know what they’re doing).

I learned that I like having physical books over eBooks. I display them on my shelves, which makes me much more likely to re-engage with a book after I’ve finished reading it. By seeing it, I’ll think about it more, and pick it up and flip through it. I don’t do this when a book is trapped in software. The same is generally true with music and movies, too.

I learned that underlining passages in books helps me focus on the core ideas being communicated, helps me stay engaged, helps me retain the information better, and makes it easy for me to flip through a book later and remember the key parts.

I learned that everything I spend time on has an opportunity cost. So I’m learning to get comfortable focusing on the things I most enjoy (such as writing), and accepting the cost of not doing other things (such as playing guitar).

I learned that with sustained effort over time I could be good at almost anything (art, music, programming, sports, etc.). But as my “opportunity cost” lesson indicates, I can’t be good at everything. I have to choose what to spend time on, and thus what to be good at. And with enough effort, perhaps I’ll even become great at something. 😄

Finally, I learned that I can’t possibly document everything I’ve learned in a year. There were too many lessons, big and small. Here’s looking forward to another year of learning in 2016!

Tags: Things I Learned
View all posts »