RSS Twitter Facebook Search Subscribe

Imaginary UX Definitions

2012 August 21
by Amy
Joining the DesignMap team as the studio’s first office manager, I entered a new world of complex systems, precise visual aesthetics, and almost incomprehensible lingo. Coming from a theater background (another field that has its own jargon with acronyms for everything), I figured I would get the hang of it and soon these new terms would become part of my everyday vocabulary. But in the meantime, I’m having fun making up imaginary definitions for UX lingo and then looking up what it really means. (First day freebie: UX stands for User eXperience.)

INTERACTION DESIGNER

Let’s start with my effort to figure out what exactly everyone is doing in the studio here at DesignMap. Interaction design. What does that mean? This required just a quick trip to DesignMap’s website to find out that “Interaction design is about determining how an application acts. How many screens are there? What do they do? How do they interact with the user and with one another?”  So that’s what Interaction Designers think about all day long. Contrast this with the misnomer “Interactive Designer.” Pretty much all designers are interactive; they carry on conversations, respond to email, ride the bus, use the Internet, pick up the phone… Specifying that a designer is “interactive” implies that other designers went and got themselves cryogenically frozen so that they can be around for the launch of the iPhone 400.

INFORMATION ARCHITECTURE

“Information Architecture” has nothing to do with how earthquake safe your local library is, or the cool stuff you can build out of books (like this guy’s desk).

Information Architecture is the art and science of organizing and labeling websites and software to support usability, bringing together principles of design and architecture to the digital landscape. Typically it involves a model or concept of information that is used and applied to activities that require explicit details of complex information systems. According to Richard Saul Wurman, who coined the term (as well as founded the TED conference), IA refers to “the creating of systemic, structural, and orderly principles to make something work--the thoughtful making of either artifact, or idea, or policy that informs because it is clear.”

WIREFRAMES

[caption id="attachment_401" align="aligncenter" width="600" caption="“Wireframes?” I had a pair of those in high school…"][/caption] Nope, wireframes are not eyeglasses. They are a tool for designers to identify structural and functional elements of a website, as opposed to graphic elements. They’re sometimes quick conceptual sketches of a navigation menu and major buttons, and sometimes very detailed blueprints of websites ready to be built.

NAPOLEON’S MARCH

When I heard “Napoleon’s March” in the studio, I first thought of Eddie Izzard running across the stage (5:07) shouting “I have a better idea!” and then retreating immediately with “Oh, it’s the same idea!” I imagined that “Napoleon’s March” might be a complex historical metaphor for a project that has been attempted before, disastrously, (Napoleon, 1812) and then reattempted with new fervor and hubris but the same result (Hitler, 1941), because the underlying challenges are still present and insurmountable. As much as I like this definition, that’s not what designers are talking about when they mention Napoleon’s March. Cartographer and civil engineer Charles Joseph Minard created a chart of Napoleon’s attempted attack on Moscow in the War of 1812. The infographic combines the geographical map of the offensive and retreat with a visual representation of the number of men remaining in the French Army. It has been called “probably the best statistical graphic ever drawn.” This representation was groundbreaking in its time, and the design community is still pretty excited about its ingenuity and clarity. [caption id="attachment_404" align="aligncenter" width="600" caption="Click on the image to see the map in more detail."][/caption]

LOUPE EFFECT

[caption id="attachment_405" align="alignnone" width="225" caption="I was pronouncing this “loopy” effect, and imagining our studio full of over-caffeinated designers."][/caption] The term “loupe” (really pronounced “loop”) is not a new invention for the digital age. Jewelers, watchmakers, photographers, opticians, dentists, and stamp collectors have been using them for centuries. A loupe is a magnifying lens – different than Sherlock Holmes’ magnifying glass because a loupe does not have a handle. Some loupes use multiple lenses and mirrors.

[caption id="attachment_407" align="aligncenter" width="600" caption="In the digital world, a “loupe effect” enlarges a section of the screen so that you can see the finer details of a new product or make tiny edits to the email you’re typing out on your phone."][/caption]

PACE LAYERING

Part of what’s so disorienting about some of these terms is that they are English words that have always been in my vocabulary, but the interaction design field has put them together in a way that means nothing to me at first. “Pace” is easy: speed, rate, how fast something goes. “Layer” is simple enough, in the context of hair, clothes, dust, cake… Okay, time to Google it – and it turns out this is actually a two-part definition, so buckle up. Part 1: Architect Frank Duffy originated the concept of Shearing Layers to describe buildings as a composition of several layers of change. From the “eternal” site or geographical setting on which a structure is built, to the skin, services, and space plan, to the uber-mobile stuff like furniture and hairbrushes, these architectural layers each have a distinct lifespan and rate of change. Using the building architecture analogy, it’s clear that the more basic the level of architecture, the more difficult it is to make changes to that level because of the interconnections between that level and others. For example, to rebuild the foundation of your home, you might need to tear down the entire house and start again. Projects on other levels are easier – rewiring the kitchen, for example, or replacing the roof. Easiest of all is moving the furniture. Part 2: Steward Brand elaborated on this concept with the idea of Pace Layering in Information Architecture, presented at the IA Summit in 2003.

In user interaction design, it’s useful to think about the different rates of change for different elements of an application or system. For example, you might have one computer for 5 years, but upgrade the operating system every 2 years, buy new software applications a couple of times a year, install updates to various applications monthly, and create new files daily. Product developers straddle the gap between innovation and stability, balancing consumer demands for new features with the potential for disorienting or even alienating customers by bombarding the market with a constant stream of updates. Here at DesignMap, we use concept maps to root our work in those deeper layers. While logos, colors and even the interaction itself may change over time, the constancy of the underlying concept helps us to make sure the fast-moving outer layers reflect that deeper truth. For more on pace layering, check out usability.com’s article “The Evolving Web.”

SKEUOMORPH

I have to admit, I had no charming misconception of what this word might mean. When I first encountered it, I copied it right into Wikipedia’s search bar. A Skeuomorph is a defined as a “derivative object that retains ornamental design cues to a structure that was necessary in the original.” The word comes from the Greek for “tool” and “shape.” For example, your digital camera is programmed to make a sound like a shutter click, even though the noise is made with a recorded audio file and not a physical shutter. And have you ever seen a chandelier with flame-shaped light bulbs? Another skeuomorph.

In user interaction design, skeuomorphs can be used to equate functions of a digital interface of a product with the functions of that product’s physical-world counterpart that users may be familiar with. For example, your email program probably has a “compose message” button marked with a pencil and sheet of paper, even though neither of those tools are used in writing an email. In image editing programs, many tools are shaped like the brushes a painter would be familiar with.

I was surprised to discover that skeuomorphs are a hotly contested topic in design. Some argue that they help new users to feel more comfortable with the digital version of a real-world product, while others denounce skeuomorphs as “kitchy.” Apple’s iCal design is a subject of much debate, because of its faux leather stitching and torn-off pages at the top like a classic deskpad calendar, in contrast to the sleek minimalist aesthetic that informs most of Apple’s other products.

THE LONG TAIL

I must be finally getting the hang of this UX lingo, because the term “the long tail” did conjure an image similar to the one below. Then again, the lucky connection could have something to do with the great number of times I’ve heard my dad quote Monty Python’s “Theory of the Brontosaurus” sketch. Chris Anderson popularized the term “The Long Tail” in his book of the same name, subtitled “why the future of business is selling less of more.” Businesses like Amazon.com incorporate this principle into their strategy of selling a wide variety of items, rather than a large number of very popular items. In the classic Zipf demand distribution, the area of the curve under the long tail is equal or greater than the area of the curve to the left of the head. That is, the volume of sales/revenue potential of many hard-to-find items is at least as great as the volume of sales of in-demand items.

For this same reason, Information Architect Lou Rosenfeld argues that interaction designers should steer clear of this almost-infinite tail of data, and instead focus on the most frequent search terms to discover what the majority of users are looking for. Rosenfeld asserts that this focus will make the biggest difference to the overall usability of a website or application, rather than “chasing the long tail” of infrequent search terms in an attempt to design for all possible user objectives.

FTUX

[caption id="attachment_412" align="aligncenter" width="600" caption="Maybe a teenager would think “FTUX” as he creates a duct-tape prom outfit in his parents’ garage."][/caption] Turns out, FTUX stands for First Time User eXperience. (Sometimes it’s abbreviated to FTUE, which is almost as much fun to say.) User experience designers are concerned not only with how the product works once a user is all set up, familiarized, and ready to go, but also with what it’s like to get started using a new operating system, new software, a new smart phone, etc. Have you ever heard someone say “It’s great, once you get the hang of it?” That “get the hang of it” is the First Time User eXperience.

So that’s my FTUX with these new terms and concepts. Please leave a comment below with any other lingo I can look up… I think I am starting to get the hang of it!

eyeo festival 2012 recap

2012 July 27
by Chuck
In June I was fortunate enough to attend the quickly sold out eyeo festival. This was the second year of the event, and given the apparent success of the first I was excited to attend. It's held in Minneapolis and this year the main venue was the Walker Art Center, but other evening events were held at different venues each night. Minneapolis seems like a great town, and the Walker was a good choice of venue for the main events during the day. As others who have written about the conference have mentioned, it is difficult to pin such a broad event down to a single blog post. I can't help but think back to the conferences years ago that revolved around the Flash design and development community and how they were attempting to speak to many audiences at once. eyeo is certainly more focused toward a design slant but features enough for anyone interested in the area no matter their title. Here, I think there is a sense of a burgeoning scene around designers and data visualization coming together that allows for a broad spectrum of practice and theory to mix comfortably. The increasing quantity and complexity of information generated means methods of helping people consume the data will continue to evolve. As Drew Breunig shares in his "Frontiers through the Ages" list, Data is the next frontier.

Speakers

I wanted to talk about a few speakers in this post. Over time, the organizers are adding talks to their vimeo channel so you will likely be able to see more than I discuss here. However, the talks below resonated with me because of how we work at DesignMap and their relationships to the type of deliverables we create and how we create them.

Amanda Cox

Amanda Cox is a Graphics Editor for The New York Times, has spoken several times at various conferences and won many awards for her work in data visualization. Amanda shared an historical view at her department beginnings along with a truly massive selection of graphics the team has created over the past 20 years. What she showed was a hefty sample of the 100,000 graphics created in the department organized in a huge scrolling page. What was interesting was to see and hear about the influences each graphic has had on later, similar problems the team has tried to solve. To see previous work recombined in more effective ways, cross-pollinating, was only possible by looking at all of the work. Certain graphics couldn't happen without previous graphics.

A few snippets of her talk:

Can we tell you something more by throwing something away?
Bar charts don't respect what's unique about the data. It's the lowest level of conversation. Not exposing the underlying content in a new more useful way.
The best kind of journalism is not mad-lib journalism. Same thing goes for graphics. You can make fine graphics, but you'll never make great graphics.

Stefanie Posavec

Stefanie is known for her visual analysis of the novel On The Road by Jack Kerouac and this project is what she shared at the conference. She spent 3 weeks documenting the novel in various ways, the end result was 4 poster that visually represent aspects of the novel. By visualizing the book in this way, Stefanie is able to call out the key themes of the novel and when they appear in the narrative. What resonated most for me was the fact that her work of analysis was done by hand, something that we value here at DesignMap highly. By putting her nose in the source material so thoroughly, she left with an intimate understanding of that material and was able to craft something that would undoubtedly have moved the author with her insights. [caption id="attachment_681" align="alignnone" width="600" caption="Details from Stefanie Posavec's poster series dissecting Jack Kerouac's On The Road."]
[/caption] [caption id="attachment_686" align="alignnone" width="600" caption="Stefanie manually collected the data used for her poster series by marking up a copy of the novel."][/caption]

Nicholas Felton

[caption id="attachment_688" align="alignnone" width="600" caption="Interior page from Felton's 2010/2011 Biannual Report"][/caption] [caption id="attachment_689" align="alignnone" width="600" caption="Covers for some of Felton's Annual Reports"][/caption] I wasn't sure how much I'd take away from Nicholas' talk. Seeing as how his Annual Report work is something I own copies of and read through several times, I expected it might not be as eye-opening as other sessions. But it was interesting to hear him discuss his process for design in more detail. How he deals with the same blank-page anxiety we all do and especially how he starts working with something, anything, to keep moving in a direction until he knows the right direction. I did however leave the talk wanting to understand a bit more about the relationship between the data he records and how it influences his end result. On his blog, he describes the purpose of the 2010/2011 report with a Philip K. Dick quote:
“a person’s authentic nature is a series of shifting, variegated planes that establish themselves as he relates to different people; it is created by and appears within the framework of his interpersonal relationships.” The Feltron 2010/2011 Biennial Report explores this notion by overlapping facets of Nicholas’ behavior to visualize how his personality varies based on location and company.
He discussed many of the steps to ending up with the finished piece, but one detail that I enjoyed was his use of triangles to form what are essentially bar charts in the 2010/2011 Biennial Report. A detail like this exposes underlying thinking which isn't always obvious by viewing the end result. [caption id="attachment_695" align="alignnone" width="600" caption="Felton explored a more effective way to display data sets with extreme upper and lower limits. A triangle-shaped "bar" allows the viewer insight into the relative height when it falls off of the printed page."][/caption] [caption id="attachment_692" align="alignnone" width="600" caption="Felton chose 2 colors for the main themes of the report. 2010 was represented by cyan while 2011 was magenta."][/caption]

Natalie Miebach

Natalie's work is probably the hardest to qualify as having specific parallels or direct use for inspiration in our day-to-day work here at DesignMap. However, I found the work very interesting because it was taking data visualization in a different direction. Manifesting data in 3 dimensions or the form of music scores (including performances of the scores) were moving away from a reliance on written language to communicate these complex patterns of data. She focuses on translating data into a tactile experience in the form of woven sculptures and musical scores. By using 3 dimensions in her woven sculptures, she's able to relay the relationships between data in a way that's difficult to do in printed form, or even in interactive ways. [caption id="attachment_668" align="alignnone" width="600" caption="Visualization of "The Perfect Storm" using wind data to create a sculpture made from reed and wood."][/caption] It felt as though, given enough time, and enough samples with like data sets and scales, that one could learn this new language. Some of these sculptures reminded me of an exhibit I saw in Peru years ago. The exhibit contained several examples of quipu, recording devices made from knotted strings meant to track numeric values such as crop yields and other bookkeeping needs for the Andean people of South America. These quipu translate data into a tactile form in the same way Natalie does in her sculptures. Of course, the data density of the quipu is much smaller, but the notion is the same. To me, this example means the work Natalie does isn't as far out as it might seem at first glance.

Would attend again

To wrap up, there were so many interesting talks about a big variety of data and visualization techniques that I didn't cover here, so definitely check out the videos. I hope to attend again next year and would recommend it for others interested in the field.

The Functional Prototype vs. The Clickable Mock-Up

2012 June 26
by Matt Leigh
Here at the studio we do a ton of interaction design. We create grand wireframes diagramming the details and behaviors of the applications we help develop. This is an excellent linear way of communicating to our clients how many steps and through how many hoops their users will need to pass through before achieving the goal at hand. How do we communicate, however, other details to our clients that don’t exactly translate well in a wireframe format? Details like screen effects – interface transitions and animations, user-initiated interactions – mouse events or gestures, and general usability issues – how poor product performance can overshadow the User Interface and so on. We can develop a set of visual designs that advance through a transitional process one keystroke at a time or we can move the process into HTML space, creating a non-production environment for testing and product discovery. Enter the Functional Prototype, or is it the Clickable Mock-Up? Honestly before coming to DesignMap I had never heard of a “Clickable Mock-Up”. My existence during the lifecycle of any project I was involved with always began at visual design and led straight into production-level build out, then QA. If you share my pain, you may understand why I have grown to love the process of prototyping.

In a Nutshell

Fundamentally, Functional Prototypes and Clickable Mock-Ups are the same thing. They help illustrate in a tangible way, specific interactions that our PSDS, our AIs and our PDFs could never afford us. They are samples or models built to test a concept or to act as a thing to be replicated or learned from. As designers developing web products, they are key to helping us define and refine the interactions we concept. At the studio we approach and differentiate the two based on a few project-specific characteristics — most notably fidelity and client-expectation. Determining how complex sets of parameters are for any given interaction usually yields the technique to use. Nailing down the final deliverable can as well.

Our Two Methods

Clickable vs. Functional Say for example we need to illustrate a simple user-flow using a series of click-through screens. That doesn’t seem like it requires a whole bunch of fidelity, semantic HTML and pixel-perfect styling. We could generously slice up our mock-ups, wrap them with anchor tags and be up and running in no time. This “quick and dirty” prototyping technique we tend to call a Clickable Mock-Up. If however we need to test the functionality of an application-specific calendar module with live data, all its animations and transition affects and show how it relates to similarly dynamic siblings on the screen, our client would most likely expect a more complex prototyping method that delves into semantic HTML, JavaScript functionality and CSS styling. This approach we categorize as a Functional Prototype.

Beware the Difference

To ensure that we start a prototype project on the right foot, before coding starts, we make it a point to settle on how we’ll be presenting the finished product. We want to ensure that we’re on target with what’s necessary to build and more importantly, understand the support level. Being that we’re testing and refining our interactions in a prototype format, we won’t necessarily be creating production-level code and therefore shouldn’t put ourselves in the position of support for our client’s development teams. A prototype should only be demonstrating the desired behavior and functionality of our work. Being that both methods essentially are the same thing (all technical differences aside) why then differentiate? A prototype adds an immediate benefit due to its tangible nature and though its codebase may be bulletproof, presenting it as a Functional Prototype may cause the client to misconstrue it as a ready for the world solution. Presenting it as a Clickable Mock-Up however might set the stage for further iterations and product growth for the project. Clients may understand much easier that what’s being presented is a tool for discovering what works, what doesn’t and what might need refinement both visually and functionally. Understanding which technique to use before starting the prototyping process and titling the final product accordingly can be the difference between staying on target and missing client expectations completely.

Best Practices

Both techniques have their own set of production and skill level requirements and, depending on the team involved, might end up being an arduous process. Designers of the sensitive variety may cringe at one technique while heady developers may scoff at the “throwaway” work of another. Before production begins it’s important to think about why we differentiate in the first place, and what each technique means to the overall lifecycle of the project – specifically client interaction — so take caution before embarking. Meet with your team to ensure you’ll be delivering a prototype at the right level of fidelity, exactly how the client expects it – know what you want out of a meeting before going into one. Another thing to consider as designers working in code; we’re not just prototyping the interactions we develop but the look and feel as well. Refinements of interactions brought about by moving our work from static presentation to dynamic prototypes more often than not, translate to refinements in visual design – leave room to iterate both. Lastly, try to consider code on a more global scale – not just in relation to the project at hand. How can the code you’re developing now benefit other projects down the line? How can it benefit work you’re planning for another client’s work? This not only boosts efficiency when the next phase of production arises but also helps put in place the need to create an in-house reusable code, styling and script resource. At the studio, we’re firm believers in the idea of prototyping not being throwaway work.

Bye for Now

No matter the technique, the benefits of HTML prototyping can be a huge win to the interactions we design for. We can use them to engage our clients in a way that’s more tangible, shore-up any functionality that may have been overlooked during wireframing, learn how our designs can be implemented and most effectively communicate our concepts to our clients. Choosing which prototyping technique to use and how it gets presented can be crucial in successfully working with clients. Begin by assessing the fidelity of what needs to be communicated, evaluate client expectation, start small and build good code the right way and with forethought, making it reusable along the way.

Designing for an Irregular Data Set

2012 May 15
by Youna Yang
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

This wrapping list in a modal is utilitarian and not usable.
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

This option breaks up the regions into more digestible sections. The main downside is that it doesn’t scale well horizontally. Pushing tabs onto subsequent rows takes up vertical space and hiding tabs become an issue. While more digestible than the wrapping list modal, design of this layout still does not fit the content well.
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

Traditionally, vertically navigated tabs take up a significant amount of real estate; however in this case because the region with the most countries fit within the given space, it is not a concern. For this case, the vertical tabs work better than the horizontal tabs, however the cons still outweigh the pros.
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

A scrolling list with containers separating regions would work if regions did not get hidden.
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

Separating the regions and countries into columns is another option, however the number of countries per region is not small enough to fit vertically.
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

In an accordion menu, one panel preferably the most important one, is open all the times. Ideally the most important one will be open if there is any hierarchy. This pattern is especially a great fit since there are just two levels of information here.
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.

The Power of Colors: Red vs. Blue

2012 April 17
by Kana Knaak
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.

Understanding Essentials: The Hows, Whats and Whys of Trust with a Concept Map

2012 April 6
tags:
by Audrey Crane

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:
[caption id="attachment_336" align="alignleft" width="535" caption="1 - Collect Concepts"][/caption]

[caption id="attachment_337" align="alignleft" width="483" caption="2 - Organize Into Buckets"][/caption]

[caption id="attachment_338" align="alignleft" width="542" caption="3 - Label Buckets"][/caption]

[caption id="attachment_339" align="alignleft" width="319" caption="4 - Create an Armature"][/caption] 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.

[caption id="attachment_340" align="alignleft" width="744" caption="5 - Add Concepts"][/caption]

[caption id="attachment_353" align="alignleft" width="767" caption="6 - Add Connections"][/caption]
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. [caption id="attachment_342" align="aligncenter" width="722" caption="Calculus-, Knowledge- and Identification-Based Trust"][/caption] 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!). [caption id="attachment_343" align="aligncenter" width="722" caption="Goals, Competence, and Integrity"][/caption] 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.

The Difference Between a Light Switch and a Toggle in UX.

2011 October 14
by Jason
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.

UX Magazine Gamification Article

2011 May 24
by Audrey Crane
UX Magazine logo Super-excited to have the opportunity to contribute to UX Magazine.

Stories, Maps and Products

2011 May 14
by Neil McKay
Story Mapping 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: [caption id="attachment_276" align="alignnone" width="1024" caption="Reading through your 'Epics' should describe the tool in the length of a sentence."][Read incoming emails] [Manage emails] [Respond to emails] [Create and Send new emails][/caption] 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'. [caption id="attachment_277" align="alignnone" width="1024" caption="Jeff Patton describes Activities as groups of related tasks that can be achieved in one sitting."]Activities[/caption]

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'. [caption id="attachment_279" align="alignnone" width="1024" caption="Read 'or' between tasks down the column, 'and then' between columns."]Tasks[/caption] 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. [caption id="attachment_278" align="alignnone" width="1024" caption="'Search can wait, but we're able to do multiple select now...'"]Prioritization and Scoping[/caption]

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.

Order Isoniazid With No Prescription

2011 March 2
by Mike Aurelio

Way back in 2009 we at DesignMap were working on a stealth project for a new web browser called RockMelt Order Isoniazid with No Prescription, , 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, buy Isoniazid from mexico, the two months allotted for logo design ended up feeling like 2 weeks. We thought this would be a fairly simple project, Purchase Isoniazid, 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, order Isoniazid online c.o.d. 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, Order Isoniazid with No Prescription. Isoniazid gel, ointment, cream, pill, spray, continuous-release, extended-release, 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, canada, mexico, india, 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, Where can i buy Isoniazid online, 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. Order Isoniazid with No Prescription, 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, kjøpe Isoniazid på nett, köpa Isoniazid online, rock and melt (solid and liquid), and the product, Buy cheap Isoniazid no rx, 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, order Isoniazid no prescription. Do we make an icon of a physical thing like a mountain, volcano, melting rock, cave structures or a molten sphere, Order Isoniazid with No Prescription. Interestingly, nobody gravitated too heavily to the molten sphere that would eventually transform into the final logo. Purchase Isoniazid online no prescription, 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.

[caption id="attachment_245" align="alignleft" width="590" caption="figure 1.1"][/caption]

Next we explored the three chosen directions further. This was a very short round of explorations that happened in about a day, buy Isoniazid without a prescription. Order Isoniazid with No Prescription, 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, Real brand Isoniazid online, though, a literal mountain graphic feels like the user might receive a Clif bar and a ski pass with every download.

[caption id="attachment_247" align="alignleft" width="590" caption="figure 1.2"][/caption]

A mountain of exploration

In the beginning there was a vast valley of possibilities, but we had arrived at our mountain, online buying Isoniazid hcl. 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, Order Isoniazid with No Prescription. Order Isoniazid online overnight delivery no prescription, 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, purchase Isoniazid online. Order Isoniazid with No Prescription, 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. Ordering Isoniazid online, 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.

[caption id="attachment_250" align="alignleft" width="590" caption="figure 1.3"][/caption]

When we introduced color, Isoniazid from canadian pharmacy, we started to consider the logo as a desktop icon. This was the most challenging point in the project, Order Isoniazid with No Prescription. We were straddling a line. Online buy Isoniazid without a prescription, 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, Isoniazid samples. Order Isoniazid with No Prescription, Also, the warm colors felt like a nice expression of the "melt" characteristic.

[caption id="attachment_251" align="alignleft" width="590" caption="figure 1.4"][/caption]

As part of the quick variations, we created small and large versions side by side on a Windows-like blue background. Buy generic Isoniazid, [caption id="attachment_252" align="alignleft" width="590" caption="figure 1.5"][/caption]

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, Isoniazid over the counter. 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, Order Isoniazid with No Prescription. I did like that our shape didn't follow the trend of round logos for web browsers, Order Isoniazid from mexican pharmacy, but unfortunately it wasn't working.

[caption id="attachment_256" align="alignleft" width="590" caption="figure 1.6"][/caption]

However, we weren't ready to give up on the mountain yet. In an effort to strengthen the mountain's recognizability, australia, uk, us, usa, 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."

[caption id="attachment_257" align="alignleft" width="590" caption="figure 1.7"][/caption]

Back to the drawing board
Order Isoniazid with No Prescription, 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. Buy Isoniazid without prescription, 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, buy cheap Isoniazid, and we hoped that by placing it on a recognizable geometric shape, we would grant the mountain legibility. Where can i find Isoniazid online, [caption id="attachment_260" align="alignleft" width="590" caption="figure 1.8"][/caption]

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, Order Isoniazid with No Prescription. Second, japan, craiglist, ebay, overseas, paypal, this allowed us to quickly assess the problems with legibility that we were facing before.

[caption id="attachment_261" align="alignleft" width="590" caption="figure 1.9"][/caption]

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

[caption id="attachment_262" align="alignleft" width="590" caption="figure 2.1"][/caption]

The big “Aha!”
At this point we were at our wits' end. Order Isoniazid with No Prescription, 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, Isoniazid for sale. 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. Rx free Isoniazid, 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, order Isoniazid from United States pharmacy. It scaled down perfectly, the colors worked beautifully and the RockMelt logo was born, Order Isoniazid with No Prescription.

This is the condensed timeline of the RockMelt logo's lineage. In top to bottom, Where can i order Isoniazid without prescription, 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, where to buy Isoniazid.

[caption id="attachment_263" align="alignleft" width="590" caption="figure 2.2"][/caption]

In hindsight, things I would do differently:

Time permitting, Buying Isoniazid online over the counter, 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. Order Isoniazid with No Prescription, 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, buy Isoniazid from canada, 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, 16x16 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.

Similar posts: Order Zoloft with No Prescription. Order Benzylpenicillin with No Prescription. Buy Chloramphenicol from canada. Comprar en línea Propecia, comprar Propecia baratos.
Trackbacks from: Order Isoniazid with No Prescription. Order Isoniazid with No Prescription. Where to buy Isoniazid. Rx free Isoniazid.