Mills Baker wrote one of the best analyses I’ve seen on the the design of messaging apps in his comparison of Slingshot and Snapchat:

Snapchat seems eager to support naturalness in communication, which can be considered in terms of deformation. It wants to combat draining formalities, make it possible for all parties in an interaction to behave as they wish without anxiety, without fear of publicity or permanence, without the burden of modal moments. In other words: it wants the full range of technologies our smartphones enable to support honest, authentic, spontaneous interaction.

In contrast:

Slingshot makes demands of you for the sake of novelty, without having any organic justification for doing so, whereas Snapchat seeks to support your communicative intent without asking for justification, without even prioritizing things — like a social graph — that would be profitable for it to develop. Snapchat seems interested in helping you communicate; Slingshot seems interested in mandating engagement and experimenting with game-mechanics and arbitrary friction, in service not to your ends but to Facebook’s.

As I read this I kept thinking of Jared Spool’s view that design is the rendering of intent. Even though I don’t understand either of these apps because I’m old, it’s clear that Snapchat understands its intent and the design renders it effectively. Slingshot, on the other hand, appears to be a shot in the dark.

Two articles on the color yellow caught my eye this week.

The first is Object of Interest: The Yellow Card — Rob Walker’s history of the yellow card as it’s used in soccer. In a 1966 World Cup game a referee apparently failed to adequately communicate a penalty warning, which resulted in the birth of the card:

As objects go, it doesn’t look like much. It’s, you know, a yellow card. But when theatrically brandished by an official, almost literally in the face of a player who has done something uncool, it has wild power. It sets off a stadium-full of whistling, and cartoonish arm-flailing from the carded player and his colleagues. A yellow card has real consequences: Possession, a free kick, and the possibility that if the carded competitor blunders again he’ll leave his team understaffed for this match, and will sit out the next. […]

The cards are a such a brilliant solution to the problem of making sure a penalty has been adequately signaled — they transcend language; they’re clear not just to everyone on the field, but in the stadium, or watching on a screen — that it’s hard to imagine the game without them.

The second is Dan Saffer’s ode to a ubiquitous object in cities: The Hidden Genius and Influence of the Traffic Light.

The yellow light is by far the most sophisticated and cognitively challenging part of any traffic light. Red and green lights have had to consider timing, namely: how long should one side of the intersection remain green, the other red. This creates the “capacity” of a signal: how many vehicles can move through on a single change of the light. […]

The yellow light doesn’t really control capacity, but instead creates an ephemeral Zone of Decision around the intersection. When a light turns yellow, nearby drivers have a choice to make, quickly: do I speed up and drive through the yellow light, or do I slow down and stop? Driving instructors will of course always tell you that a yellow light means slow down and prepare to stop, but on the street, that’s not always how it works. Sometimes it really would be more dangerous to stop than to run the yellow. And sometimes those driving instructors are right: running the yellow is a terrible, dangerous idea. How do you know which is which?

So here we have two yellows, the one extremely clear (“I’ve made a huge mistake…”), the other an object of anxiety (“Should I stay or should I go?”). And yet we all know what the color means based on history and context and common understanding. I don’t know why that strikes me as fairly remarkable, but it does.

Also, apropos of nothing, does anyone else remember this?

Jessica Pressler wrote an article called “Let’s, Like, Demolish Laundry”, and it’s a wickedly funny (and, unfortunately, very accurate) look at the tech world’s obsession with solving First World problems:

We are living in a time of Great Change, and also a time of Not-So-Great Change. The tidal wave of innovation that has swept out from Silicon Valley, transforming the way we communicate, read, shop, and travel, has carried along with it an epic shit-ton of digital flotsam. Looking around at the newly minted billionaires behind the enjoyable but wholly unnecessary Facebook and WhatsApp, Uber and Nest, the brightest minds of a generation, the high test-scorers and mathematically inclined, have taken the knowledge acquired at our most august institutions and applied themselves to solving increasingly minor First World problems. The marketplace of ideas has become one long late-night infomercial. Want a blazer embedded with GPS technology? A Bluetooth-controlled necklace? A hair dryer big enough for your entire body? They can be yours! In the rush to disrupt everything we have ever known, not even the humble crostini has been spared.

Or as Mike Monteiro said, slightly more succinctly:

We used to design ways to get to the moon; now we design ways to never have to get out of bed. You have the power to change that.

Related post on Elezea: Legacy

The post I wrote this weekend on software development belief systems in corporate environments has been in my head for quite a while, I just hadn’t been able to write it up until yesterday. As often happens with these things, I noticed three articles in that past 24 hours that tie in really nicely with that post.

The first is Jeff Weiner’s Avoiding the Unintended Consequences of Casual Feedback, which talks about the kind of feedback executives should give to their teams:

Years ago, a former direct report of mine helped bring this point home. While he and his team welcomed my input, he observed that oftentimes what I thought was a take-it-or-leave-it remark would create a massively disruptive fire drill. Up until that moment, I had no idea my opinion was being weighted so heavily.

To address the issue and to ensure that the team and I were on the same page with regard to situations like that, we developed three categories to describe any feedback I provided (either in conversation or via email): One person’s opinion, strong suggestion, or mandate.

Next is Michael Lopp’s Chaotic Beautiful Snowflakes, which talks about the unintended work that managers often create without even knowing it:

The fact is that you significantly underestimate the amount of work that you generated this morning. You could document and communicate the obvious work, but you can’t document all the unexpected side effects of your actions. In a large population of people, it’s close to impossible for an individual to perceive and predict the first order consequences of their well-intentioned actions let alone the bizarre second order effects once those consequences get in the wild.

Finally, there’s John Maeda and Becky Bermont’s Building a Design Culture in an ‘End-Up’ Technology World, which talks about the elements of a good design culture in larger corporations:

In the end, building a great design culture is not the goal in and of itself. What it does is allow a company to recruit great designers, and then supports their ability to build great products, along with their counterparts in product and technology. Start-ups and end-ups may each think that they other has an easier time building or sustaining a design culture, but it takes work at any stage of the game.

All three articles are great companion pieces to what I wrote yesterday. I realized this morning that even though the traffic on yesterday’s post wasn’t huge, it will always be a personal favorite of mine, because it documents a lesson learned from a lot of sweat and frustration. And those are often the best lessons you can teach yourself.

You know that thing where you get home after a long day and catch yourself some time later staring off into space, pigging out on a bag of Doritos and…? Oh, uhh, no me either. But I heard that happens to some people.

Anyway. I’ve been thinking about that phrase you always see on consumer goods packaging when they go through a redesign. The almost-apologetic and slightly nervous proclamation that even though the thing now looks different, nothing else has changed:

Clearly marketers have learned that consumers don’t like redesigns, so they started using this message in a defensive attempt to soften the blow for people. Even then, it doesn’t always work. Remember when Tropicana reverted to their old packaging because some people called the redesign “ugly” and “stupid”? We should know this by now: people have opinions, and they are going to make a big noise about those opinions.

Yet whenever we go through a website redesign process we appear to develop some amnesia around this topic. We seem surprised when people spew vitriol all over Twitter, and we try to make ourselves feel better by saying that they’ll “get used to it.” Some part of me really wants us to create “Bold new look, same great functionality!” gifs for those kinds of projects, in the spirit of the “Under construction” gifs of yesteryear. But just like in the case of Tropicana, I don’t think that will work.

What’s the alternative? Well, first, we have to realize the biggest problem with big web/app redesigns. It might be the same functionality underneath (or not), but that functionality is often harder to find, and that frustrates users to no end. The good news is that we work on the web, not in packaging. We can do things incrementally! In the words of Cameron Moll, “Good designers redesign, great designers realign”. I’ve also written about this before in The Data-Pixel Approach To Improving User Experience:

The main problem with big redesigns, therefore, is that, even though objectively the UX might have been improved, users are often left confused about what has happened and are unable to find their way. In most cases, making “steady, relentless, incremental progress” on a website (to borrow a phrase of John Gruber) is much more desirable. With this approach, users are pulled gently into a better experience, as opposed to being thrown into the deep end and forced to sink or swim.

Look, I’m not saying this is a perfect analogy. But I spent a lot of time spacing out about this on Friday, so I thought I’d write it down for posterity. What I’m trying to say is, let’s worry less about bold new looks in web design, and instead work on making things taste better.

This is a written version of a talk I gave at Industry Web Conference on April 23rd, 2014. It’s a great conference and you should definitely attend next year.

This is a photo of what many believe is the first wireframe ever created. It’s attributed to Paolo di Dono (aka Paolo Uccello), dating somewhere in the mid 1400s (source):

Back then, wireframes were used to accomplish very specific goals to help with the design of everyday objects (source):

• To view the model from any desired point
• To produce standard and auxiliary views
• To create perspective views more easily
• To analyze distances within the structure
• To check tolerances and interference
• To decrease the number of prototypes required
• To edit the model

Wireframe models are particularly useful in the world of architecture, so it’s no surprise that software used to create CAD models incorporated wireframes as core to the product:

Image source

To clarify things a bit, wireframes were originally used to accomplish two product design goals: to reduce rework, and to speed up delivery. Those are words that will make any designer or developer’s ears perk up. Who doesn’t want that?

However, somewhere along the line we’ve watered down wireframes to something completely different. At worst they’re reverse-engineered artifacts based on completed PhotoShop files once an agency account manager remembers they’re supposed to “do UX” as part of the project they sold. At best they’re hailed as good communication tools — nothing more, nothing less. We’ve managed to reduce a highly useful design tool to something we fight over on Twitter. And it’s not just the humble wireframe that’s in the crosshairs. Personas. PSDs. Debrief presentations. They’re all looked on with the same disdain:

The reality is that there is a lot of truth to the criticism we lavish on “deliverables”. The Lean movement is right about the main reason for getting out of the deliverables business — whatever time we spend documenting stuff is time spent we’re not making stuff, and that’s a problem. It’s much better to create hypotheses, build them quickly, and test them with users to get feedback and iterate. I’m in complete agreement on that approach.

That said, there is a problem with this approach that has started to become more and more bothersome as I went on my own journey to stop making deliverables. The problem is that design is path-dependent. The choices we make early on in a design constrain the choices we can make later on. Ryan Singer sums this up really well in his answer on the Quora thread Should I focus on a good user experience, or push something out quickly?

On the very first iteration the design possibilities are wide open. The designer defines some screens and workflows and then the programmer builds those. On the next iteration, it’s not wide open anymore. The new design has to fit into the existing design, and the new code needs to fit into the existing code. Old code can be changed, but you don’t want to scrap everything. There is a pressure to keep moving with what is already there.

Our early design decisions are like bets whose outcome we will have to live with iteration after iteration. Since that’s the case, there is a strong incentive to be sure about our early bets. In other words, we want to reduce uncertainty on the first iterations.

So the main issue I kept running into as I stripped deliverables out of my design process is: how do I know where to start? How do I make sure I start in a place that isn’t going to limit me so much that I’ll have to start over completely at some point? And not just that, but what about that thing we all want to pretend doesn’t exist but we have to deal with every single day? You know, the S word. Stakeholders. Those people who need to know what’s going on and why, all the time. Without deliverables we’re kind of exposed to the elements on that, with nothing to lean on.

Something’s gotta give, and I think that something is the deliverables we make part of our design and development process. So I started thinking.

I started thinking about Jared Spool’s excellent piece from earlier this year, A Bias For Making, in which he wrote the following:

A bias for making doesn’t mean the team never plans. On the contrary, plans happen fluidly throughout the entire design process. The difference is they are evolving as the team learns from the process of making.

And then I started thinking about Giff Constable’s words in You Are Spending 3x-5x More Than You Should:

Agile/lean has helped people debunk the ‘big upfront design’ phase, but far too many replace it with nothing.

And as I kept thinking about all this stuff, I started to realize that there are some things that the right deliverables could actually be good at. For example:

• Deliverables could provide a better baseline to start a design from, particularly when it comes to device-agnostic design and development.
• Deliverables could help teams running along smoothly by anchoring everyone on the same vision, and serving as a communication tool to help executive teams understand the execution plan.
• Deliverables could help with building up organizational memory, so that when the inevitable leadership changes happen, everything doesn’t get scrapped to start over.

Of course, the next obvious question is, what are these right deliverables you speak of? If we’re all agreed that flat wireframes and millions of PSDs are against the spirit of Lean, what’s the alternative? How do we solve the problems that “no deliverables” present, and come up with something that helps us create better products (which is the end goal we all have in common)?

There are two kinds of deliverables that I’ve been working on as possible (work-in-progress) solutions to these issues, and in this post I’d like focus on one that clearly needs a better name: Expanded Customer Journey Maps.

Journey maps are visual representations that help summarize research, highlight and prioritize user needs and opportunities, and give teams a common goal to work towards (see Adaptive Path’s excellent introduction at The Anatomy of an Experience Map). A product’s journey map is important because:

• It confirms a common understand of the users’ needs and goals, and the strategy you intend to follow to attend to those needs and goals.
• It is an excellent prioritization tool, since it allows companies to focus on the most important parts of an experience first, without losing sight of the overall picture.
• It is a guiding light for design. Every time a design idea comes along, a quick glance at the journey map helps us figure out if it’s a good idea that will accomplish the chosen strategy.
• It is an excellent conduit for content-first design, which fits in perfectly with responsive design approaches.

There are many different ways to create a customer journey map. It has some common elements, such as a visual representation of customer touchpoints, emotions, and key takeaways throughout their experience with a product. But that’s only useful up to a point, so we’ve started to expand on the concept. In addition to the usual elements, this document also becomes a representation of the information architecture and the product’s content plan, with personas (needs, goals, scenarios) serving as the starting point for everything — the glue that ties it all together.

This new document is a summary of everything we need to know to design the best possible product for users. It has the following elements:

• Unique selling points to keep us focused on what the site needs to communicate at all times. This comes straight from the persona needs and goals.
• Journey stages and model to remind us how the product fits into people’s lives, and what the primary calls to action need to be throughout the site. This section is a visual representation of a customer’s journey from realizing they might have a need for the product, until long after they’ve used it. This helps product managers keep a holistic view of the entire product and how it fits into users’ daily lives.
• Questions that our target personas are likely to ask in each phase of the journey, to focus the type of content we serve on each page. In an e-commerce context, these are questions like, “Can I trust this retailer?” or “When will my stuff arrive?”
• Takeaways and key principles to summarize the unique selling points, journey model, and user questions, and document how they translate into the design decisions and solutions we need to keep in mind throughout the design process.
• Content plan that maps each phase of the journey with the questions our personas will ask during that phase, and what it means for the specific content that needs to go on each page. We get very specific here — nothing gets on the page unless it’s in the content plan. And if we can’t identify a persona that would find the content useful, it doesn’t go on the list.

Below is an example of an expanded journey map. You can click through to see a larger slice of one of the sections.

There are a few things that we found this kind of expanded customer journey map does really well:

• It is completely device-agnostic. It starts with personas and content, and the entire design remains anchored on that.
• Once you get going, design cycles happen faster, because everyone is aligned on the vision and direction.
• During user testing we tend to find fewer usability issues because we already thought through the most common problems that might occur.
• As a team we tend to have better arguments — meaning we don’t fight about whether the button should be blue or yellow, but whether the design accomplished the goals we agreed on.

It’s not a perfect solution, of course. Everything has drawbacks. In the case of expanded journeys, we’ve found the following challenges that we still need to work through:

• There’s no denying it, the initial lead time before design starts is longer. That’s just the way it is, because thinking about a problem takes time. Once the design phase starts we actually make up that time in spades, as mentioned above, but it can still be an awkward time with clients and internal stakeholders if they can’t see “pictures” as quickly as they might want.
• It’s easy to get distracted if you’re a UX nerd. This stuff is so exciting for some people (ok, me) that it’s possible to stand in front of that white board for days if you don’t check yourself. This isn’t about making a nice piece of paper, it’s about making a better product. Give it your best shot, and then move on. Don’t get lost in analysis paralysis.

So where does this leave us? Yes, deliverables can slow us down and result in documentation that no one reads. But the right deliverables anchor teams in a united product vision, they provide early validation for product ideas, and they speed up (the right) making activities. That’s worth the drawbacks for me. Remember, deliverables aren’t bad. Bad deliverables are bad…

This is still a work in progress. I’d love to hear others’ thoughts on this methodology, and if they’ve expanded it in other directions. If you have thoughts or ideas please let me know on Twitter, or write a post and send it to me. I’ll link to it here.

I’m a big fan of sketching, and this post by Jacob Rader does a great job of explaining why it’s such an important part of the design process:

Sensemaking is the active conversation we have with the events that we encounter; it’s our ability to take in information, process it, and derive meaning and action from it.

Rather than focusing on the external, sketching provides us a sensemaking process for our own creative flux. When we’re presented with a problem our minds go to work to create this cloud of ideas, populating it with information and attempting to form connections. This facilitated sensemaking turns that abstract concoction into a concrete reality. This works because sketching forces us to make decisions and apply structure to our ideas. By externalizing we pass those fragments through a filter of our own experience creating a foundation to build our ideas from.

When we externalize the pieces of an idea through a sketch we’re making a testable “design move” which we’re able make judgements around. This positions us to make further moves that iteratively cycles and builds an idea.

This navigation article by Gerry McGovern is from 2006, but it’s still so spot on. I’ll quote this one bit from Web Navigation is About Moving Forward, but you should definitely read the whole thing:

Navigation should primarily be about helping us keep on going in the direction we have chosen. If I choose a link for “notebooks” then I have made a decision. Continuing to present me with links for servers and desktops decreases my ability to focus on the notebook direction I have chosen.

When I choose a link for “ultralight notebooks” that indicates that I am not interested in multimedia notebooks. Once I arrive at the ultralight notebooks webpage, the overwhelming focus of the navigation must be to help me find the right ultralight notebook.

Good web navigation design is not about giving people lots and lots of choices. It is not about second guessing decisions we have made. It’s not about asking what if we want to get back to where we were. It’s about looking forward, not about looking backward.

This is unfortunately still such a common practice on e-commerce sites. Why continue to show users unrelated product ads once they’ve made a decision on what they want? Here’s the search results page on Kalahari.com when I do a search for “Samsung TV”:

This isn’t the time to punt apps, newsletters, and the marketplace. I’ve indicated that I want a Samsung TV, so sell me a Samsung TV!

One of my favorite articles of the year so far is Zachary Crockett’s The Invention of the AeroPress:

The AeroPress was conceived at Alan Adler’s dinner table. The company was having a team meal, when the wife of Aerobie’s sales manager posed a question: “What do you guys do when you just want one cup of coffee?”

A long-time coffee enthusiast and self-proclaimed “one cup kinda guy,” Adler had wondered this many times himself. He’d grown increasingly frustrated with his coffee maker, which yielded 6-8 cups per brew. In typical Adler fashion, he didn’t let the problem bother him long: he set out to invent a better way to brew single cup of coffee.

It might sound like an article about coffee, but it’s more about entrepreneurship, product design, and the sheer tenacity of true inventors. Great read.

I really enjoyed Nick Stockton’s exploration of the space syntax concept in architecture in There’s a Science to Foot Traffic, and It Can Help Us Design Better Cities. He explains:

Space syntax [is] the science of how cities work. In the late 1970s, British architects Bill Hillier and Julienne Hanson hit on the idea that any space within a city — or the entire city itself — could be analyzed in terms of connectivity and movement. They reasoned that a city’s success depended largely on how easy it was for people to move about on foot.

This wasn’t a huge revelation. Studies reaching as far back as 1960s have shown walkable cities have higher property values, healthier residents, and lower crime. What set Hillier and Hanson’s ideas apart was the notion that a city’s geometry did more for movement than any other design factor. They argued that every other cog in a city’s engineering depends on the walkable grid. Cars, buses, trains, and bikes play a role, too, but only as much as they transport people to places where they then proceed to walk around.

There’s some great examples in the article, including a case study on the redesign of Trafalgar Square in London.