Viget Advance : The Strategy Lab

Waxing Speculative about Amazon’s Business Model

2009-06-22T19:34:00Z

From Jeremy Keith's notes on Jared Spool's AEA Boston talk:

You can buy an iPod nano on Apple, Best Buy, etc. for about $149. Amazon sells it for $134. That’s probably cost price. It turns out that Amazon can sell almost everything at cost price and still make a product because of volume. It’s all down to the Negative Operating Cycle. Amazon turns over its inventory every 20 days whereas Best Buy takes 74 days. Standard retail term payments take 45 days. So Best Buy is in debt between day 45 and day 74. Amazon, on the other hand, are sitting on cash between day 20 and day 45. In that time, they can invest that money. That’s where their profit comes from.

Holy smokes. Maybe I'm dense or out of the loop on these things, but while I figured there was a volume advantage to Amazon, I didn't realize that this cycle-based plan was the key to their profits.

Barn and I were talking about this a little over IM today, and this gives a lot of fun fuel with which to speculate about all things Amazon.

Sustainability

The first question is: how stable is this kind of model? Will vendors start shortening the cycle on Amazon, knowing that Amazon is able to pay more quickly? My guess is probably not. If vendors are widely accustomed to the 45-day terms, and Amazon is providing a large portion of their sales, then everyone is winning. I can see pressure coming from vendors who are also retailers, like an Apple, in an effort to keep Amazon prices in line with the rest of the industry, but it's probably likely to stay put on the whole.

As a follow-up to that, if Amazon is dependent on the returns it's getting on these investments, is the down market strongly impacting them? You have to guess that it would, but their Q1 2009 revenues and earnings are up year-over-year compared with Q1 2008. Even if their returns are lower on these investments, their lower prices may be working really well at bringing in increased sales in this recession, where consumers are more price-conscious than ever. They are indeed growing slower than they were in this economy, but they're still the best on the block.

Competition

How can brick-and-mortar operations like Best Buy compete with Amazon when Amazon can sell at cost all they like? Best Buy relies on two things in competing with Amazon:

The need to try-before-you-buy, especially with products like consumer electronics.
The need to have a product right now. Amazon's fast, but it's still next-day at best. If you need something today, you're going to a brick-and-mortar store.

Amazon can lessen the impact of the former by making returns even easier and lower-risk than they do now. Taking cues from Zappos, which has made buying clothes and shoes online almost risk-free, could help make this happen. A broader return policy (many items cannot be returned to Amazon if they've been opened) and free/cheap return shipping would be enough for the vast majority of consumers.

The latter is much harder, and is probably where they're less likely to try to compete. But can businesses like Best Buy rely largely on that immediacy as an advantage? It seems very relevant to incidentals and consumables like office supplies, blank CDs, and even books/music/movies (if you don't have a Kindle, TiVo, or Apple TV), but folks can usually wait a day or two for a pricey consumer electronic product in exchange for a discounted price.

Amazon Stores

I actually think that Amazon is more than happy to stay out of the storefront game, and that they'd lose a big piece of their price advantage: sales tax. Having storefronts mean that all sales, online and offline, would be charged sales tax in states where those stores existed. Saving that 4-10% figures into their pricing advantage in an enormous way, and storefronts kill it instantly.

But it's far more fun to think about Amazon trying to compete for those customers who need something immediately. It's not insane that Amazon might dive into the storefront crowd (I didn't say it was likely, just not insane). It would certainly be counterintuitive to folks at Amazon, but let's imagine that they're inspired by the success of Apple's play into storefronts.

What would an Amazon store look like? A few ideas:

First, it's impossible for Amazon to sell in a store even 10% of the SKUs they sell online. They'll need to keep their selection trim. This comes with disadvantages, though: think of the last time you looked up a price on Target.com and only realized once you got to the store that it was an online-only product. To avoid this, the hypothetical Amazon store would have to be very focused: there would need to be an expectation that far more items are carried online, and only those that fit a certain profile would be carried in a store. It would be fun to consider a model where the top 10 sellers in their online store in various categories would get a spot in the store, where online activity is directly impacting the stock of their stores.
Amazon could drive their apparent cost down even further by allowing users to ship their order to a storefront for free, like many other storefront retailers do already.
Amazon's knowledge of your purchase history could make for a really interesting store experience. Let an Amazon iPhone app (or a special in-store product) scan the barcode of an item and tell you if it's compatible with other products you've bought from Amazon in the past. No longer would you need to remember whether or not your camera has an SD or CF slot.

How else could a great online store, like Amazon, transform the storefront experience for the better? What would you do if you were in charge of creating an Amazon storefront? It's all fantasy-land, but it's the fun kind.

The Shackles of Simplicity

2009-06-16T19:12:00Z

Simplicity has been at the core of the web's philosophy of design for the last five years. Whether it's a major part of the visual approach, with large amounts of negative space, simple color palettes, and a focus on strong typography; the interface approach, with fewer things on a given page; or the product approach, with products that do "one thing well"; nearly everyone has carried the banner of simplicity at one point or another.

But while this approach has indeed helped us make products on the web that can appeal to a mass audience, it is starting to show its limitations. After a few months (weeks?) of using a simplicity-centric product like Basecamp, you start to run up against its limitations: it may facilitate the way that the creators work best, but you're not quite like the creators. Maybe you've outgrown the simple feature set and need more for your modestly-growing needs. Maybe you no longer have a few months' worth of content in the system, but now have years of content, and managing it all has become a bear. Simplicity is beginning to fail.

Part of the problem is that simplicity is the solution to a problem poorly-identified. Life is complex, and tools to conquer life's complexity need to instead embrace it, rather than ignore it.

Occam's Razor

A former student of philosophy, I can't get away from a conversation about simplicity without bringing up Occam's Razor. This principle, commonly referred to as the *simplicity principle*, is core to all logical and philosophical argument, and really ends up being at the core of the contemporary drive for simplicity in design.

The idea is that the best solution to any problem is that which has the fewest assumptions or factors, eliminating anything from the equation that doesn't matter enough to impact the outcome.

This sounds pretty straight-forward, and is a great tool for evaluating your own progress toward the solution to a problem. However, the devil, as always, is in the details. It's easy to eliminate a factor -- it's much more difficult to know that it doesn't matter enough.

Understanding Complexity

Some concepts just aren't simple, no matter how they're framed. A few weeks ago, I was talking with Ali about her work on a guerilla redesign of the Supreme Court's website. As we were talking, we kept coming back to the fact that stakeholders involved were chasing after simplicity, and Supreme Court decisions aren't simple. A legal decision at that level can't be boiled down to a score like a baseball game, and even the most succinct summaries require a bit of background.

Complexity isn't confined solely to the fields of law and medicine. In fact, common, everyday tools often need explanation and clarification to be adequately understood. Other times, many simple tools need to come together in a way that creates complexity.

By trying to simplify the inherently complex, you're likely to run into one of two outcomes:

You may find yourself beating your head against a wall, searching for the simpler representation that doesn't actually exist. Time is wasted, frustration ensues, and bad decisions get made.
You over-simplify the problem. This is a frequent problem with everything from project management software to explanations of Supreme Court decisions. It's the result of ignoring the importance of certain parts of the problem that, in the end, cannot be ignored.

In the end, Ali's redesign was an overall success, but there are specific parts of the interface that are over-simplified and actually end up being misleading rather than helpful. They're small factors, but they detract and distract from the otherwise-overwhelming success of the project.

Embracing Focus

Instead of valuing simplicity, consider valuing focus. If your design focuses on specific goals or tasks, like being able to manage domain names, you're able to embrace simplicity or complexity as it makes sense.

You may make the process for renewing a domain name incredibly simple, where the process for managing DNS entries could vary in complexity depending on the task -- adding a subdomain may be simple at first, but complexity could be allowed for changing a subdomain's TTL. If you've ever had to transition a website from one server to another, you know how important the ability to manage a TTL can be to a smooth transition, but many domain name providers don't provide an interface to make that adjustment, seemingly with the goal of simplifying the interface.

Focus allows you to create features for more advanced or experienced users, who often allow and in fact desire complexity. Focus also allows you to ensure that new users are able to complete tasks as easily as possible, without oversimplifying the problem. Focus provides liberation from the bonds of simplicity while still providing the constraint that aids successful design.

Managing Complexity

When you come across complexity within the scope of a focused design, the question moves to how that complexity can best be managed. While this is the topic for at least a book or two, there are a few strategies worth sharing that can help move a design toward success.

Realize that managing complexity can be hard. Devising a good solution to a complex often problem takes really smart, talented, creative people a significant amount of time. Expecting to address a complexity challenge in a couple of hours is relying on luck.
Address complexity visually. If the most complex parts of the process are secondary actions, treat them that way visually, allowing users to focus on the core. If they're primary, make sure that all possible clarity is given to the interface, so as not to muddy the already-confusing waters even further.
Consider chunking tasks based on complexity. If a problem has multiple parts, separating the more complex ones from the simple ones can help aid usability. This can be as simple as having a view that turns on the "advanced features" or it can allow multiple paths through a process, depending on the needs and desired outcome.
Take the entire system into account when looking for efficiencies. If you've got laser-like focus solely on your design, you may be missing opportunities to leverage other parts of the system. A mobile phone's GPS chip may be a piece of the system you can leverage if location is a significant factor in your design. For internal corporate products, for instance, other internal systems (like payroll, user directories, or scheduling systems) can be used to make the product you're designing "smarter," thereby helping a user through a particular task.
How would a good teacher help a user through this process? Teaching helps newcomers understand complex ideas long before and after we're in school. Consider how you might best teach users confronted with this task, and enable the system to do that teaching -- or better yet, get a good teacher's opinion. Whether it's a little extra explanation around a form field, a clearer path to the finish line, a modular form that adjusts to user input, or even a video walk-through, teaching can help a user get a hold of her wits and achieve the desired outcome.

All of this management of complexity is assuredly complex in itself, but it's not something we can eliminate from the problem with Occam's razor. It's part of our jobs as designers and architects to tackle the hard work along with the easy work, and that means solving the whole problem.

Hopefully the next five years will be those where web designers learn to focus, rather than simplify. If so, we'll be making new tools that not only work well, but help us conquer some of life's more complicated problems.

Geo: Soon to be Legit

2009-06-15T20:37:00Z

The W3C has been working on a specification for a geolocation API, and has reached the point where it's starting to firm up and come together. That's good news, as it allows browsers to tell websites, through a JavaScript interface, where the browser is located.

The better news is that we're going to be able to use these new APIs sooner than you might have thought, given the relatively new nature of the API draft spec. Opera has implemented the spec in builds for several months, and it will be implemented in the release of Firefox 3.5. More recently, it's become evident that Mobile Safari in the new iPhone 3.0 software provides a geolocation API, and it appears (outside of the NDA realm, at least) that it is indeed compatible with the W3C API.

What does this mean? It's the beginning of an opportunity for designers and developers to start using specific location as a context on the web. This can play big roles or minor roles:

No longer asking a user to search for the closest location of a store. Just show them the closest, and allow them to adjust if needed.
Allowing for a nearly-actionless customization of content based on location, like for a news, weather, or traffic site.
Letting a user know if your business provides service in that user's area.
Locating users' contacts in a given area (the stereotypical geo-social play).
All sorts of other uses.

The new API won't get around the privacy concerns of asking for a location, so it doesn't mean you can be sketchy without permission, but it will eliminate a lot of potential steps users have to take now. Users will be prompted to allow a site to know the device's location, and have to be able to revoke that permission, much like the iPhone currently does.

True, geo is probably most useful for mobile apps, but there are plenty of potential uses for users who aren't on their phones as well. Hopefully, 2009 and 2010 will be the years we start to discover the real potential of a geo-enabled web.

Managing Wireframes More Effectively in OmniGraffle

2009-05-18T15:52:00Z

I’ve been using OmniGraffle as my primary tool for wireframing (and most everything else) for about 3 years. In that time I feel like I’ve gotten pretty good at using it efficiently, but I do try to keep an eye out for new tips and tricks. Recently, I’ve been following along as the documentation geniuses at EightShapes have developed and released their InDesign-based documentation system called Unify. I was intrigued by one idea in particular: keeping wireframes and wireframe documents as separate files.

Since I started at Viget I’ve always developed my wireframes directly in our OmniGraffle template, and have frequently found myself struggling with pages that don’t nicely fit inside the frame we created for the design. Inspired by Unify, I realized that I didn’t have to do it this way. I could create the wireframe as a separate document, then embed it within the documentation template once the wireframe was ready to be delivered.

Demo Video

Rather than break the process down into detailed steps, I recorded a short video that demonstrates how this works in practice. I’ve provided a summary of the video below.

More Effective Wireframes in OmniGraffle from Viget Labs on Vimeo.

Creating the Wireframe

I’ve created a OmniGraffle document template that’s 512px wide, with the scaling set to 1pt = 2px, for an effective width of 1024px. This keeps the document to a reasonable size, but you do need to keep the scaling in mind as you work. However, there’s no reason a 1:1 scaling wouldn’t work as well, especially since you can then put the Konigi UI stencils to good use.

This document is my wireframing canvas, where I now do the bulk of my design work. Once I’ve complete the wireframe, I export the finished design to JPG or PNG at a reasonable resolution.

Creating the Document

Next, I open up the document template. This template has a rectangular shape set aside the wireframe. Now all I have to do is drag the image file I exported into this frame. I can adjust the zoom level to make sure that the entire wireframe is visible, or drag the image within the frame to position it. It’s easy duplicate the page, and show the top half of the wireframe in one, and the bottom half in the other. No need to actually split the wireframe in half.

Once I’ve embedded the image of the wireframe, I add my annotations as a new layer. If I make changes to the wireframe, replacing it in the doc is as easy as dragging the new image into the frame. Once everything is in place, I export the document to PDF for the client. A secondary benefit of this technique is that I can now deliver two versions of the wireframe: the annotated PDF, and a set of 1:1 scaled images.

No More Fear of Heights

Working outside the confines of the documentation template has made working with odd sized pages significantly easier, and I feel like the wireframes I’m producing are more more realistic (in a good way). Thanks to EightShapes for the inspiration, and I hope you find this approach as helpful as I have.

Testing Web Text Readability

2009-05-13T13:28:00Z

Since my post about line length on the web got a bit of attention, much of it calling for more research, I figured we could help out with that a bit.

We've written up a brief reading comprehension test that can help us figure out if there are conclusions to be made about web text readability in different conditions. It's fast, it features a fun and quirky Cory Doctorow story, and it needs your input.

So head on over to the readability test and spend 10-15 mins to help us gather some great results. While you're at it, try to get everyone you know to take it as well, eh?

Once we've gotten a decent sample, we'll post the results here, so stay tuned.

Sketching in the Kickoff Meeting

2009-05-13T13:00:00Z

I recently had to deal with a frustrating (but relatively common) problem: A client had a pretty clear idea of what they wanted, but that idea wasn’t clearly communicated in the RFP. We went through a few iterations of wireframes, and finally found a design that felt comfortable to everyone. We plan our engagements with just this approach in mind. However, I couldn’t help but wonder if we could have gotten to that point sooner if we’d been able to take the picture the client already had in their head and use it as our starting point.

On occasion we’ll get clients who have already produced some kind of design “sketch” to document the product they want. These sketches have always been a great discussion pieces to kick off the design process. What I was looking for was a way to get that same conversation started with clients who weren’t comfortable with producing mockups in Visio, PowerPoint, or Photoshop.

The answer was decidedly low tech. At our next kickoff meeting, we reviewed the project goals and requirements, then handed everyone a pen and a stack of paper and asked them to draw their dream website as best they could. I thought this might take some cajoling, but everyone jumped right in and started drawing. After about 5-10 minutes, we put the sketches up on the wall and asked everyone to give us a walkthrough of what they’d produced. Over the next 15 minutes we learned an amazing amount of detail about the site we would be re-designing; little details that would have been hard to communicate in an RFP (or tedious to read through). We annotated the sketches with these insights as we went along, and I used them to inform the first set of wireframes we produced for the project. The result was a very happy client, and a lot of time saved.

Do Try This at Home

Interested in trying this yourself?

Discuss Project Goals & Challenges First — This gets the entire team thinking through the problems we’re trying to solve and the goals we’re trying to achieve, and helps focus thinking towards solutions to those problems.
Set Expectations — This exercise is intended to provide inputs into the design process, no to produce final designs. Setting this expectation clearly up front will help when the outcomes don’t match the sketches exactly, and will hopefully avoid locking you into a particular solution too soon.
Have Materials on Hand — You don’t need to be fancy. While I love sketching notepads, plain white paper works just fine. Thicker markers or pens are handy, since they discourage people from dwelling too much on details.
Set Aside Time — It took us about 25 minutes in total to do the exercise for one page in a news site. It was sufficient for this project, but I would probably set aside 30-45 minutes for each page you want to cover. Project complexity will play a big role here.
Review the Results — The sketches themselves are handy, but a lot of the value in this exercise is the insight gained from the conversation around them.
Be Prepared to Help Things Along — I participated in a workshop with Leah Buley and Todd Zaki Warfel where they made a great point; drawing a UI is nothing more than lines, circles, and squares. If you can draw those shapes, you can draw any UI there is. Be prepared to demonstrate this point if you've got reluctant participants.

No Silver Bullet

I’m happy to say that our experiments adding a bit of art studio into our client meetings produced some very nice results. At the same time, I don't expect we'll be putting this into practice with every client. In fact, I suspect there will be clients who will resent the very idea, after all, we're supposed to be the experts and they shouldn't be doing our work for us. While I very much hope those clients will be few and far between, we're still feeling out the circumstances where we can use this method most effectively.

Credits

I can’t in any way claim to have invented this idea, I drew my inspiration from a number of past presentations and discussions with Todd Zaki Warfel, Leah Buley, Will Evans, Russ Unger, and others.

The Line Length Misconception

2009-05-07T19:36:00Z

Classically-trained designers, and really every professional designer, should know the old adage that long line lengths can have a counterproductive impact on readability. The trusty copy of Bringhurst's authoritative The Elements of Typographic Style makes this rule fairly cut-and-dry:

Anything from 45 to 75 characters is widely-regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal.

So naturally, when designers work on the web, they're keeping this rule in mind. Consequently, it's become a best practice on the web to keep line lengths below 75 characters, and this best practice has been the source of dissent against movements for things like variable-width (fluid) layouts and the like.

But research doesn't support this claim, at least on the web. Instead, users are able to read significantly longer line lengths on the web, and it actually increases efficiency and comprehension.

The Research

The first research I could find relating to this topic went all the way back to 2005. The study,The Effects of Line Length on Reading Online News, looked at how well college students read news on the screen at different line lengths. They tested line lengths of 35, 55, 75, and 95 characters. The study came to two important conclusions:

Reading speed was highest at 95cpl, and lowest at 35cpl on screen.
Reading efficiency was again highest at 95cpl.
They found that line length no impact on comprehension on the screen

These days, it would be a bit nicer to have a wider array of line lengths, perhaps going up to 115 or 135cpl, but this is a useful study.

Guesswork

In a very brief and informal search, I came across a healthy number of sites that had line lengths around or above 100 characters that seemed quite readable, including my own blog. So what makes the screen significantly different from print that would impact comprehension in this way?

A few guesses, with absolutely no basis in research, the third being my favorite:

We've been conditioned to longer lengths by websites that have tended to stretch the top end of this limit, as opposed to newspapers, which tend to stretch the lower end.
The active lighting of a computer display is more conducive to longer line lengths than passive paper.
Perhaps line lengths that are out of proportion with their medium are more difficult to read. Print tends to have vertical layouts, which would naturally correspond to shorter lines, while we tend to use widescreen monitors these days. Perhaps the widescreen monitors are more conducive to the readability of a proportionally-longer line length.

If the range of line lengths had been wider in the study, and if we had an updated study since the widescreen monitors had become popular, we could really see what might be impacting the difference.

Best Practices

So should you really be limiting your line length to 75 characters? This research suggests you shouldn't. Users will be perfectly fine reading longer columns of text.

What is the new standard? Tough to say, but 100cpl seems to be within the range of feasibility. There may be a good opportunity for some new and more thorough research in this area that could offer some valuable new insight.

Prototyping with Production Purposes in Mind

2009-05-06T02:02:00Z

(X)HTML Prototyping and Agile Development go hand-in-hand. When working in a faster, more iterative process, there are definite benefits to using (X)HTML to communicate an interface and the various flows users traverse through it. Along with those benefits come challenges that many UX professionals continue to wrestle with. Existing wrestling matches aside, another challenge presents itself once the prototyping phase has served its initial purpose. After that point, do you throw away that front-end development work or re-cycle it into the foundation of the project to be visually designed and technically developed?

The Scenario

On a recent project that involved developing an application on a very aggressive timeline, we came across that very question after jumping into agile project planning. During planning, Jackson and I were tasked with rapidly designing the application's interface. To save time, we agreed to divvy up the interface (based on common user flows) and sketch concepts as a first pass. Validating and solidifying these sketches by jumping into (X)HTML prototyping was our next step.

Following those process decisions, we tackled the question of whether to recycle or toss our work (once our goals were accomplished). For our team at-large, the decision to re-use the markup made a lot of sense given the limited schedule, small team involved, and collective experiences we UXers had in producing production-level markup. For the developers on the project, that meant using our prototypes to inform the application's modeling, structure, and eventual output. Recycling -- for the visual designer -- meant visually theming the interface we'd design, and then visually styling the markup we'd use for our prototypes.

With that plan in mind, we set out an iteration timeframe ahead of the designer and developers. A few busy weeks went by. And while I am extremely proud of the work, collaboration, and final product that the team produced, the debate on whether or not to use prototype (X)HTML during production still wages on for me. Here's where my thinking on the topic:

The Benefits

Efficiency — When prototyping in (X)HTML, there's the potential to save time and effort down the road by taking a first pass at items such as semantic markup, general interface layout, and content generation.
Using a Universal Language — Producing a prototype in a format that not only your UX team knows (cough .graffle files cough), but your own cross-disciplinary project team has more experience with can have a huge impact on the team's understanding of the interface, and its scope and capabilities. (X)HTML is perfect for this, as often both developers and designers alike are more than familiar with it. The extra semantic weight, consistencies, and information (X)HTML gives the content within an interface can add to these groups' understanding of modularization, functionality, and even different states of the interface as it gracefully degrades.
Eliminating Ambiguity — Recycling front-end development in future project phases means that elements such as status messages, in-page interactions, and various conditional states within an interface are at least noted, if not discussed and acted upon during the first UX pass. Often, when prototyping through paper and passing along, these are easier to overlook.

The Challenges

Blurring Responsibility — Being the first individual to touch the markup means becoming the local authority on it, as well. This doesn't completely match up with the traditional list of responsibilities requiring the visual designer or front-end developer be the keepers of the (client side) code. It can mean extra efforts and time spent on maintaining and communicating practices around this code instead of on UX-related tasks.
Conflicting Interests — A focus on using the medium of (X)HTML to review a more interactive form of an interface can be trumped by larger project and other long-term team concerns. While it is good enough for a proof-of-concept, is the markup generated production-ready? The markup may contain consistency and flexibility for prototyping purposes, but does it adhere to any internal or client-based standards? Repetitive items may be pulled into re-usable snippets to developers; however, is that code re-factored and abstracted appropriately?
Pulling Multiple Shifts — In Agile iterations -- or, at the least, in accelerated waterfall process steps -- things move fast. As Richard Cecil notes, this can leave a UX designer with the simultaneous responsibilities of carrying forth research and making design decisions for an iteration two steps away; developing the prototypes for the next upcoming iteration; and supporting the validation and implementation of the markup from the prototype now being used for the current iteration developers and designers. While, with planning, this can be manageable, the extra focus involved with implementing markup from the prototype demands could dilute the amount of attention given to the quality of future iteration work.
Trading “Popsicle Sticks and Paste” for “Brick and Mortar” — While the UX gains of prototyping in (X)HTML center on swift validation within an interactive medium, the tradeoff for those gains is, in many cases, stability in interface construction methods. Shortcuts are used to erect a scaffolding, styling used to show form for functionality's sake only, and states are described, but merely toggled without true logic. This philosophy certainly does not match up with the bulletproof-level quality of a completed application's logic and code. So, where does that transition happen from the former stateto the latter? It can be harder to cleanly move to the production-ready level when carrying over a foundation of assets created from the prototyping philosophy above. Artifacts of the scaffolding can easily be forgotten or misinterpreted and embedded within the production-ready work. Questions arise on if and how to logically segment the replacement of prototype-era with production-era work without disturbing other current prototyping or production work simultaneously happening.

For Future Consideration

Projects, especially in this economy, will continue to lean towards optimizing budgets and schedules. That means these scenarios of potential re-use aren't (nor are their benefits and challenges) going anywhere. So, how can we address the challenge of designing in the medium of (X)HTML, CSS, and JavaScript, and have our work used later in a project's life-cycle while still achieving the outcome we need from the exercise?

What Were We Here For? — Don't lose focus of the primary purpose of using HTML for prototyping. It is imperative that the goals of the UX phase (validating the effectiveness of the interface against user expectations and behaviors) are fulfilled through this exercise first. If that's not completed, you're running the risk of spending even more time revisiting this phase than if you had taken a more static and traditional approach to begin with.
Cut Your Work Out Ahead of Time — Practice Parallel Track Development, which includes preparing the proper amount of research and design work in time to also participate in the support of the current iteration's implementation. Sketching, re-usable and lightweight (X)HTML and CSS Libraries, as well as JQuery trusted plugins and state handlers such as Polypage can help you avoid re-inventing the wheel and cut some heavy lifting time while still producing a representation of heavier functional designs all within single-iteration timeframes.
Play Well With Others — When working with designers and developers, communication is key. This means clearly communicating the state (e.g. in progress vs. complete vs. integrated by development) of prototypes to be handed off. We used a set of pre-defined classes on the <body> element of views to show their status of completion in attempt to avoid extra questions and confusion. Controlling the various revisions through version control of prototypes is a must as well with this. Virtual (through Campfire in our case) as well as in-person walkthroughs and Q&A sessions were a common occurrence during our collaboration to help with measuring scope, receiving team feedback, and prioritizing tasks.
Reach Out to the Experts — If you're rolling your interface design work into an application or CMS, chances are you'll be working with not only client-side languages, but server-side technologies wielded by developers as well. And that (X)HTML you've written? Down the road, it is going to have to accommodate the visual designer's creative vision and theme. With those things in mind, reach out to the developers for a basic list of server-side syntax (includes, partials, links to other views, etc.) that may be helpful to you in expediting your work and revising it in the future. Similarly, asking for and adhering to any web and front-end development standards or conventions your visual designer may have will go a long way in providing a solid foundation.

And Yourself?

How common is the re-use of UX (X)HTML Prototypes in production in your experience? Do you think its valid to re-use the front-end development work completed as part of the prototyping throughout the project? If so, do you have any thoughts or resources you use for support?

An Open Letter to Third-Party Twitter App Founders

2009-04-29T13:12:00Z

Dear Aspiring Twitter Speculators,

Congratulations on your new idea. You’ve come up with, and perhaps already built, a product that is genuinely useful to almost every Twitter user, filling one of the many feature canyons left open by the Twitter product team. Perhaps you’ve already gathered a respectable following on the interwebs, with a few thousand people using your service on a regular basis. All that, and it only took you a couple weeks to build on the side.

Now you’re waiting for the big moment to happen: the call from Ev or Biz or whomever. You’re sure they’re going to want to purchase your product for loads more money than it took you to build it. It fills a clear gap, after all, and there are already people using it. They bought Summize, right?

Unfortunately, gentle reader, there are a some significant differences between Summize’s situation and yours. Let’s take a moment to consider them:

Summize was not simple. Summize was a largely-original search engine based on technology the Summize team had been working on for many months for a different product. There was a lot of significant technology behind what seemed like such a simple product.
Summize scaled. When Twitter was failing, Summize’s search kept trucking along. Many users adopted Summize as an ad-hoc Twitter client during the dark days of abysmal uptime.
Summize had some sick engineers. Twitter didn’t just buy the search engine, they acquired the company. Of the six Summize employees, only the founder and CEO moved onto another project — the rest moved to the left coast and joined the Twitter team. This was an acquisition of talent as much as it was of product.

Summize didn’t just fill a product gap, it filled gaps in Twitter the company, and that’s an enormous factor in why they were acquired. Does your product, and your team, do that?

Let’s look at an example. Up until last week, when it stopped working, Twimailer was my single favorite Twitter-based product. It allowed me to get a much more detailed follower notification, with the follower’s bio information, recent twitter messages, and stats. It was also implemented in a smart way: they give you a special email address, you tell twitter to send notifications to that address, and Twimailer parses the notifications, creates the nice ones, and forwards them along to you. A couple friends of mine assumed they would be ripe for an acquisition.

Here’s why not:

It’s down. It’s been down for a while now. Maybe it’s dead. That certainly hurts its chances, but even if we ignore this…
The tech is worth nothing to Twitter. Sure, their implementation was reasonably slick, but that was necessary to work around the fact that Twimailer was an external app. All that email parsing shenanigans is completely unnecessary to Twitter.
It’s easy. If you’re the Twitter team, implementing the Twimailer feature set takes a few hours or days, not weeks or months.
There’s no real IP there. The idea of a more useful email isn’t novel or unique in a sense that Twitter would be buying patentable IP or anything like that.

An acquisition of Twimailer, TweetCC, or many of the other eleventy-billion Twitter-based webapps just doesn’t make any sense. And so it probably doesn’t make sense for them to acquire yours, either. Maybe you are indeed the next Summize, but the road is uphill and only one has been chosen thus far.

But don’t be discouraged. You’ve made a service that is valuable to thousands, hundreds, or even dozens of people, and that’s a good thing. Perhaps you can modestly monetize it and have it contribute a tidy sum to the lifestyle to which you’ve grown accustomed.

After all, the journey is the reward, no?

IA Summit 2009

2009-04-21T18:06:00Z

It can be an odd experience attending a conference in a recession, and my trip to the 10th Anniversary IA Summit in Memphis, TN, didn’t disappoint in that regard. The event was smaller, tinged with uncertainty, and chock full of people trying to figure out what the future holds for themselves and for their profession. I left feeling both frustrated with the angst, and brimming with new ideas and a deep desire to return next year. It took me a while longer to get all of these thoughts down than I thought it would, about a month longer in fact, but I’ve enjoyed re-visiting my favorite talks in order to share them with others.

Sketchboards & Prototypes

I spent my first day at the Summit learning about Sketchboards and Prototyping with Leah Buley from Adaptive Path and Todd Zaki Warfel from MessageFirst. Sketchboarding is an analog method for sharing design inspiration, iterating on design concepts, and mapping out user flows. My team worked on designing a document collaboration tool as part of “Facebook for the intranet”. We quickly sketched ideas, put them up on the board, identified common patterns and solutions, then began to identify parts of the flow we hadn’t adequately defined. There wasn’t nearly enough time to tackle the problem, but the exercise gave us a great introduction to the process.

Todd led the afternoon prototyping session, where we talked about principles of prototyping, and got our hands dirty creating some fairly sophisticated interactions with paper, tape, scissors, and transparencies. Our crowning achievement was a “functional” video player for the iPhone (complete with giant paper iPhone). If you’re interested in Todd’s work, you can check out this recap from a workshop he ran here in Durham last year. You can also check out his upcoming book on prototyping from Rosenfeld Media.

Michael Wesch

The first day of sessions kicked off with an amazing high speed presentation by anthropologist Michael Wesch from Kansas State. The subject of Michael’s talk wasn’t exactly new, that we’re entering into an era of participatory culture mediated by the tools we ourselves are designing, but his presentation was an amazing thing to behold. There’s a podcast online, but it’s too bad there aren’t videos available.

Podcast

Digital Space & The Context Problem

I’ve heard Andrew Hinton give various talks on the problem of context, but he never fails to help me dive deeper into the problem. Simply put, digital spaces lack physical context, and frequently do a very bad job of substituting a digital context for the physical. This problem might seem a bit abstract, until we realize just how important context is to human cognition. Andrew has a number of great examples of this, but the one that resonates with me is role of context in social cognition. We have relationships with our families, our friends, our peers, our co-workers, and more, and we modulate both how we express our selves and how we process information based on which context we’re in. Digital social spaces tend to collapse these contexts, connecting us with all of our social circles through one channel, allowing us to express ourselves in one way. This gets worse as when we introduce aggregation into the picture, because we not only collapse social context but also “object” context. In some way, we can work around the problem of context by segregating our interactions across tools. Aggregators take away even that modicum of control.

Andrew asked us how we’re going to start to understand the ramifications of this shift in context, and to start thinking about how we’re going to understand the problem. Is this a fundamental behavioral shift? Is it a problem to be solved? Or is it an opportunity to create new kinds of contexts?

Slides | Podcast

Speaking the Language of Business

After having the pleasure of meeting Eric Reiss at dinner, I was curious to hear his views on how to define the strategic and business value of IA. Eric’s core point was that we have to understand and speak the language of business, so we can sell the services we provide in terms the client (or stakeholders) will understand. Spend much time in IA circles and you’re likely to enter into a discussion on “selling IA,” and for many this has come to mean defining the ROI of our work. However, Eric contended that ROI as a measure is inherently backwards looking, and doesn’t do a good job of demonstrating the future value of IA practice. Instead, focus on actions and results, not intangible benefits.

Podcast

Designing Rules

Dan Brown’s talk focused on the idea that designing for the web is moving beyond (or, has already moved beyond) the ability to design for specific pieces of content. Instead, we need to start thinking of designing systems of rules that define how what content will appear, and how that content will behave, in a given context. It didn’t really strike me at the time, but I’ve come to realize that Dan was describing a design methodology very similar to the algorithmic game design methods of the famed Will Wright, creator of Sim City, the Sims, and, most recently, Spore.

In each case we provide the system with guiding rules, and then let go, trusting in the systems of rules we’ve created to craft the experience for the user. There are limits to the utility of this approach, but I think that as sites shift from distributing content to data, and as “content-heavy” sites become increasingly interactive, we’ll find that designing rules is far more powerful than designing content.

Slides | Podcast

Experience Themes

I’ve long distinguished “User Experience Design” from “User Interface Design” by saying that UxD aims to build holistic experiences, not just usability interfaces. The problem with that statement is that it’s hard to define a holistic “experience.” It’s one of those “I know it when I see it” kinds of things. Thankfully, this problem is getting some attention, and Cindy Chastain gave a great talk on using experience themes as a tool to conceptually tie together a design. I appreciated that the presentation included a very specific example of a project where these ideas have been into practice.

Slides | Podcast

Is Interaction Necessary?

If there was a talk that blew my mind, this was it. Karl Fast summarized a rather critical shift that’s been happening in terms of cognitive research, away from the classical idea of humans as rational actors to an understanding that context and physicality are critical to cognition. This has some pretty heady implications, particularly as we make steps into more tangible interfaces. He also introduced me to the idea of epistemic action, which recognizes that “errors” can in fact be critical to the way we think. These actions allow us to explore the problem by changing the environment quicker than we can attempt to model these changes mentally.

Podcast

Strategies for Enabling UX to Play a More Strategic Role

Richard Anderson & Craig Peters walked through a number of different strategies for making UX efforts take on a more strategic importance within your organization. In an interesting twist, they gave over most of the session to let us discuss the pros and cons of these strategies in small groups. This gave us a chance to hear different viewpoints, and to share our own thoughts about how effective these techniques might be in our own organizations.

Revealing Design Treasures from the Amazon

I’ve yet to attend a Jared Spool talk that wasn’t highly entertaining. Here he covered much of the same ground as his recent articles:

Leading With Insight

“A lot of times, people don’t know what they want until you show it to them…” Steve Jobs

“Recognizing the need is the primary condition of design” Charles Eames

I tend to avoid the “What Designers Can Learn From Oddball Thing X!” presentations the IA Summit seems prone to, but Matthew Milan managed to trick me into learning about insight from Columbo, and it wasn’t so bad. Matthew’s basic premise was that as designers, we’re in the business of finding insights into our customer’s behavior that will lead to better products. At least, that’s what we should be doing. This is why we do research, not to validate our assumptions, but to challenge them and look for that moment of clarity where we see how we can make a real improvement in an experience.

Slides

Designing Social Interfaces

Erin Malone and Christian Crumlish gave a short but informative introduction to many of the social design patterns that they are covering in their new O’Reilly book of the same name. You can see much of the work they’ve produced on the wiki they setup as a companion to their book:

Designing Social Interfaces

‘Tis the (Tax) Season

2009-04-13T11:53:00Z

If you're in the US, there's a good chance you have April 15th on your mental calendar, if not circled on your desk calendar with a bold, red sharpie. It's the due date for individuals to file their tax returns, and while about 60% of us file well ahead of time, the rest have a fair propensity to procrastinate a bit and file within the two weeks leading up to the deadline. There's good reason for this procrastination — no one likes paying taxes.

Last week, our ~~landlords~~ friends upstairs at Tax Analysts (great tagline: "Respectfully Disagreeable Since 1970") asked us to take a look at the website at the center of this early-spring anti-holiday, IRS.gov. While they were looking for input around functionality and a bit of visual design, we noticed some interesting things that we thought were worth covering here.

The Bad

First of all, let's just get this out of the way: IRS.gov is a visual disaster. The layout is poor, the typography is messy, there's almost no effective use of white space. The home page looks like someone kept talking about the fold. That much we know, so let's get over it.

Under the hood, it looks like someone was making an attempt when it came to markup, but failed in the end. Tables for layout, loads of style attributes throughout the markup, and the occasional alt-text that doesn't reflect the exact text in the image make this a great example of bad markup that may still be 508-compliant enough to pass muster.

There are other bad cases throughout the site. If you're a resident or non-resident alien, this guide may be the worst possible way to convey complicated tax information to an audience that will largely fall on the novice side of the scale.

The biggest sin, in my view, is the fact that they've failed to configure their web server to respond to irs.gov, without the www prefix. An inexperienced user going straight to irs.gov may assume the site is down, rather than realizing that the agency was just too lazy to properly configure its domain, especially since www is deprecated.

The Not-So-Bad

But really, the site has a lot of good things going on. The navigation seems lame at first, focusing on audience groups like the failed navigation on usa.gov, but it's very appropriate here. Imagine a novice asking a random expert how to file taxes. The obvious response might be a question: "well, is this for you, or a business?" The navigation reflects this, and provides reasonable portals to relevant content from each audience-centric page.

The home page has some solid content. Prominently-displayed on the home page are links to common forms (1040s are obvious, but number one is the 4868 form to request an extension: convenient!), and links to online services you're likely to take interest in. There's a big feature block that seems to have relevant info for the last-minute filer more often than not, and the lower right has a reasonably prominent link to find the mailing address if you're filing old-school.

Finally, they put at least a little effort into search. If you're stumbling on this year's new question about last year's stimulus payment, you might search IRS.gov for something like "stimulus payment." The results page not only has links to reasonable results, including a page to help you figure out the answer to the question. They also provide some editorially-chosen results at the top, in this case a page that gives a broad overview on the stimulus package. In all, you've got a good chance to find what you need via search.

The US tax code is a mess of words more closely resembling spaghetti. It's a tough job to effectively communicate everything involved, but the IRS.gov team has done a better job than most other government agencies.

Biases in Effect

The person we were speaking with at Tax Analysts mentioned that everyone they'd talked to thus far had told them that IRS.gov was an awful site that didn't meet expectations. After our analysis, including what you've read above, we thought there were a fair number of redeeming qualities to the site, so the fact that everyone else was hating on it was curious.

Then we realized that the worst job in web design is likely being the designer for IRS.gov. Why? A simple matter of cognitive bias. We encounter cognitive bias issues, where a cognitive process skews the decision of a user, all the time when working with clients. We'll use biases to our advantage at times, and steer clear of them at other times when possible.

In this case, we run up against some pretty strong cognitive dissonance: people almost universally hate the IRS. No one likes paying taxes, and the complexity of the process (as determined by Congress, not necessarily the IRS) is frustrating to everyone except Certified Public Accountants.

So when a taxpayer is at that dreadful time of year, filing tax returns, finding out that freelance gig comes at a high price in April, or wondering why her employer's automatic withholdings didn't cover the load this year, it's going to be incredibly difficult for that user to say that IRS.gov is anything other than Beelzebub's homepage. Any slight flaw becomes an enormous headache and a source of angst and confusion.

In order for taxpayers to like it, the IRS website would not only need to be perfect in almost every way, but it'd require an act of Congress to make the process easy enough for mere mortals. In other words, something would have to freeze over. Happy Easter/Passover :)

Sure, Those Colors Look Nice - But Can You Prove They’ll Work?

2009-03-31T13:03:00Z

For the past several months, I've been working with a client who is based in North America but who operates regional offices in various parts of the world where their (tourism industry) product is offered. Over the past year, we've collaborated with this client one country at a time, through their North American central office, updating some of their country-specific web properties. It's been a cool opportunity for the team to experiment with tweaking web designs to work in cultures that we haven't designed for in the past. One of the best lessons learned (well, more confirmed than learned), is that good web design (as any other form of art) transcends regional boundaries. A good web design in America is also a good web design in Norway, France, or Australia because, at the end of the day, the best web design gets out of the way and lets the content and features pull users in and through the conversion process. So far, we've found that user intuition about how to get from Point A to Point B in the purchase process doesn't vary by location - everybody is looking for the same information.

However, we also found that aesthetic preferences, as you might suspect, vary a great deal between nations. The preference in one country might be for ultra-sleek, clean design with little imagery and a neutral color palette. In other places, users seem to prefer a richer, bolder palette full of evocative imagery and depth. Given those widely varied and utterly subjective preferences, we faced a new challenge with our current design project in this space: How do we define a design that not only works but also looks "good" in Germany, in Australia, in France, in the UK, and many other distinctly different parts of the world?

Our first attempt was to employ our standard process of presenting three mood board options and finding the most preferred of the three. In this case, we had the opportunity to ask our users (during usability testing for the same product) what they thought about the mood boards. For this exercise, we came up with three distinct directions. One that was sort of business-y, one that was fun and lively, and one that was neutral. We asked users how they would describe them and which they preferred. After weeks of interviews, we were able to finally discover that the mood board results were totally inconclusive. Each country had a preference, but with 4 countries responding to 3 mood boards, we couldn't possibly have come up with a less definitive answer. Germany preferred one, France preferred another, the UK preferred the third, and in Australia there was no clear winner. Obviously, none of these design concepts was the "right" answer.

Beyond that, even within the countries that preferred a particular design direction, the feedback was contradictory. For example, we presented a mood board similar to the one below.

And, in response to this design concept, we heard the following descriptions:

France: punch, dynamic, warm, friendly, current, pretty, leisure, approachable, summer, modern, nice, ugly, usual, lively, airy, joyful, attractive, organized, hard hitting, welcoming, 1970s, cheap, old

Germany: loud, amateur, warm, white, leisure, friendly, sunny, nice, neutral

UK: bright, golden, distracting, holidays, warm, sun, summery, fun, light, breezy, sunny, inviting, touristy, interesting, striking

Australia: nice, bright, simple, stands out, eye-catching, inviting, warm, summery, fresh, eco-friendly, holiday, beach, mid-range

Our next step was to pull the best elements of each concept while attempting to steer clear of the potential negatives. People everywhere thought the yellow design above was friendly and fun, so we tried to keep that element without making it "distracting" or "amateur" or "1970s." For our other two mood boards, we did the same. The end product is still in development (I'll update with a link here when it goes live), but the key point is that our applied design employs blue, yellow, gray and generous use of white space. We really like it.

Normally, that's where the story would end. But, in this case, our client is responsible for presenting this design to a multitude of stakeholders in all these countries and to help smooth the approval process, they wanted more than a recommendation from our designers. They needed "proof" that this design was the best possible design for our purposes. More specifically, we needed to be able to prove that the color selection of blue, yellow, and gray was the best choice for every country we're working with.

Yes, that's right. My marching orders from the client were "Prove to us that these are the right colors."

It was a fair question given the circumstances; but, on its face, this seemed impossible to answer. What kind of research could I find to prove something so subjective? Skeptical that such an answer existed, I turned to Google Scholar to start digging. I expected to find some general studies that described the emotional impact of certain colors on the subconscious, or maybe a study of the use of colors for branding in certain industries. But. lo and behold, there on the very first page of results was the holy grail of documents: a legimate study about my exact topic with the exact answer to my question. That *never* happens! It was one of the best work days of my life.

Conducted by Irina Kondratova and Ilia Goldfarb of the National Research Council Canada Institute for Information technology, a paper called "Color Your Website: Use of Colors on the Web" had carefully, thoughtfully, and thoroughly analyzed the use of color on web sites across the globe and found some very significant patterns. I recommend you read the published paper yourself to learn about methods and other conclusions, but here's the punchline:

"Results of our color usage analysis for the fifteen countries showed that some colors are commonly and preferentially used across all countries studied. These colors include white, black, all shades of gray, all shades of blue and a light yellow color."

Sweet! What are the odds of that? It turns out the blue, gray and yellow palette we had arrived at was, coincidentally, the only single color palette that the (fairly limited, but perfectly valid) research on the subject has proved acceptable. Going one step further, I also discovered an article from the Proceedings of the 7th International Conference on Electronic Commerce which concluded that among the four most trust-inducing features of interface design is the use of "moderate pastel color with low brightness and cool tone." Even better - our palette was exactly that!

Armed with these facts, I was able to quickly sum up the key points and reiterate with more confidence to the client that not only was our design beautiful, but we could also prove it was the right choice. Of course, the ultimate proof will be in the conversion rates once we launch; but, at this stage of the project, I think the matter has been settled as conclusively as possible.

I didn't write this post just to tell you my fairy tale story of proving the unproveable - I'm curious what other web design professionals think of this whole exchange. Was there a different direction I could have pursued to arrive at an equally presentable conclusion about color? Even if the study I referenced was conducted perfectly, is there any *real* merit to an analysis like this? Or, in the end, is there just nothing more certain than good design intuition?

Confirming Passwords Is Annoying: Is There a Better Way?

2009-03-23T13:00:00Z

The defining characteristic of a password field is that it abstracts text as dots. While the intention of this behavior is understandable (it makes users feel secure and protects from prying eyes), the unintended effect is that it creates a usability problem. Users can't tell if they've entered a password incorrectly until after the site's validation informs them. It's like typing with your eyes closed.

The most common solution for the password field problem on registration pages is to require people to confirm their password in a second field. Again, the intention is understandable (it cuts down on mistakes), but the reality is that sites are requiring people to deal with two password fields. Here's an example of the common solution with some JavaScript validation:

Demo

Password
Confirm Password

While this isn't a terrible experience, I think there are a few other ways to handle this problem worth exploring. With some inspiration from a post on IxDA.org, I've created three below. Of note, all of these proposed solutions load a password field when the page is generated, so the browser will initially treat them as regular password fields.

Solution #1: Users click a checkbox to show characters

Demo

Password
Show characters

Pros: The decision to show or not show characters is fully at the discretion of the user. Passwords can be edited while characters are displayed.

Cons: It doesn't automatically switch back to a password field. People could accidentally keep it checked while they're filling out the rest of the form, leaving the password susceptible to prying eyes.

Solution #2: Users hold down a button to temporarily show characters

Demo

Password

Pros: Users are able to see their password characters if they'd like and cannot accidentally leave the field in the show character state. This solution potentially feels more secure to users than solution #1.

Cons: The downside is that users cannot leave the field in "Show characters" mode while they're editing the field. They can only see what they've entered when the button is pressed down.

Solution #3: The password field automatically changes to show characters

Demo

Password:

Pros: As a user, this approach would be my personal favorite because it's the easiest option, and you always see your password as you're typing it in. I don't really care about other people seeing what I type, since I rarely find myself in situations where I notice or would expect people to leer at my screen.

Cons: When users first select the field and start typing, it will look and behave like a regular text field -- which may be startling to some. Users will not see that it switches to a password field until after they've entered something and clicked off of it.

Conclusion

None of the solutions presented here are the silver bullet for how to handle password fields in all situations. Depending on your users, your goals for the form, and your willingness to try something a little extraordinary, one of these options may make sense for your site. If anyone has any other ideas for how to handle password fields, I'd love to hear about it in the comments.

Update! April 16, 2009

In response to this post, Stephen Lewis from Experience Internet put together a writeup and demo for another alternative to password confirmation. His works very similarly to the iPhone password input field where the last character is momentarily a character before automatically switching to password "bullet".

Embracing the Curve

2009-03-04T16:29:00Z

Note, this post is also posted on Jackson's blog. Read the original post.

As web application designers, we often work to design interfaces to be as simple as possible, focusing on the new, uninitiated user who wouldn’t necessarily be interested in using a sophisticated interface. On the other hand, developers, enterprise, and other experienced users appreciate those sophisticated interfaces for the power they can give to the user.

It’s a common situation to outgrow a web application. You sign up for a tool that appears to be easy to use, and it is. You adopt it as part of your toolkit or workflow, and continue to invest your time and interest into it. Over time, though, you begin to feel the limitations of the simple tool. Maybe you were using Basecamp and are finding that it’s not the best way to task other people on a project. Perhaps you’re getting frustrated by Twitter’s lack of privacy or group options.

As a designer, what’s the right way to go? Do you design the simple interface for the new user, or the sophisticated interface to offer power to the more advanced user? In creating simple web interfaces, we are often designing at the expense of power, and that power can be the key that makes software truly invaluable for users in the long term.

Doing Both

It’s a false dichotomy. Having a simple interface that new visitors are likely to grasp does not mean that more advanced users need to be left out of the picture, and the best web apps understand how to embrace the learning, experience, and usage curves to create a product that is loved by brand new users and experienced ones alike.

To look to the real experts on this topic, we might turn to video games. I’m not a huge gamer myself, but it’s clear that in this age of never-ending MMORPGs, embracing the curve is a necessity rather than a nicety. Consider the two screenshots from World of Warcraft below, one from a new player, and the latter from one more experienced (level 80, whatever that means):

A low-level WoW player has a fairly straight-forward interface. (Credit: Snooze on Flickr)

A high-level WoW player’s interface is significantly busier, but this is appropriate, given the context of use. (Credit: Vyskol on Flickr)

We can find this kind of design on the web, too. Geni, a well-designed genealogy site, has an interface that scales from an incredibly simple initial screen (which also serves as a de-facto signup screen), to a family tree consisting of hundreds of people.

Geni’s welcome page for new users gets you directly into the app in an incredibly simple and compelling way. It feels incredibly simple to make initial nodes.

Even with 300 family members, the interface still works, and provides additional options for viewing the family data in other ways that may be more manageable for you, such as lists and indexes, and a panel to quickly navigate a huge tree at the bottom of the screen.

Method 1: Interface Expansion

One method is to reveal and expose additional options and interface elements to users as they grow accustomed to the app. This is what we see in the World of Warcraft example above: the new user has a relatively straight-forward gaming interface, with just a couple abilities surfaced to the interface. As the player levels up and gains new abilities and tools, the interface increases in complexity.

There are loads of opportunities for this type of expansion on the web. A bookmarking app doesn’t need advanced features for manually organizing your bookmarks until you have a few in the system. Interfaces for adding loads of metadata can be frightening for a new user, so maybe more metadata is requested for more seasoned users.

It’s common for an internal discussion about an interface to have a thread dealing with the fact that a simple interface may be great for managing a dozen items, but breaks down for hundreds of items that may be accumulated over time. Why not switch to the more advanced interface once the user passes that threshold, rather than exposing them to a sophisticated interface right away?

Method 2: Interface Prioritization

Flickr focuses on the photography, but advanced and social options are exposed above the image in a way that is subtle enough to not scare amateur users.

Flickr is a great tool for both amateur point-and-shoot photographers as well as the semi-pro with dozens of lenses for her D300 body. These are two audiences that have wildly different needs when it comes to photo management and editing, and Flickr manages to do a solid job of handling both in a way that doesn’t alienate either group. Not only that, but they enable some nice social features in the process that don’t obscure the art of the photo.

They do this by having an interface that focuses on the simple, but still allows the more sophisticated. Most amateur users will be happy to upload their photos, comment on them, and casually browse sets and the metadata. More advanced users or precocious amateurs will be looking to the relatively subtle toolbar above each photo to organize, edit, share, or view other sizes.

By prioritizing the simple tools for the mass audience and providing subtler entrances for tools built for more advanced users, both can be served quite effectively. Subtlety is the key here, though, since the advanced tools can have an overwhelming effect on beginning users if their interfaces overshadow the simpler interfaces.

Method 3: Graduated Social Influence

It’s of paramount importance in social apps and communities to ensure that the most dedicated users don’t tire, yet often these apps don’t need additional functionality to be enabled for these users. What then?

Instead of thinking of advanced ways to interact, consider advancing a user’s social influence by gradually enabling them to take charge of aspects of the community. Allow them to moderate comments and posts, to recategorize items, to censure abusive users, or to feature content prominently.

General Tips

A few tips for being successful at embracing the curve:

Time is your biggest ally. Because the curve is often a function of time, you don’t need to release advanced features at the same time you release basic features. Instead, bring in more advanced options as your users have begun to get familiar with the basic aspects of the application. This can benefit your project launch date, your initial budget, and the velocity of your development.
It’s not always a two-side issue. Sometimes you need steps between beginner and advanced, especially if advanced is very advanced. Consider handling a steep curve by making it a staircase to the top.
It’s no excuse for editing. Just because you can have more sophisticated tools in an interface doesn’t always mean you should. Continue to balance the needs of simplicity versus flexibility and power and make smart choices in the interests of your users.
This affects interface testing. Yes, this means you can’t just test your advanced features with new random users, since advanced features are surfaced in the context of experience. I’ll write a bit more about how testing doesn’t always reflect the truth later, but make sure you’re testing users within the proper context in order to get relevant results, especially on the more advanced pieces.

A Few User Experiences in Banking

2009-02-25T15:01:00Z

Last December, I visited a financial planner. It was well worth the time and hassle of tracking down recommendations from folks whom I trust. It was enlightening but also daunting -- I had a lot of work ahead of me to get prepared for retirement at 30. (Tsk, and some call me an idealist).

Anyway, among the many great recommendations was to explore investment opportunities available in any of a number of companies. So, I started doing some research and now have intimately experienced the user flow and options available to me behind three major financial institutions, which I refuse to name because I don't want anyone to steal from me.

Here are some observations I've found in my micro-research:

Decision paralysis on the home page is alive and well. One of the companies had no visual or content hierarchy -- it was literally line item after line item of everything I could use them for. This is OK if I'm just scanning for a certain keyword, but it's also anxiety-inducing. Another company had much better visual hierarchy -- for example, there was a question on the home page that asked "New to Investing?" -- but then led me to a landing page with enough choices for a seasoned investor. The conversion funnel could be more effective if I felt a guided experience rather than a free-for-all.

Two of three companies structured their user experiences around their own internal organization. This is amazingly annoying when I want to move money from point A to point B and have to sign into two different interfaces and have confirmations from both. Why on Earth would you require your users to jump through these hoops just because your internal territories are so deep? However, one company did invest obvious love and care into audience research and ease of use, which then made the other two seem even more bureaucratic.

Pop-up explanations are everywhere, but never seem to help. Maybe this is just me, but I don't really need a glossary when trying to manage my banking online. Instead, I need answers to questions that seem nowhere to be found (like, when setting up bill pay for an individual, does the date I choose dictate when the check is cut or when it's delivered?). Or the answers are off on some page beyond my current view, which makes keeping things in context very difficult. But, to remedy this, see the next point:

Live chat works. I feel weird typing this, but it's true. On each of the three companies I was researching, I used the live chat option and found stellar results -- one of which was so pleasurable thanks to friendly customer support that they earned my business. (A follow-up call afterwards gave me the warm fuzzies, too.)

Overall, I was amazed that two of three financial institutions I surveyed are capable of managing millions (billions?) of dollars for people but aren't better equipped to manage their users' experiences intuitively. Maybe I'm expecting too much?

A UX Reading List

2009-02-24T14:19:00Z

Way back in December my colleague Mindy set out her web design goals for 2009 , and included "Continue to improve my understanding of User Experience design" at #4 on her list. We've got a well-stocked UX bookshelf a Viget South, and Mindy's post got me thinking about the books I recommend to people who want to learn more about user experience design, information architecture, usability, and interaction design. I set my own goal of putting together a "UX canon" that I would be able to share. Well, it's nearly March and I've yet to finish my reading list. Thankfully, the design faculty at the School of Visual Arts did me a favor and posted there own interaction design reading recommendations. It's a pretty good list, and has most of the books I had in mind to include in my own reading list. I highly recommend that you check it out, and in the spirit of sharing, I do want to recommend five books that didn't make it onto the SVA list:

The Inmates are Running the Asylum by Alan Cooper — I think you could call this the book where I found religion. Inmates isn't a practical book, but it embodies all of the frustration about interface design that I felt as a Computer Science student in college.

The Human Interface by Jef Raskin — Raskin has a fondness for oddball interface paradigms, but this is another book that is more about the spirit that embues user experience design than the actual practice of the craft. Fun Fact: Raskin's son Aza is now leading UX efforts for Mozilla.

Tog on Interface by Bruce Tognazzini — Bruce "Tog" Tognazzini was part of the legendary design team at Apple during the early years of the Mac OS, and this is an engrossing look at much of the thought and effort that went into crafting many of the fundamental interface elements we now take for granted.

Contextual Design by Hugh Beyer and Karen Holtzblatt — SVA is a design school, so I guess it isn't surprising that they don't have much in the way of design research books. Contextual Design presents the case for ethnographic research methods in UX design.

Information Architecture for the World Wide Web (3rd ed.) by Peter Morville and Lou Rosenfeld — Finally, I want to recommend the classic and definitive Information Architecture for the World Wide Web. Effective organization of information is critical to creating usable designs, especially on the web, and this is the book that formalized IA as a practice.

Let Your “Regulars” Do Your Work

2009-02-19T13:50:00Z

Ok, so I had a great (and effective) marketing tactic used on me this morning. I’m a relatively new coffee/espresso drinker, but I noticed pretty quickly that the barista at this new, non-[major franchise] shop had forgotten the hazelnut syrup I had requested. But, because I still need my sugar fix, I turned around at the end of the parking lot and went back in with the intention of just grabbing a few sugar packets rather than making a fuss. The barista recognized me though, and I felt compelled to mention the oversight. He apologized emphatically and added the syrup; which is really the best I would have hoped for.

The manager, however, overheard the exchange and stepped in to offer me a free sandwich for the error; which, to me, seemed excessive, but an extremely gracious gesture that was good for his up-and-coming business. I protested slightly, but then he hooked me by saying, “Really, it’s fine – you’re a regular.” Now, I’ve only been in this shop four times (granted, three of them were this week), so I’m hardly a “regular.” But, by calling me one, I now felt pressured to actually BE one. On top of that, I was quick to mention the experience to the first person I ran into this morning. I’m spreading the word.

Here at Viget, we strive every day to not just get people to our clients’ sites, but to make them “regulars” on those sites. We propose marketing and social strategies, blogs, content revisions, and design updates to grab people, draw them in, and, hopefully, keep them coming back for more. But, in a fickle, ever-changing online world, how can we ensure that we’re connecting with our core audience? We’ve written before about ways in which customer service and brand personality effect online experiences, but allow me to add another case study to the list.

The Lefsetz Letter focuses largely on the music industry; but, in a post this week, Bob Lefsetz recounts an experience he had with one of my personal favorite e-commerce sites for outdoor gear.

I immediately received an e-mail confirmation that said "Get stoked - most items ship within 24 hours." That’s how they talk on the hill. But most e-commerce sites use the traditional phrases, vetted by attorneys to avoid any and all lawsuits. These companies are not run by humans, but computers. Just try to complain when you’ve got a problem. And then, three hours later, came another e-mail. With the above quote. Yes, "Holy crap. Your stuff just shipped." Wasn’t I supposed to wait ten days for them to make money on my money? They ship within twenty four hours? But what truly sold me was the irreverence. Real people work at Tramdock.com. Or at least real people wrote the computer scripts.

And those are the keys. Mr. Lefsetz was not only able to make that connection between the company that was trying to make money from him and the people who are actually behind that company, but they exceeded his expectations as well. So with a necessary focus on keywords and SEO to get people to our sites, how do we bridge the gap between marketing and personality in order to keep them there?

Bob closed with this:

Play to your core. If you deserve to be bigger, your fans will spread the word. And don’t be afraid of offending those not in the loop. They don’t matter.

In the end, he “gets” what I “get” about this site. Backcountry gear isn’t for everyone, so why try to speak to everyone? Find a voice that speaks to your core audience, exceed their expectations, and your “regulars” will do the work for you.

Easy enough, right?

Customer Service With a Smile (For Real)

2008-12-24T14:33:00Z

As somewhat related to my post about how offline experiences can influence those online, I'm going to dish a bit about customer service. We work with clients who have products or services that potential customers (understandably) want to explore more holistically before choosing, so we may suggest their linking to/exploring the places where chatter about them might already exist -- like GetSatisfaction or Rate-it-All -- to help promote acceptance through transparency. And, on the flip side, it has the potential for companies to learn and grow based on the honest feedback being exchanged out there.

Southwest Airlines has been an early adopter of social marketing strategies, using Twitter and blogging religiously, and continues to forge itself as a rather personable airline that strives for that transparency. I have been flying it whenever possible -- or, at least since Independence Air folded, sniff sniff -- for a great combination of low fares and friendly staffers. Twice now I've been on flights where an employee has sung to us. And, last night, after being diverted BACK to Baltimore having being told not to land on Cleveland's ice-covered runway (good idea), the ground staff re-fueled the plane and then hopped onboard to announce, "I hope we don't see you here again tonight. No offense."

None taken.

Well, we didn't see Baltimore again, but we didn't see Cleveland, either.

Our second attempt to land in Cleveland from Baltimore was diverted at 2 am (original landing time was supposed to be 9:20 pm) from the turbulent skies near Lake Erie to the calmer clouds of Columbus, Ohio. My plans, like everyone's around me, went from being inconveniently delayed to officially busted. When I learned that the only flight to Cleveland wasn't until 11 the following morning, I decided against waiting behind about 50 people in line at the customer service counter and, instead, found a nearby hotel to sleep off the tough travel experience and hope Southwest's customer service would be fair when I called the next day.

With so many companies promising great service and quality products outwardly online, only to then seem terse and unhelpful -- or non-existent -- when problems arise, I feared the worst. I really didn't want to have to stop flying Southwest. Lucky for me, I don't. When I called their customer service number, a human IMMEDIATELY picked up the phone and greeted me pleasantly, but not in an overly perky way that could potentially annoy an angry customer. She quietly listened to my saga, apologized for my less-than-stellar experience, and asked to put me on hold briefly before returning moments later with news of a flight refund in the form of a voucher good for one year. This is probably pretty standard, and it definitely covers the cost of my hotel room with ease, but potentially more important to me was the empathy I perceived from her and the speed to which she addressed my situation. Whether it was just this particular representative, or (as I suspect) was organizationally driven, talking to someone who seemed open to helping me made me proud to be a loyal customer.

Southwest's rather bare-bones website isn't impressive, but it gets me booked easily into a seat so I can see their happy staffers and no-fee policies for myself. Coupled with their social media participation online and responsive customer service offline, I'd argue that their end-to-end strategy is the definition of attentive and cyclical.

The entire call lasted five minutes, but my business will last much longer.

(But here's to a return flight this weekend that proves less dramatic!)

Creating a Feedback Loop for Users

2008-12-22T18:12:00Z

Over the last few months, I've worked on several projects that started with good, solid user research efforts. We've sent out surveys, performed interviews, run usability tests, and worked with customer support teams. It's exciting to start a design project with good input from users, but the research we've been doing made me realize how often we have to work without the benefit of good user insights. This got me looking around at tools that companies can use to get started on gaining insight into their user's needs. I found two that looked particularly useful, and easy to use: Get Satisfaction and UserVoice.

Get Satisfaction

Get Satisfaction is a hosted service that provides companies with a forum for customers to post complaints, suggest and rate new ideas, help each other, and communicate with employees. It's simple enough to get up and running, in fact you may find that your customers have already done the job for you. Get Satisfaction is primarily a customer service tool, but if customer service is the new marketing, it's also a fundamental piece of a good user experience.

Get Satisfaction provides a number of tools companies can use to identify key user needs and pain points:

Users post and rate problems with your products
Users suggest new features and vote for their favorites
Users share their tips and tricks with each other

Get Satisfaction isn't alone, if these features sound useful, you can also check out:

UserVoice

Dell and Starbucks both received a lot of attention when they launched services specifically for giving customers a voice in developing their products via the Dell IdeaStorm and My Starbucks Idea websites respectively. Fortunately, UserVoice provides companies with the ability to create their own site modeled after Dell and Starbucks.

UserVoice doesn't provide as many tools as Get Satisfaction, but it does a better job of letting users provide insight into the improvements they want most:

Usrs can suggest new features and improvements
Users can vote for their favorite new ideas
The company can indicate which ideas they like, and which they don't

One of the most powerful features is the ability to mark ideas as "accepted" or "completed". This gives your customers a view into the ideas you like best, and which one's you've committed to implementing.

If you like UserVoice, but are looking for simpler, or free solution, check out FeatureList. If you know your way around a text editor, and would like to host your own solution, an open-source Digg clone like Pligg cound easily be turned into a UserVoice-like tool.

Making Good Use of Input

Regardless of the tools that you're using to connect with your customers, it's important to remember that they shouldn't be the only way site improvements are prioritized. Research and practice have made it pretty clear that users put their short term pains ahead of long term rewards, our job is to counter-act this tendency while taking their needs into account. Serendipitously, I ran across a great post by Tim Sabat on Particletree, "On Prioritizing Feature Development," that discusses just this problem. Tim's post is a reality check, reminding us of two classic usability maxims:

Build what people need, not what they want
Pay attention to what the user does, not what he says

We can't forget either of these when we engage users directly. One solution would be to use user input as part of an affinity diagramming exercise, such as the KJ technique.

In the end, I believe that utilizing tools like Get Satisfaction and UserVoice are great first steps in directly engaging users in design and product development. For companies, they can serve as a low-cost first step towards more in-depth research methods and tools. For users, they provide transparency and empowerment. My hope is that these tools can help build a sense of community ownership and participation in the design process.

Other Tools

Several forum tools have plugins that can add Q&A and user voting functionality, if you're more interested in hosting your own tools:

vBulletin with project management tools
phpBB with the Topic Solved and Voting-based Moderation add-ons
Drupal with the Answers and Voting add-ons

Google Gives Back - Services and Grants for Nonprofits

2008-12-05T18:01:00Z

Aside from its standard bevy of free tools and services, Google has several grants and premium services available to nonprofits:

1) Google AdWords Grants

Certain nonprofits are eligible for free pay-per-click (PPC) advertising through Google AdWords (up to $10,000/month). Organizations are able to target keywords and craft appropriate ads within Google's guidelines.

Ads are each given a cost-per-click (CPC) value of $1, so they're not going to rise to the top as often for common keywords that others may spend more money on. Once you get a grant, it's important to carefully select and monitor your keywords to make sure they will actually show up on relevant searches within your niche.

The grant amount will vary based on how much you are able to use in a given month. The monthly cap is $10,000, but because you only spend $1 if your ad is shown AND someone clicks on it, it's rare that you'll actually be able to spend the full amount in a given month. Still, you'll be able to tweak your campaigns and keywords at any time to try to maximize your grant.

Check your eligibility - Basically, you should be a nonprofit organization that is not political, fee-based, or religious. Organizations in several countries are eligible.
Apply for the grant

2) Google Checkout

Google Checkout offers a way to process donations to your organization for free. There is no monthly fee, and they are still not charging a credit card transaction fee! They say this will hold true until 2009, but I vaguely recall that they once said "until 2008," so maybe this benefit will last a little longer...Because you need a Non-Profit Tax ID number to apply, I assume that this is only offered to organizations in the US.

3) Google Apps (for Email)

When you sign up for Google Apps, you can use Gmail for your email service (instead of a paid Exchange server or the like) while keeping your organization's domain as your email address. You will still be able to use your desktop email program (ie. Outlook) to pull email from that account so that you can manage your email as you always did. You can also migrate existing emails into the new Google account.

Google Apps is free for everyone, but nonprofits are allowed to sign up for the Education Edition, which means that you can actually contact Google for help - a service normally reserved for Premier (paid) users. You are also able to use additional email migration tools such as IMAP or the Migration API. As far as I can tell, the only requirement here is that you are a nonprofit.

4) YouTube

YouTube for nonprofits is just like regular YouTube except that you get a listing in their nonprofits section and can accept donations (through Google Checkout) directly from your channel. There are similar eligibility requirements for this program as for the Google AdWords Grants, but it's currently only available to organizations in the US or the UK.

Learn more and apply

5) Google Geo Challenge and Google Earth Grants

Think there may be a way to use Google Earth to promote your cause? Google is offering grants for these projects right now. The application deadline for the current round of Geo Challenge grants is Dec 22, 2008, but it sounds like they intend to have more rounds in the future. As a nonprofit, you may also be eligible for a Google Earth Pro license (compare features with the free version here) .

Obviously, there are plenty of other free Google services and tools you can be taking advantage of (Analytics, Feedburner, Calendar, Docs, Groups, etc.). Here, I mostly just wanted to point out some of the extra benefits that you may be able to apply for as a nonprofit. Am I missing any that you're aware of? If so, please leave a note.

Viget Advance : The Strategy Lab

Waxing Speculative about Amazon’s Business Model

Sustainability

Competition

Amazon Stores

The Shackles of Simplicity

Occam's Razor

Understanding Complexity

Embracing Focus

Managing Complexity

Geo: Soon to be Legit

Managing Wireframes More Effectively in OmniGraffle

Demo Video

Creating the Wireframe

Creating the Document

No More Fear of Heights

Testing Web Text Readability

Sketching in the Kickoff Meeting

Do Try This at Home

No Silver Bullet

Credits

The Line Length Misconception

The Research

Guesswork

Best Practices

Prototyping with Production Purposes in Mind

The Scenario

The Benefits

The Challenges

For Future Consideration

And Yourself?

An Open Letter to Third-Party Twitter App Founders

IA Summit 2009

Sketchboards & Prototypes

Michael Wesch

Digital Space & The Context Problem

Speaking the Language of Business

Designing Rules

Experience Themes

Is Interaction Necessary?

Strategies for Enabling UX to Play a More Strategic Role

Revealing Design Treasures from the Amazon

Leading With Insight

Designing Social Interfaces

Links

‘Tis the (Tax) Season

The Bad

The Not-So-Bad

Biases in Effect

Sure, Those Colors Look Nice - But Can You Prove They’ll Work?

Confirming Passwords Is Annoying: Is There a Better Way?

Demo

Solution #1: Users click a checkbox to show characters

Demo

Solution #2: Users hold down a button to temporarily show characters

Demo

Solution #3: The password field automatically changes to show characters

Demo

Conclusion

Update! April 16, 2009

Embracing the Curve

Doing Both

Method 1: Interface Expansion

Method 2: Interface Prioritization

Method 3: Graduated Social Influence

General Tips

A Few User Experiences in Banking

A UX Reading List

Let Your “Regulars” Do Your Work

Customer Service With a Smile (For Real)

Creating a Feedback Loop for Users

Get Satisfaction

UserVoice

Making Good Use of Input

Further Reading:

Other Tools

Google Gives Back - Services and Grants for Nonprofits

1) Google AdWords Grants

2) Google Checkout

3) Google Apps (for Email)