At DesignMap we pay careful consideration to all different levels of problems. An interesting and reoccurring problem I’ve come across lately is designing within a limited space while accommodating different types of restrictions. This particular example is around viewing and editing countries within a modal. The modal is triggered from a world map widget within a dashboard that provides an overview of selected countries. Here are some constraints, desires, and context around the problem:

Constraints

• Number of regions and countries are in flux so scalability is crucial (started with 77 countries with 7 regions; ended with 163 countries with 5 regions)
• Range in number of countries per region (One region has 2 countries while another has 45)
• Cannot alter how regions are broken up and which countries fall under a region
• Search is not in scope

Desires

• Scannability
• Digestibility
• Sensible modal size

Context

• For the general use case, the smart default is with all regions and countries selected
• Each modal option has a “Select/Deselect All” checkbox for cases when the user only wants to select a few countries in different regions (i.e. if the user wants to select just the US from the Americas and the UK from Europe, a Select/Deselect All option prevents a user from having to individually deselect 161 countries)
• Checkboxes left of each region provides quick regional select and deselection for the same reason, on a smaller scale
• To the right of each region is a count of selected and total countries in parentheses indicating the current state

Here are six different options with some pros and cons that were considered in designing around these restrictions:

1. Wrapping list

Pros

• All countries are visible at one glance
• No extra selection needed to view regional data

Cons

• Difficult to scan; category headers are mixed in with listed sub content
• No hierarchy
• Increases cognitive load

2. Horizontally Navigated Tabs

Pros

• Breaks up the regions into more digestible sections

Cons

• Limited horizontal space for tabs; five tabs can be seen here
• Countries are hidden due to regional separation into tabs
• Space is poorly used for the region with the fewest countries (Imagine two countries in a tab)
• Tabbed interface creates repeating sub headers (We now need to create another Africa sub-header for the regional Select/Deselection)

3. Vertically Navigated Tabs

Pros

• Flexibility of adding tabs is easier than horizontal tabs
• Easy vertical scanning of regions

Cons

• Space is not used well for the region with the fewest countries (again the tab with only two)
• Countries are hidden due to regional separation into tabs
• Won’t scale well horizontally if number of countries per region increases
• Tabbed interface creates repeating sub headers

4. Scrolling with containers

Pros

• Scales well
• Works well with small number of items (two countries within a region)

Cons

• Content below the fold may get lost unless users scroll all the way to the bottom.
• Regions are not scannable
• Countries or regions may be missed if scrolled quickly
• Cognitive load for scrolling and finding desired content (User has to move to the scroll bar, click, move and down)

5. Separated Columns

Pros

• Headers are horizontally scannable at the top
• Most of the countries are visible before scrolling
• No hidden regions or need to click into separate regions

Cons

• Countries towards the bottom of the alphabet are hidden
• Still need to scroll to view the rest of the countries
• Does not handle range in number of countries well (i.e. Region with two countries)
• Layout forces the content to feel too tight in this modal

6. Accordion Menu

Pros

• All regions visible at all times
• Regions are vertically scannable
• Auto-sizing accommodates a wide range of countries (Both 2 countries and 45 countries work well)
• Larger height of an accordion provides larger click area and affords a larger header

Con

• All countries not viewable at once

Although the accordion option does not allow the user to view all countries at once, all the pros outweigh the single con. This solution scales well, is scannable, easily digestible, and auto-sizes according to the content. The characteristic of elegantly compacting categories in a small space makes great use of an accordion menu for this example.

Even if it’s just contemplated in our head it’s valuable to explore variations of a design not only to derive at the best solution, but also to comprehend the rationale behind it. That way when we are presented with similar cases in the future we have a stronger intuition about the best approach.

Here are some links for additional information on accordion menus:
http://ui-patterns.com/patterns/AccordionMenu

http://www.welie.com/patterns/showPattern.php?patternID=accordion

http://developer.yahoo.com/ypatterns/navigation/accordion.html

All options are wireframed for discussion purposes.

Can you tell which is bigger, the blue square or the red square?

Let me guess: you picked red.

They are both the same size at 120 pixels x 120 pixels. One of the interesting characteristics of the color red is that red objects appear closer to the viewer. If you picked red, this explains why.

What other characteristics are there?
I tried tracing my memories of studying colors. Despite of the fact that I studied design for four years, the only other thing I can remember about red is that red evokes appetite. So, I ran a quick search of color characteristics and found a good resource: Psychological Properties Of Colours:

RED. Physical
Positive: Physical courage, strength, warmth, energy, basic survival, ‘fight or flight’, stimulation, masculinity, excitement.
Negative: Defiance, aggression, visual impact, strain, alarm.

BLUE. Intellectual
Positive: Intelligence, communication, trust, efficiency, serenity, duty, logic, coolness, reflection, calm.
Negative: Coldness, aloofness, lack of emotion, unfriendliness.

How is this useful?
While I was doing my search on color characteristics, I happened on this great infographic, The Colors of The Top 100 Web Brands. It is slightly outdated as it’s from September, 2010, but it presents a good color mapping of the most influential web brands. I have included that below:

Let’s take a look at blue and red brands specifically.

The first thing I noticed was there were many more blue brands than red. Perhaps blue’s intellectual quality is not a bad association to have for many companies. Plus, blue is the world’s favorite color– it doesn’t hurt to have the brands associated with the favorite color of the many. (57 % of men and 35% of women chose blue as their favorite color.) If you are interested in more details on color preferences by gender, here’s another fantastic infographic explaining that.

At a glance, I see a couple categorizations of blue brands;
• Social Media: Facebook, Twitter, LinkedIn, WordPress, and flickr (I know it’s blue and pink, but blue is dominant).
•  Financial: Citibank, Chase, Paypal, and Experian

I can pick out a couple of words, favorable associations to the category, from the blue list above.

Social media is all about communication and coolness. I would pick intelligence, trust and efficiency as good attributes for financial brands.

On the red side, I see some news/media brands: CNN, CNET, ESPN, and BBC (well, BBC’s logo is no longer red…) I find energy, stimulation and excitement are all good associations to these brands.

Color is only one aspect of the brand, yet it plays a big part in delivering appropriate message, or creating and/or conveying a suitable brand image. Color preference is subjective, yet colors have somewhat universal connotations. Having this knowledge in the back of your head might help you deliver a more appropriate message, and more agreeable results, to your next design project.

How is this applicable in UX design?

This iOS screen is a good example of two distinctively different types of buttons on a single page: the red “Delete Account” button and the on off light switch style buttons for Mail, Calendar, Notes and Archive Messages. You know the difference. The light switch button next to “Mail” will let you toggle the email on or off. The red “Delete Account” will, by contrast, delete the entire account The delete button has more visual impact on the screen, as it should– without an existing account, on/off buttons wouldn’t exist.

The significance of the delete button is clear because of the combination of size, style, color and location.

How much is color contributing to this? Is it contributing anything at all? To find, out I created a screen with a blue delete button instead of red.

This still clearly shows the significance of the delete button, yet it doesn’t appear as alarming as the red one. Considering the significance of deleting an account, “alarming” is an appropriate feeling to trigger. This is certainly color’s contribution in this case.

You cannot solve complex UX problems with color alone, but applying appropriate colors based on color psychology can make the experience more intuitive. Intuitive UX requires less thinking, and intuitive UX is always good UX.

I’ll close with a few more pieces of interesting color trivia:

Did you know?

• Facebook is blue because Mark Zuckerberg is red-green color blind. “Blue is the richest color for me. I can see all of blue,”  – via SFGate.
• A pink room can be good for calming down screaming kids, but not so much for your workout.
  • “Pink with a wavelength of 620 nanometers causes adolescents and children who have been screaming and yelling to calm down in 3 to 4 minutes.”
  • “Looking at this specific pink causes human muscles to weaken.”

If you are interested in this particular shade of that pink, you can find out more here.

A few years ago, I was working for a client who had the word “trust” in their tagline. This company had been around for a while, as had their tagline, so no one really thought about it outside of the annual “does our logo need to be updated” discussion.

But they wanted to do a major redesign of their site. Their initial requirements were pretty broad, so I began to dive into their product experience to narrow  them down. I also started the conversation about brand pillars, design guideposts, and manifestos. As a highly regarded brand that had been around for a while, there was plenty of big-picture brand surveys and analysis to do, but it was interesting to look at the mark itself (which had been around for almost 100 years), and the tagline, and ask ourselves what the words really meant. If working for Hugh Dubberly (a RISD-, Yale-, Apple-, and Netscape-alum that AIGA President David Brown called, “a professional shiner of light into the murk and ambiguity of life.”) taught me anything, it taught me not to take the basics for granted. Often a deep understanding of the basics can be precisely what guides us to a breakthrough user experience. So what exactly was trust, anyway? What did we mean by it, and did it have any implications for the user experience?

How

We’re big fans of creating concept maps to understand a topic that is new to us but that we need to understand well, or which we might know slightly but need to have a rigorous understanding of. It helps us to ensure a user experience that’s consistent with an accurate mental model of the space. Over the years, much of it under Hugh’s guidance, we’ve created concept maps for topics as diverse as heart attacks, TCP/IP packets, and Java. As Hugh says on his site:

“We create concept maps, a type of model,
to explore and learn about complex information spaces.
By showing everything—the forest and the trees—in a single view,
concept maps help people create mental models and clarify thoughts.
We create concept maps to share understanding—
with our clients, peers, and others interested in the subjects.”
http://www.dubberly.com/concept-maps

0. A Brief Definition

Concept maps came into use by educators after the publication of Joseph Novak and Bob Gowin’s book, Learning How to Learn. The basic idea is that you draw all the objects or concepts related to a particular idea, and then you draw and label all the connections between those concepts. Because of the non-linear nature of a concept map, it can much more succinctly describe a complex network of concepts and their relationships. The maps’ visual nature lend them to sharing and conversation, which often leads to deeper understanding (more concepts, and more connections).

1. In Which I Adjust My Approach

Armed with a healthy (read: naïve) dose of “How complicated can it be?” I planned to use my normal approach to concept mapping. Normally my process goes like this:

1. Collect all the concepts I can think of or find
2. Organize the nouns into buckets
3. Label the buckets
4. Organize the bucket labels into a sentence or two (if two, they must intersect—this becomes the “armature”)
5. Add the rest of the concepts with their relationships
6. Fill in the missing relationships and add concepts
7. Share, revise, repeat

So for example, to make a simple map of “martinis”, it might go this way:

1 - Collect Concepts 2 - Organize Into Buckets 3 - Label Buckets

4 - Create an Armature In this case, I really had two uber-buckets: cocktail and sophisticated. With a few experiments, I decided to try this perpendicular two-sentence armature, which allows for easier connections, which you’ll see later. Sometimes you have to try lots of variations of the armature to find something that works.

5 - Add Concepts 6 - Add Connections

You can see here that plenty of revision is called for—ice is missing entirely, as are the concepts of “wet” and “dry”, but you get the idea.

In the case of the “trust” concept map, I began my first search and found, to my horror, nearly 2 million articles on trust via Google Scholar. It was impossible to imagine collecting a meaningful set of concepts from so many articles.

A search for a model or definition of trust helpfully narrowed things down a bit. I decided to use an entirely different approach, and to essentially work from the inside out, looking for a good working definition of trust to use as my armature, and then I planned to build around that.

2. Find a Candidate for an Armature

As I read papers focused exclusively on the definition of trust, I came to realize that many of them hinge on an important article written in 1995 by Lewicki and Bunker. I’d read that article, but now decided to use it as my touchstone, and to use their definition as my armature. I reread it more carefully, following up more fastidiously on its references, finding criticisms of their definition and investigating papers the authors had written since. I revised their definition, now my armature, to support important objects and relationships. Simply finding my first set of articles, zeroing in on my “touchstone”, and following the strong leads from there took two weeks. As I read I mapped, starting off with lots of concepts but few connections. As I went on, I added fewer and fewer concepts (at some point I’d found most of them), but more and more connections because my understanding of the nuances of how the terms related became more developed.

3. Stop Mapping at Some Point

Eventually I’d followed my primary paths of inquiry full circle, running into references to papers and authors I already knew, and for the purposes of this exercise felt I had enough solid material to work with. To riff on da Vinci, research is never done, just abandoned. Because I’d worked “from the inside out” (from a good definition first), it was relatively simple to organize my concepts, add missing connections, and then remove everything that didn’t seem to be of primary importance. Because my audience for this map was internal, not academics, it was important to make sure I kept the final version of the map contained. I love geeking out on this stuff but not everyone has the same tolerance for it.

What

So what, if anything, was useful about this map?

Tiers

Broadly, I was interested to read, and finally decided to use, Lewicki and Bunker’s tiered classification for trust: Calculus-Based Trust sounds just like what it is: people make a calculation about whether there are penalties and rewards in place sufficient that they can trust another person. Starting there, people can move up to (or, depending on the circumstances, start at) Knowledge-Based Trust. The idea here is that you know something about, you have some experiences with, another person or entity. Finally, the ultimate trust is Identification-Based Trust, where we believe another person knows us well enough, and has our best interests at heart so much that our interests are aligned, and I can trust them entirely.

Calculus-, Knowledge- and Identification-Based Trust

Expectations

My definition of trust in the map is a modification of several others’, but nearly everyone’s definition includes the idea that trust involves an expectation. For this map, I specifically called out the generally agreed-to-be-critical expectations about goals, competence and integrity that are guided by experience, reputation, and of particular interest to this audience, brand. (See Hugh Dubberly’s Brand Map if you really want to blow your mind.)

…and So What?

It is important somewhere in here to make the point that not all models are gems of insight or even useful. Designers and their bosses, clients and colleagues need to allow for a little bit of “follow your nose” time, for a few models that don’t go anywhere, and for time with those that seem to show hope.

It’s also worth answering the question that comes up occasionally: How do we know this is right? Because it’s clearly subjective — I used good sources, but I also chose the definition to use, I chose what to leave out, and personally acted as both author and editor. But I maintain that subjectivity is not a reflection of accuracy. There are seven different ways to organize the coins in your pocket. The fact that you organize yours by amount and I do it by size doesn’t mean that either of us is wrong. If the map leads us to some new understanding, or even fosters conversation, then it’s done its job.

Having said that, the trust model surfaced some ideas that are worth considering.

For example, I’ve always been baffled about why people look for “the little lock” when conducting usability studies of ecommerce sites. Sure, secure http is important, but many of them think https when they see the icon. They don’t know what it is or whether it’s actually in play. And even if it is, there are nefarious employees, hackers, etc. But these people had some good experiences with a recognized and repeatable construct, and had developed some knowledge-based trust of it. (It’s worth noting that trust only exists in a situation of perceived risk – if users know everything about how a site works, who is running it, and everything in between, there’s no point in or need for trust. The flip side is that the very fact that usability participants don’t understand what https is or how to know when it’s actually being employed creates a risk state that requires trust.)

It’s also suddenly crystal clear that for even the most basic level of trust, Calculus-based trust, as site owners we must provide some essentials to users, things like: How does our company make money? What happens if something goes wrong? Why is our company helping them in the first place? AirBnB’s recent near(?)-miss with a user, not making the penalties to AirBnB of something going awry crystal-clear and then supporting them with consistent, repeated actions to develop a reasonable expectation and then a reputation completely erodes the basis for trust. All the elements are there: Where is the clear statement about rewards and penalties? What experiences are people having with the service? What kind of reputation are they developing? (Alas, good concept maps have the unfortunate side-effect of seeming obvious after people read them.)

Similarly, being explicit about goals (We make money the old-fashioned way—we earn it.), competence (50 million served!) and integrity can support an expectation of trustworthiness, sometimes long beyond the time that actual experiences belie that expectation (Don’t be evil!).

Goals, Competence, and Integrity

There are certainly many more examples of how this trust map specifically can have implications for user experiences; we’ve just pointed out a few of them. Happily, with topics like trust, we can continue to learn and leverage what we learn across projects and over years.

References
Bainbridge 1997 – Who Wins the National Trust?, Marketing, October 23th, 21-23.
Barney and Hansen, 1994 – Trustworthiness as a Source of Competitive Advantage, Strategic Management Journal, 15, 175-190.
Bhattacharya, Devinny and Pillutla, 1998 – A Formal Model of Trust based on Outcomes, The Academy of Management Review, 23 (3), 459-472.
Bhattacherjee, 2002 – Individual Trust in Online Firms: Scale Development and Initial Test, Journal of Management Information Systems, Volume 19 Issue 1, Number 1/Summer 2002
Fournier, 1998 – Toward the Development of Relationship Theory at the Level of the Product and Brand, in Advances in Consumer Research, Vol. 23, ed. Kim P. Corfman and John G. Lynch, Jr., Provo, UT: Association for Consumer Research, 661-662.
Delgado-Ballester, 2003 – Development and Validation of a Brand Trust Scale, Revista: International Journal of Market Research
Dubberly, 2005 – Models of Models
Gefen, 2000 – E-commerce: the role of familiarity and trust, Omega, The International Journal of Management Science, 28 (2000) 725-737
Glaeser, Laibson, Scheinkman, and Soutter, 2000 – Measuring Trust, Quarterly Journal of Economics 115(3): 811-846.
S. L. Jarvenpaa, M. Tractinsky, and M. Vitale, “Consumer trust in an Internet store,” Information Technology and Management Special Issue on Electronic Commerce, vol. 1, no. 1–2, pp. 45–71, 2000
Jones, 2005
Lewicki and Bunker, 1995 – Trust in Relationships: A Model of Trust Development and Decline, in Conflict, Cooperation and Justice, ed. B. Bunker and J. Rubin, San Francisco: Jossey-Bass, 133-173.
Lewicki, R.J., & B.B. Bunker. (1996) “Developing and Maintaining Trust in Work Relationships.” In Trust in Organizations: Frontiers of Theory and Research, eds. R.M. Kramer & T.R. Tyler, 114–139. Thousand Oaks, CA: Sage Publications.
Mayer, Roger, David James, and F. David Schoorman (1995), An Integrative Model of Organizational Trust, Academy of Management Review, 20 (3), 709- 734.
McAllister, Lewicki and Chaturvedi, 2006 – Trust in Develop Relationships: From Theory to Measurement
Oakes, 1990 – The Sales Process and the Paradoxes of Trust
Oxford English Dictionary, 2005
Sheth, Jagdish N. and Atul Parvatiyar (1995), Relationship Marketing in Consumer Markets: Antecedents and Consequences, Journal of the Academy of Marketing Science, 23 (4), 225-271.

Here at DesignMap we go to lengths in determining the best controls for our clients. Often in the course of explaining our choices, we uncover important distinctions, that we feel adds to the growing field of UX. One of those instances came up recently regarding the use of a light switch vs a toggle. Here is how we see the differences.

Light Switch

Light Switch is a sliding button which displays its current state, clicking the button will switch states. A Light Switch should be used as a gate, in scenarios where simple binary functions are necessary. For example turning on a set of features or search criteria. In the diagram below the grey line represent information flow with the Light Switch acting as a gate: either the information flows or it is stopped.

Toggle

Toggle, a button which only allows for one item to be selected at a time, turn off unselected items as a selection is made. The Toggle should be used as a pivot where both items in the Toggle are options – for example, filtering a grid by one of the options in the Toggle. In the diagram below the information flow is diverted to either option of the Toggle.

Best Practices

Light Switches generally should have very short items names, “On” and “Off”, “Yes” and “No”, etc. Additionally, to the user, the name that is not selected should be able to be inferred from the selected name. For example, most people would know that if they see “Yes” the opposite would be “No”, even though they cannot see the word No in the Light Switch.

Toggles need to show all options to the user as the non-selected options cannot always be inferred by the selected option

Furthermore, Toggles could have more than two options, so showing all options at a glance is imperative.

Incorrect Usage

In the case of Toggle switches, “On” and “Off” do not work well. The reason behind this assertion is, that it requires users to read two labels in order to know the current state of the switch. Additionally there is no color difference between the two options, which would also help with the determining the state of the Toggle.

Both Light Switches and Toggles have places in modern web applications. Hopefully the above descriptions will help clarify which scenarios those controls are better suited.

What do you think? Do you use Light Switches in your interaction design? Let us know in the comments.

Super-excited to have the opportunity to contribute to UX Magazine.

Product opportunities come in many forms, and there’s just as many ways to define an opportunity and translate it into something tangible.
To create a great product, Product Managers, Developers, and Designers (among others) need to both understand the larger context, and develop an intimate knowledge of every detail.
Recently we’ve been using a pattern called ‘Story Mapping’ (coined by Jeff Patton) to help us do both. Originally developed to bridge the apparently irreconcilable practices of user centered design and agile development, the benefits of Story Mapping apply even when the organization is not using an Agile methodology.

The (my) case for story mapping

Story mapping gives us a tool to decide what’s in scope and what’s not.  Ideas are easy, and making a great product is as much about making tough calls on which features don’t make the cut as it is about interaction design. Story Mapping can help you balance what your user needs and what you can deliver on time.

This is a low cost, fast and transparent process. It’s great for exposing and managing complexity that otherwise may have only been found when the developer or designer are actually building the product.

The act of writing a ‘story’ requires us to empathize with our user. A product that anticipates the desires, fears and aspirations of a user will almost certainly exceed expectations.

Getting Started

The Story Mapping process needs inputs, something to frame the activity. We need to know where this story starts, where it goes, and where it ends.
These goals are usually found in business requirement documents. As the name implies though, story mapping, like a good story works best with actors and motives. In the user experience world we create Personas to consolidate user research into a set of archetypes representing the spectrum of your audience.
Before getting started we choose one of our Personas to be our headline actor. With our feet firmly in our persona’s shoes we start telling stories of how Jane (no longer just a ‘user’) would get this job done, and very importantly: why Jane does this.

We’ve been trying to keep this process simple, light weight and maybe even fun. This way the team can see the benefits of the process as they’re working on it.
Get started with lots of post-it notes, lots of wall space, and a cross discipline team. Keep your team small, I’d suggest 3 at most. People who’ve been involved in your research, listening to potential users, are your best bet for informed contributions.
Product managers, subject matter experts, client support staff and designers are also likely candidates for your team, and don’t hesitate to work with developers, even potential users themselves. You can always bring other people to your completed map later to review and test the stories.

Telling stories with your team

See Jane’s user experience

Epics

Begin with high level chunks, describe Jane’s work flow from end-to-end.  Use a post-it for each step.  Keep the steps broad enough that reading through the steps end to end will be about the length of a sentence. This is often called the ‘Epics’ level.
An over simplified example:

Reading through your 'Epics' should describe the tool in the length of a sentence.

Jane wants to read, manage and respond to incoming email and also create and send new emails.

Think of these as buckets of functionality to cover the user’s needs, and, of course, to address all your business requirements.
Keep reviewing and adjusting these as you build the map.

Activities

For each of those high level steps do the same again, but now with a bit more detail.
Note what the user’s goal is, what they want, and why.

“Jane wants to prioritize emails from multiple accounts to balance two jobs and feel in control.”

We call this level of story ‘activities’.

Jeff Patton describes Activities as groups of related tasks that can be achieved in one sitting.

Tasks

Think more granular as you write the next level of stories: what are the individual decisions or actions that Jane wants to make?
These ‘Tasks’ get us into the details of each Activity, and expose all the complexity of activities that previously we wrote off as simple, or not a big deal.

Position them horizontally in sequence so you can read from one to the next: Jane ‘browses’, [and then] ‘selects’ [and then] ‘marks email as high priority’.

Read 'or' between tasks down the column, 'and then' between columns.

Of corse in any workflow there maybe several options at any one point.  To accommodate this we stack stories vertically  – so we can read down a column of stories with ‘or’ in between: Jane ‘browses all emails’ [or] ‘searches by keyword’.

It’s important to give this step it’s due. Tasks are the building blocks of your map. The key benefits of story mapping are gained by validating the Activities and Epics above with cohesive, comprehensive and highly detailed tasks.
You may find the need to revise the Activities and Epics as you expose the details.

Feature Prioritization

Triage for user satisfaction

Take all those vertically stacked ‘or’ tasks and prioritize them. Reposition the tasks that are most crucial to Jane and move them to the top of each column. These are the tasks that are necessary for Jane to complete her goals. In my very simple example above, it’s critical to be able to select an email, selecting multiple emails is not.
The items at the top must allow the Jane to move horizontally through the stories and achieve the most important goals – this is your minimum viable product.

Scoping

This step makes Story Mapping ‘agile’ and time-line friendly

Your team can now slice through the map horizontally to select which tasks will be addressed per release. Here you can evaluate effort estimates, demand or necessity of a feature and of course your time line. If your organization is using agile you can fill your backlog and sprints in this step.

'Search can wait, but we're able to do multiple select now...'

So…

I think this is a great tool to shine a light into all the corners of your product. A wall covered with post-it notes makes product plans tangible and physical, everyone can see literally how big it is.
Stand back to see the big picture, step forward to understand every little piece.

Be prepared for your map to get HUGE, and for folks to baulk at putting the effort into something made of post-it notes. If that happens, I’d point out the alternative: some individual has to sit down and type out a document that details every little bit of the product. Then many people have to sit down read, and respond to that document. Revise and repeat. Personally, I’d prefer to hash it all out in a team with pens and paper.

You can rally your team around the story map, where everyone can discuss, understand and contribute to the entire undertaking, and celebrate each milestone reached.

P.S. Obviously story mapping is best in-person, but reality means we work remotely sometimes. I’m still struggling to find a good online tool to do this process with remote teams. There’s a growing list of tools, from simple and literal post-it note apps like Listhings, through to agile project solutions like Silver Stories, and ScrumDesk, none of which I endorse due to either being under powered or overly complex.

Way back in 2009 we at DesignMap were working on a stealth project for a new web browser called RockMelt, now in public beta. Part of that project was the design of their logo, which went on and off over the span of two months. With other projects going on simultaneously and the amount of work that we put in for this project overall, the two months allotted for logo design ended up feeling like 2 weeks. We thought this would be a fairly simple project, but we hit plenty of brick walls, made some piles of crap, suffered moments of total despair, and eventually arrived at an “aha!” moment where everything came together. Come to think of it, I think I just described every design project I’ve ever worked on.

One note of caution: If you’re looking for a post about “how to execute the perfect logo design project,” this isn’t it. And, while I love when a project goes smoothly, I think we as designers grow the most when being presented with and overcoming challenges. And so, this post is about the challenging process of designing the RockMelt logo and the things we would do differently if we had it to do over again.

What’s that, a Rock-Melt you say?
It all began with a name that brought to mind a geological phenomenon and a fuzzy idea of a socially connected browser. I love the fuzzy zone — nothing but options — but I dread it for the same reason. Our attempt to clarify the “fuzz” began with an effort to find the relationship between the name and the product. We visualized its parts, the name’s combination of two elemental opposites, rock and melt (solid and liquid), and the product, a socially networked web browser.

This first step considered conceptual directions we might take. Do we go for a unique type treatment? Do we emphasize the letters R and M? Do we make an icon of a physical thing like a mountain, volcano, melting rock, cave structures or a molten sphere? Interestingly, nobody gravitated too heavily to the molten sphere that would eventually transform into the final logo. The three directions that were chosen are marked with green asterisks below: a mountain graphic that integrated the name (far left), the name sculpted from stone (top right) and an emphasis on the letters R and M.

figure 1.1

Next we explored the three chosen directions further. This was a very short round of explorations that happened in about a day. Almost immediately, the decision to dig deeper into one particular variation (with green asterisk below) was made. At the time we  at DesignMap and RockMelt felt like this variation had a lot of possibilities (and it did as you’ll see further in the post). Looking at it now, though, a literal mountain graphic feels like the user might receive a Clif bar and a ski pass with every download.

figure 1.2

A mountain of exploration

In the beginning there was a vast valley of possibilities, but we had arrived at our mountain. Well, lots of mountains as you’ll see below. We explored color, shapes, introduced a flame image (feel free to chuckle), added detail, stripped detail and on and on. This became cycle of illustrating variations only to find that they became almost completely unrecognizable — sometimes even resembling a pile of crap — at desktop icon size. Not exactly what we were going for.

In our first set we worked in black and white so we could focus on the interacting shapes of the graphic. Was the mountain organic and realistic or geometric and abstract? How could  we arrange the type in relation to the mountain? It was also at this point that we recognized the need to introduce the “melt” characteristic to the logo, so we tried various placements of drips. We introduced a flame to represent a source that causes the melt. This flame within the mountain was a direction that we pushed further on with, and at that point we believed it would in fact be the ultimate direction of the logo.

figure 1.3

When we introduced color, we started to consider the logo as a desktop icon. This was the most challenging point in the project. We were straddling a line. On one side was the conceptual area where we were still making variations of a mountain and flame, and on the other side we were roughly visualizing how the logo would interact with its environment — a person’s desktop and toolbar.

Since we were cranking out a lot of variations in a short amount of time we worked primarily in vectors with plans to move to pixels the favorite variations became clear. Since the PC version of the browser was going to be in blue tones we went away from grey and blues as the base shape (the mountain) in favor of warm oranges and reds. Also, the warm colors felt like a nice expression of the “melt” characteristic.

figure 1.4

As part of the quick variations, we created small and large versions side by side on a Windows-like blue background.

figure 1.5

We then placed our favored logo variations on a desktop and a Windows XP toolbar. We wanted to assess what a triangular, mountain shape looked like in these environments, especially side-by-side with other popular browser icons. This is where things got a little tricky. We felt that the flame and mountain became hard to recognize as such and, in my opinion, sort of resembled a Star Trek logo. I did like that our shape didn’t follow the trend of round logos for web browsers, but unfortunately it wasn’t working.

figure 1.6

However, we weren’t ready to give up on the mountain yet. In an effort to strengthen the mountain’s recognizability, we did some variations without the flame and made the mountain more organic and realistic. We settled on a common desktop icon size of 32 x 32 pixels and created a few Photoshop variations. This was the last of the mountain variations resulting in the infamous “piles of crap.”

figure 1.7

Back to the drawing board
Circling back to the initial sketches we took a small step away from the mountain and decided to see what we could come up with for a mountain with molten lava spewing from it, a.k.a. a volcano. We had three volcanic directions — a dimensional volcano in a sphere, a dimensional volcano on a plane and a flattened volcano on a circular disc. We thought the problem with legibility was that the organic shape was too unusual to recognize by itself on an unpredictable desktop background, and we hoped that by placing it on a recognizable geometric shape, we would grant the mountain legibility.

figure 1.8

At this point, instead of making many variations in Adobe Illustrator, we chose the volcano in a sphere. This time we rendered it almost immediately in Photoshop for two reasons: First, time was running out and the pressure to deliver was mounting. Second, this allowed us to quickly assess the problems with legibility that we were facing before.

figure 1.9

We tested a transparent sphere and a sphere with a solid background on a range of colored desktop backgrounds. However, it was still hard to read specifically as a volcano in a sphere and we had hit another brick wall.

figure 2.1

The big “Aha!”
At this point we were at our wits’ end. In addition to the scaling and recognizability issues there was another thing that was bugging us — our mountain and volcano directions were considering characteristics of the name, rock and melt, but the product as a social web browser was completely disregarded. The final solution wasn’t completely apparent even though the answer was staring us in the face back on the initial set of concept sketches. I don’t remember if we specifically revisited the initial concept sketches or if all of the work we had done up until that point somehow started to come together, but I do remember having a “eureka” moment as I imagined the logo one morning as I got ready for work. When I arrived at the office, I sat and roughly sketched up a new take on the “molten sphere” — this time combined with an iconic networked globe image — and shared it with the team. It was very well received and the marriage between rock, melt and a social web browser finally resonated! It scaled down perfectly, the colors worked beautifully and the RockMelt logo was born.

This is the condensed timeline of the RockMelt logo’s lineage. In top to bottom, left to right order are the first two concept sketches, the first Photoshop rendering and the final rendering done by Nate (Principal, DesignMap), which gave it an excellent realism and edge.

figure 2.2

In hindsight, things I would do differently:

Time permitting, I would push the three directions (figure 1.2) further and do a lot more variations. In the additional variations I would look for more ways to convey the idea of a social web browser.

Additionally, I think the variations (figure 1.2) were still heavily weighted as conceptual ideas. In other words, the drawings were thinking of the concept or essence of the eventual logo without taking into account the eventual size and environment of the logo.  That’s not to say that exploring concept at that point was a bad thing, but I think the project would have been more efficiently served if I had layered concept with considering the logo as a desktop icon.

During the mountain phase, we may have began too large (figure 1.4). If we had started small, 16×16 pixels or so, we would have been better able to work out what details form the illusion of a mountain at that size.

The volcano in a sphere (figure 1.9) and the flame in the mountain (figure 1.6) are both unique enough that they would likely require seeing them at a larger scale as a frame of reference to recognize them at a smaller scale. While it’s a good possibility that a user would see the larger version when downloading the browser we didn’t want to completely rely on that. (One could argue that the Firefox logo has a similar issue, but thats a subject for another blog post.)

In conclusion, if you plan on designing a logo that will be a desktop icon always think twice before settling on a mountain image. Also, no matter how simple a design project seems they always become a living, breathing thing that we as designers need to respond and adapt to. And, no matter how many times we as designers tackle projects of similarity they always tend to have unique qualities that challenge us in different ways.

I think we’ve mentioned here before that we’re huge fans of Marty Cagan. Sometimes, I have to confess that I squirm a little when he recommends that anyone and everyone, but particularly Product Managers, should go talk to customers at every opportunity. Of course, he’s right, but what gets me squirming is imagining a young, enthusiastic Product Manager who’s rightly excited by a particular idea talking to people and missing tons of great information by making a few easy-to-make mistakes during the interview.

This came up for me again when helping a friend run a “how to do research” boot camp. We decided to script a few interviews to show how things might go badly awry, or very well, in an interview. The most interesting interview, though, was the one we put together that was “subtly wrong”. I realized that by ignoring some basic rules of thumb, it was really easy to get totally different information.

Here’s one of the scripts:

C: Hi Participant Patty, I’m Carla. Thanks for agreeing to talk with us today.

P: Hi Carla.

C: Patty, I’d like you to start by telling me what kind of car you’re looking for. Tell me, step by step, what research you’ve done so far.

P: Well, I’ve looked at Toyotas, and that’s about it. That’s really my only option in my price range. I don’t like Hondas… (short pause)

C: Lets talk about the Toyotas you’re looking at. What web sites are you using?

P: Well, the Toyota web site. And Google.

C: Do you use the web daily?

P: Yes, daily.

C: And what do you do online besides car research?

P: News mostly. I read news. And email. Does that count?

C: Sure. Do you use Facebook?

P: No, I don’t really use Facebook. Although Farmville is fun.

C: So you do or don’t use Facebook?

P: I don’t.

C: Can you tell me why not?

P: I don’t know, it just… it’s… (struggling)

C: Time-consuming?

P: Yes, time-consuming.

…

If we were to write up some quick notes about this person, we’d say:

• Looking at Toyotas
• Doing research online using OEM sites and Google
• Uses web daily, not into Facebook

Now let’s look at a slightly different approach from the interviewer:

C: Hi Participant Patty, I’m Carla. Thanks for agreeing to talk with us today.

P: Hi Carla.

C: Patty, I’d like you to start by telling me what kind of car you’re looking for. Tell me, step by step, what research you’ve done so far.

P: Well, I’ve looked at Toyotas, and that’s about it. That’s really my only option in my price range. I don’t like Hondas… (short pause)

C: (silent)

P: I got in a car accident when I was in high school, and even though I know they’re technically safe, it was a really bad accident and I just don’t feel comfortable with them.

C: I’m sorry to hear that! You said you’ve looked at Toyotas. What do you mean by that? How are you looking at them?

P: I have been doing some test driving. That’s mostly it. And I travel for work so when I do that I always try to rent one of the models I’m thinking about. Also a little bit online: the Toyota web site. And Google.

C: I’d love to talk more about the test driving and rentals, but first let’s talk about the web sites. How often do you use the web?

P: Maybe three times a week.

C: And do you do anything online besides car research?

P: News mostly. I read news. And email. Does that count?

C: Sure it does. I wonder, do you use Facebook?

P: No, I don’t really use Facebook. Although Farmville is fun.

C: Farmville is fun?

P: Yeah. I don’t really count that as using Facebook. But I probably spend spend half an hour on it every time I log on. It’s the first thing I do. But I wish I did it less.

C: Why not?

P: I don’t know, it just… it’s… (struggling)

C: (silence)

P: I worry a little bit about Facebook, and the whole privacy thing, you know?

C: You’re worried about privacy on Facebook?

…

Quick notes, from an interview with the same person, would look more like this:

• Shows concerns about safety, privacy
• Doing test drives, renting cars, and research online with OEM sites and Google
• Uses web three times a week, uses Facebook every time she logs in

Laying aside the shortcomings of this kind of research, what I love about these scripts is what a different picture you get of the interview participant. The first interviewer didn’t do a terrible job by any means, but really got different information. If you accept the premise that these scripts are plausible (and I certainly have seen examples of these kinds of things many, many times), then there are two basic rules that we probably all already know, but are reinforced neatly here:

1. LISTEN. Just be quiet and listen.
2. Stay neutral (be aware of leading, even subtly).

We were thrilled to see our client RockMelt all over the news this week (NYTimes, ZDNet, TechCrunch). While we didn’t get a NYTimes mention as part of the Netscape Mafia, we’re pretty excited that the PayPal Mafia has someone to give them a run for their money, and since many of us hail from Netscape, to have some ties to those illustrious “Netscapees” mentioned in the article. (Though wouldn’t it be less-menancingly termed “Netscape Posse”?) We’re pretty psyched to see adjectives like impressive and intuitive in some of the things we’re reading about the design itself, too.

Big congratulations to the RockMelt team, and thanks for giving us a chance to pitch in on such an exciting product!

I’m a little late to the party on this topic.  When Apple was dealing with the iPhone 4 antenna issue, ‘Antennagate’ back in July it drew my attention to that ubiquitous little graphic tucked in the top left corner, and I started thinking that…

It’s Wrong

The graphic is wrong because it’s a bar chart.  Bar charts are used to display and compare the values of a discrete data set.  Using a bar chart is the wrong choice for two reasons.
First, bar charts have two axis, one for the discrete data set, and the other for the value of each of those data points.  Cell phone reception has only one axis: how much bandwidth do I have out of my phone’s total possible bandwidth?

Secondly, bar charts are for discrete data sets, where our cell phone reception is a continuum.
If this is correct, then wouldn’t something like this be more accurate?

I can see and understand my reception quality, but how do I communicate it?  What out of what?

Better: ‘I’ve got three out of 5 bars’

Better yet: More visually distinct, and I can still see my total of 5.  It’s best not to rely on color change to indicate an item’s different state, so use color and shape.

Our current cell phone reception bars get this right.

I’m convinced that the bar chart is wrong, but I’m sure these guys at Apple et al aren’t amateurs, so I try again.

Maybe if we look at the chart closer and break down the values

If I take the bar chart and make the following assumptions: the first bar has a value of one unit; the second equals two units and so on; that the totals are cumulative; and lastly that five bars equals 100%, I can then map that on to a continuum.

Looks like all bars are not created equal.  Which takes me on to:

Why it’s right

After a little searching and reading I learned that signal strength and signal performance are not the same thing.
To summarize what I found: the bars represent signal strength, not the ability for the signal to carry your call, your signal quality.  The usable portion of the signal is extremely variable and hard to calculate.

The performance, as in the quality of the reception, only drops significantly when there is a significant drop in signal strength.  Put another way, signal quality plateaus after a certain level of signal strength.
Visualized it may look like this:

If we map that to the bar chart again:

Here’s some progress.  Apparently it’s harder to diagnose issues at lower signal strengths.  So by lumping the largest area, the plateau, of the chart into the fifth bar the other four bars can show more detail.  The resolution, detail or ‘information density’ in the left of the chart is increased.

From CNET’s Marguerite Reardon:
Why doesn’t Apple just measure the bars in a linear fashion so that each bar represents an equal share of decibels?
Because the range is so big, it’s harder to diagnose problems at lower signal strengths. Signal strength measurement doesn’t need to be very granular at the top end of the scale because performance is only affected when it drops off considerably. But more granularity is needed in the lower part of the scale. Read more at CNET…

The challenge and why it’s still wrong.

To explore the technical aspect further uncovers more complication.
CNET…
AnandTech (these guys have a terrific set of articles on this issue, if you’re game.)
MetaFilter

As I mentioned above, the bars represent signal strength, not the ability for the signal to carry your call.  We wrongly assume the bars are telling us about the ability of the signal to carry our call.   You can be standing under a cell tower and have five bars, but very poor reception because the tower is overloaded with other users.
There’s more. The lack of an industry standard against which to measure reception quality undermines our ability as users to communicate about reception quality on different devices – your device’s 3 bars may not equal my 3 bars.

I feel the designers of the reception graphic have given a good answer a difficult problem.  Since signal strength is apparently the only reliable data available, and we know that at roughly x signal strength we’ll start having noticeable quality loss lets focus the chart there.

What has been lost though, is an understanding of why and how people (us) use this information.  It’s 10:30pm on a Wednesday, so I’m not about to start any user research, but I can think of how we talk about reception:

‘I’ve only got one bar’

‘I’ve got three bars, should be fine’

‘Five bars’.

‘No reception’

‘Bad reception’

‘Good reception’

‘Oh, that’s a dead zone’.

I hope that sounds familiar.  I notice two things there: no frame of reference, we assume it’s ‘…out of 5 bars’; and a near binary reference of off and on, or good reception and no reception, with bad reception in between.

So to conclude, and make a little contribution, could a simple traffic light style style indicator work?