Viget Advance : The Strategy Lab

Five Major Identity Schemes, and How to Decide

2009-11-04T15:03:00Z

Almost any site that has user-generated content has an identity system in place. Choosing that identity system is one of the first decisions made by any product team, though most seem to punt on it and go with the standard option of allowing users to create a username or screen name of sorts. There are other options, though, and this choice can have a pretty substantial impact on not only the functionality of the site, but also on the character of the community that gathers there. Here are five primary options, with some examples of sites in the wild that use them, followed by a few ideas on how to choose.

The Default: Pseudonyms

The vast majority of sites are based on a pseudonymous identity system, where users choose a name by which they'll be known on the site. For example, on most sites where I register, by pseudonym is 'whafro,' and has been for nearly twenty years now. It's not anonymous, per se, because actions are attributable to someone in particular, though their genuine identity may not be known.

Wide Open: Anonymous

Far fewer sites provide an anonymous system, where there isn't any identity attributed to a user, real or fictional. Craigslist's anonymize option is probably the most noteworthy example of this type in the wild, and it's a double-edged sword for them. On one hand, people take advantage of the anonymity to use the service in ways they probably wouldn't otherwise, and it's led to a very healthy site. However, the site can come across as being sketchy, especially when it's used to commit a crime, and that likely keeps away many folks who may otherwise use the site.

Of course, the question of whether or not any user is ever truly anonymous is a different one. Often, these sites maintain logs of IP addresses or other information that could be used to identify a user in the event of criminal activity or something like that.

The Truth: Abstracted Names

Yelp uses what I call an abstracted identity model. Users are generally represented using their first names with a last initial, like 'Jackson W.' This creates the feeling that you're interacting with real people, while still providing a healthy amount of distance between your actual identity. Especially for a site centered on local reviews like Yelp, this model can help establish authenticity while not scaring folks away.

Sure, there probably isn't more than one Jackson W. in Falls Church, Virginia, but it's at least abstracted away a step or two from being my complete identity. In fact, a quick Google search for those terms doesn't really yield much of value.

The Whole Truth: Real Names

While it wasn't initially the case, Facebook now places a lot of emphasis on the use of real names throughout their service, making it a required part of their terms of use. For a while, this wasn't the case, and I had friends with names like "Mother Superior" and "Jaaaaaaaaybo," but they've all been kicked into line by now. Even people who change their names more than once may find their accounts locked -- so if you change your name when you get married, don't divorce ;)

This makes complete sense for a network where the emphasis is on interacting with people you actually know. Unlike many topical social networks, Facebook really doesn't have many great avenues for meeting people you don't know, and everything is tailored to help you find keep up with those you actually have met offline. Offline, people generally interact with each other using their real names, so Facebook tries to mimic this as much as possible.

Nothing But the Truth: Genuine Identities

While Facebook emphasizes the use of real names, they aren't checking IDs or anything during the sign-up process to ensure that the name you've given them is genuinely your name. Yes, that means that you could sign up for an account as M. Jackson Wilkinson and pretend that you're me -- not that there's anything remotely interesting about doing so. Other services are beginning to experiment with taking the next step and actually verifying that the assumed identity is in fact genuine.

Twitter has started verifying accounts for well-known people -- think Shaq and Ashton Kutcher -- through their Twitter Verified program. For accounts that have a history of impersonation, Twitter staff gets in contact with the account holder and verifies that it does indeed represent the person it claims to. It then places a badge in a specific spot on the profile that advertise this verification so others can have confidence that it's a legit source. Now that news agencies are actually using Twitter as a real source for news, this has become increasingly important.

Amazon has a similar process for its members, using it most often in the context of reviews. When a reviewer's name appears alongside a Real Name badge, that verifies that the name given is the same name as on the user's credit card. In this case, it's used to give users confidence in the reviews posted by these members, showing that a real person is standing behind the opinion given, rather than an anonymous coward throwing tomatoes.

Choosing the Right Combination

Of course, your product need not commit to only one of these systems. Slashdot allows for anonymous comments, posted as "Anonymous Coward" and rated down by default, while letting logged-in users post with their pseudonyms without the anonymous penalty. On SpeakerRate, one of our products here at Viget, we use pseudonyms by default, and allow users to validate their accounts against a LinkedIn profile, in which case we use their real names as defined by LinkedIn.

The key to choosing a system is balancing the needs for the contributor's privacy against the skepticism of the consumers. In Yelp's case, a pseudonymous identity system might lead some to think that many reviews of local restaurants are being posted by the restaurant staff itself. That might still be the case, but at least it's discouraged by the emphasis on abstracted real names. In Facebook's case, privacy in terms of identity isn't really necessary for people who are supposed to know each other anyway. For a forum dealing with sensitive topics like disgruntled workers, relationships, or medical issues, anonymity might be crucial to creating a safe haven for people to share their thoughts.

In the end, it's important not to gloss over the identity system. As easy as it is to create a typical signup and login process based on pseudonyms, it could be a major roadblock in the way of building a community that can grow organically. It's one of the first, and most important, elements of your product's user experience.

Closing the feedback loop with a little help from your friends

2009-09-03T14:00:00Z

I was at the Agile 2009 conference last week to give a talk based on a project we did with Choice Hotels, this is the short version of my presentation. A quick thanks to everyone who came to my talk at the conference, and to everyone who provided feedback afterwards!

View on Slideshare

I like to think that most designers accept that integrating user feedback is critical to the success of a project. I also like to think that I’m not alone in struggling to find time and budget to undertake a thorough research phase on every project. As a group, UX designers have found a lot of ways do design research quickly (and cheaply) in order to make the best use of the time they have available on a project. On a recent project we found just such a solution that allowed us to gain critical insights while overcoming hurdles that made doing user research difficult.

Marketing Saves The Day

We were working on a re-design of web presence for Choice Europe and Choice Australia, and wanted to incorporate user feedback based on our previous design work for Choice Scandinavia and Choice Canada. We were able to produce a prototype site for use in usability testing, but quickly ran into some problems:

We didn’t speak German, French, or Spanish
We didn’t have budget for travel
We would have to work around significant time differences

We worked around the problem by partnering with Choice’s local marketing teams. These teams were local, had the language skills we lacked, and were more aware of local customs than we were. We provided training in remote usability methods, and working together we were able to complete almost 50 usability tests in 4 countries.

The test results gathered by the Choice marketing teams provided critical insights that we used during the design process, and provided a means for the Choice teams to get involved directly in that process.

The Fourth Way

Generally, there are three ways to gain insight into customer needs:

Talking to customers
Thinking like a customer
Thinking like yourself

The higher you are on the scale, the higher the quality of the feedback and insight you can gather. The problem is that we rarely have time for #1, and that we spend too much time using #2 and #3, relying on our ability to think like our customers for insight. What we realized was that we could add a fourth option by taking advantage of the fact that Choice already had teams who were interacting with customers.

Integrating Collaborative Research

If you think about it, there are lots of groups within any company that:

Already talk to users or have access to users
Are already working to help users
Have an interest in getting feedback directly from users

So the challenge for every agile product team is to connect with those groups, and partner with them on research activities in order to get insight into customer needs and get timely customer feedback on their work. The process for doing so isn’t all that different from the approach we normally take to design research:

We identify our information needs
We create a research plan
We recruit participants
We do the research
We analyze the results

It’s in recruiting and undertaking the research that we find ready opportunities to collaborate. In order to do so, we need to create a good research plan. One of the challenges we’ll face is that the UX team has the knowledge and skills to do research, but someone else has the time and opportunity to do the research. As a result, we’ll need to share our expertise via the research plan (and a testing script) and via training.

Plan to spend time training your partner based on the methods you’re going to use, and make sure to practice. You should be doing practice runs anyways, but it becomes even more useful to do so when the researchers are inexperienced.

Once both teams understand the research plan, and are comfortable with the methods, then we can start to make use our combined efforts. Of course, how we do so will be dependent on who we’re working with.

Finding Allies

So how do we find groups in our organization that we can partner with? We’ve identified three criteria that can help you:

Access: Who in your organization has access to contact information for your customers, or better yet, who in your organization is already talking to customers directly?
Mutual Interest: Looking at the research questions you have, is there anyone else in the organization that would benefit from this information? Think about your project stakeholders, who will benefit if you can better meet your project goals?
Complementary Skills: Are there teams within your organization that already have day-to-day tasks that can be leveraged as research methods?

Which groups fit these criteria will differ between organizations, but we can identify broad groups that frequently match at least one:

Marketing: Marketing may have access to existing users via mailing lists and other customer data, and share an interest in gathering insight into customer needs.
Customer Service: Not only does your customer service team already talk directly to users, they have a vested interest in removing barriers to customer success in your product.
Community Teams: Like customer service, they talk directly to users, and can help identify individuals who might be well suited to a particular research project.

Once we’ve identified our research partners, we can look for appropriate ways to split up the work that needs to be done. It may be that they take over all recruiting and research activities, or one team can do the recruiting while the other does the research. Regardless, one last challenge will be getting good results.

To make sure we do get good results, everyone needs to have some understanding of what good results look like, and how to capture them. This could be audio, video, or screen recordings, it could be observations on sticky notes, or structured results forms. This is just one more reason to practice.

Does It Work?

We got great results when we put this approach into practice with Choice Hotels, but there are limits to its effectiveness. Most importantly, you’re faced with reduced control over the feedback you’re getting. You’re relying on researchers with limited training, and as a result they’ll need help from you to gather information effectively. Similarly, you’ll need to take into account your partners’ strengths and weaknesses in creating your research plan. To make this approach most effective, it will help to make it a regular part of your research efforts. This will give everyone a chance to gain experience with the research methods and data collection. Thankfully, making research a habit not only improves the results you get, but also creates a more efficient channel for getting user feedback, and can even change the way your organization approaches product development.

Customer Centric Organizations

Jared Spool likes to talk about the three things that define an customer-centric organization:

Vision: Everyone needs to have a shared vision for the future
Feedback: You need to watch your customers use yours or a competitors product at least once every six weeks
Culture: The company needs to embrace failure as a learning tool

By working together with groups outside of the UX team on customer research — by directly exposing these groups to direct customer feedback — you’re directly contributing to making your organization more customer centric. I think this point alone makes this collaborative approach to research worth considering.

Agile 2009

2009-09-02T17:49:00Z

First, a sad fact:

Trips I've made to Chicago: 2
Trips I've made to Chiacgo where I eat Chicago-style pizza: 0

I’m hoping to make a third trip to rectify this injustice, but in the mean time, I wanted to share my experiences this past week at the Agile 2009 conference in Chicago. I had a good time, learned a lot, met some great people, and joined in with 1300 other geeks in cursing the lack of both cell coverage and wifi.

Keynote: Alistair Cockburn

I missed the first day of the conference, so my trip kicked off with Alistair Cockburn’s keynote on Tuesday. Alistair made quite an entrance with a bagpiper, and kicked off his talk with a recitation of Mark Antony’s funeral speech from Shakespeare’s Julius Caesar. He started with the assertion that Agile practices are now not only mainstream but are becoming the default practice for many. As a result, it’s more interesting to look at new and emerging practices than it is to dwell on the “core” ideas in Agile. He identified four emerging practices:

Software development as craft
Software development as a cooperative game
The use of lean processes (from manufacturing)
Design as knowledge acquisition

Craft: Alan Cooper also talks about software as “craft,” but I’m not sure I understand what he or Alistair mean by this. I think it means that software development has come to be seen as low-skill, assembly-line process, rather than a creative one. As a result, we need to re-focus on developing skills and techniques, and then developing our ability to synthesize and create new skills and techniques.

Cooperative Game: Software development can be seen as a cooperative game, where teamwork, good communications, and good strategies are required in order to achieve the goal of the game. However, not all software projects have the same rules, so a good part of a project consists of learning the rules. Furthermore, not all games are goal directed. Some are open-ended (IT systems development), and some are infinite (product line management). Recognizing which kind of game you’re playing can help you identify the appropriate strategies to employ.

Lean Processes: Agile process geeks have been paying close attention to the manufacturing process management methodologies like Kanban for inspiration for evolving Agile practice. These methods emphasize continuous flow through a development team in order to prevent blocking progress or creating bottlenecks.

Design: In a later talk, Jeff Patton said that Agile and UX have two different ideas on what “design” means. In UX it means figuring out what to build, in Agile it means figuring out how to build. I’m not sure which meaning Alistair was using here, but the message I got was that we need to optimize risk reduction vs. creating value.

The Big Picture & The Glass Wall

I went to two talks on creating product vision; Desiree Sy from Autodesk talked about the importance of a “big picture” for an Agile process, and Matt Roadnight and Una Walsh talked about a specific method they call the “Glass Wall.”

Desiree Sy: Doing experience design within an Agile team can lead to overemphasis on tactical design decisions, without regard for creating a cohesive design. We don’t want to get bogged down in big design, but Desiree made the point that big design and the big picture aren’t the same thing. We can create the big picture without a lot of upfront work. This happens at three levels: Product, Release, and the Sprint (Iteration).

At the product level we create a vision by answering two questions: who it’s for, and what it is. We can also create high-level principles that define the characteristics we want for the product. These vision statements and principles can be used to guide prioritization and acceptance of features in the product backlog. At the release level we focus on specific business goals. These goals help us select and re-prioritize features from the product backlog into a set of features for a given release. At the iteration level we focus on creating a definition of “done” for each story that aligns with our release and product visions.

Matt Roadnight & Una Walsh: The “Glass Wall” is a product vision documented in an experience map, showing touch points between the user(s) and the product. By incorporating information about the user, including their environment and emotional state, we can map out a narrative of the interaction that can identify areas for improvement and innovation.

The map starts with the users needs, goals, aspirations, and concerns. In essence, we’re building a persona, so we also want to add in some details to make this user real. Obviously, this is best when based on research. The next step is to tell this person’s story as it relates to the product. We start with the challenges the user faces in trying to achieve their goals. Each of these challenges is a story that we can map out, but we can only focus on one at a time. In our exercise, we focused on a grocery store, so we mapped out a day in the life of a suburban working mom. We then mapped out her emotional state at each moment in her day. On top of this we mapped out the touchpoints between our user and the grocery store — everything from making a grocery list, to cooking, to the actual shopping. Once we had the story mapped out we looked for places where we could better connect to our user, where we could make her day easier, and where we could improve the quality of the interaction.

Each of these connections basically becomes an opportunity to explore possible features and product ideas. In the end, the idea is to pick out the key features and ideas and create an experience map that defines the brand interaction for our product.

5 Users Every Friday

Tom Illmensee described his experience augmenting an Agile practice with user research by bringing in 5 users every Friday for testing. His team scheduled the users up-front, rather than on a week-by-week basis, in order to remove recruiting as a bottleneck, then figured out what to test based on the features they were implementing each week. The goal was to make testing part of their team culture, so they invited team members to each test as observers, and included the team in analyzing results. The practice removed testing as a bottleneck, but the planning and analysis (in addition to the design work) each week led to a good deal of fatigue.

I was really happy Tom shared his experience with this approach, since it seems like a great solution for Agile teams looking to make user feedback part of their organizational culture. I also appreciated that he was frank about the challenges they faced.

The State of Agile UX

Jeff Patton gave an overview of 12 emerging practices in Agile UX —

UX as part of the product owner team
Research, model, design up-front, but only just enough
Chunking the design work
Using parallel tracks for UX and development
Buying time with complex dev tasks
Cultivating a pool of users for continuous feedback
Schedule continuous user research
Leverage time with users for multiple activities
Use the RITE method
Prototype in low fidelity
Treat the prototype as the specification
Designers learning development skills
Becoming a design facilitator

While I feel many of these are well established patterns rather than “emerging” practices — at least I hope they’re not new to too many people — Jeff’s talk was a great way to recap many of the themes from the UX stage over the course of the conference.

Innovation Games

Lane Halley and Luke Hohmann led us through an introduction to “Innovation Games.” While some of the games were less game-like than I was expecting, many were similar in approach to techniques I think of as “experience mapping,” using various facets (time, usage, location, etc.) to map out how users interact with products. The goal is to gain insight into customers needs, and identify areas for innovation. I enjoyed trying a game for myself, and see a lot of overlap with Una & Matt’s “Glass Wall” approach and techniques such as collaborative sketching for facilitating both strategic and tactical design discussions.

An Agile UX Adoption Story

Lily Cho led us through the story of Liquidnet’s adoption of Agile during the re-design of their core product. Lily’s story was interesting because they switched to Agile after they had already completed an 8-month research phase, which provided their design team with a great deal of background research to draw on during the actual design and development process. The lessons her team learned —

Be prepared for changes in role (they went from owners of the spec to facilitators)
Leverage familiar practices and tools (don’t throw everything out all at once)
Process change needs to happen iteratively
Integrate agile process into parallel tracks
Increase transparency by sharing parallel sprint activities
Upfront research to inform later design
UX is not just a discipline within the project

The last point in particular resonated with me. It isn’t just the UX role that owns the quality of the product experience, it’s the entire team. I’m starting to worry that using “UX Designer” as the name of a role within a product team gives everyone else an excuse to abrogate their role in creating a good experience for the customer.

LiveAid

One of the more ambitious sessions at the conference was a 3-day interactive design and development sprint to build an iPhone-optimized website for the Mano-a-Mano charity. The UX and front-end efforts were led by Todd Zaki Warfel, Joe Sokohl, and Jonathan Knoll (aka Yoni), who led participants through a brainstorming and collaborative sketching workshop based on research they’d done before the conference. Joined by a team of developers, they produced a website that raised over $4000 dollars over the course of the closing banquet.

I was an observer more than a participant, but it was both inspiring and tiring to watch the team design, develop, and launch the site in three days.

Keynote: Jared Spool

Watching Jared Spool is always great fun, and even more so when he’s got a ballroom full of developers rolling in the aisles after his (brief) rendition of Beyonce’s “Single Ladies” dance. Rather than recap the entire talk, which will hopefully be made available online, I want to emphasize a point I’ve heard Jared make before. In order for a company to produce a great product, three things need to happen:

Everyone needs to have a shared vision for the future
You need to watch your customers use your or a competitors product at least once every six weeks
The company needs to embrace failure as a learning tool

Future Reading

Outside of the sessions, I came away with a list of things to read up on. After the keynote, I’ve got Kanban and Lean Development on my reading list. Two sessions I missed out on, but I wish I’d attended were on Story Planning from Jeff Patton and Blitz Planning with Alistair Cockburn. Finally, I’ve got the book Influencer by Kerry Patterson in my notes, but no idea where I heard of it.

Final Thoughts

Agile was an interesting experience for me, in part because I’m doing less work on Agile teams, but also because it was the first non-UX conference I’ve been to in a while. We talk a lot about collaboration in the UX world, but I saw more people working together at Agile than I’ve ever seen at a UX conference. There was an “OpenJam” area available to anyone who wanted to work together, chat after a talk, or even hold an impromptu session. At the end of the week the walls were covered in butcher paper, markers and tape were everywhere, and it was clear that this area had been put to good use. Similarly, the sessions I participated in were more interactive than any I’d attended at a UX conference.

Overall I’m glad I made the trip to Agile, but I learned a few things to keep in mind if I go back. First, I’d hit up more talks outside the UX stage. If I’m not making the effort to learn more about Agile process outside of my role, I can’t expect others to check out the UX talks. Second, I’d look for more opportunities to discuss Agile UX with other practitioners. The UX talks were interesting, but didn’t really give us a chance to have a conversation about our experiences.

Designing for Politeness

2009-08-13T12:30:00Z

“If we want users to like our software we should design it to behave like a likeable person: respectful, generous and helpful.” — Alan Cooper, “The Inmates Are Running the Asylum”

A few years ago a grad school friend asked me to come in and speak to his class about interaction design. The class was 50 minutes long, and I could take as little or as much time as I wanted. I prepared some brief notes, 30-40 minutes worth, and figured the rest would be taken up by discussion. I got up in front of the class, and promptly used up all of my material in under 10 minutes. I was mortified. In desperation I pulled up some wireframes for a project I was working on, and started listing off the changes we’d made and the rationale behind them. The class was bored to tears.

As I talked through the changes something clicked in my head, and told the class that “a UI is a conversation between the system and the user.” I started pointing out how the old UI was cold and aloof, full of empty form fields and imperious demands on the user. The new UI ditched the jargon, embraced a more conversational tone, tried to make the outcome of every action transparent, and gradually engaged the user over time.

While I crashed and burned with that class, I’ve continually come back to the idea of interaction design as creating a conversation. The nucleus of this idea was “The Media Equation,” a book by Byron Reeves and Clifford Nass that examines the human tendency to treat technology just as people. Reeves & Nass make some pretty strong claims, but I have faith in the core of their argument; even though we know technology isn’t human, we still interact with it as we would in any social interaction.

If we think about what it means to communicate effectively, we see that a lot of the same rules apply to designing interactions: don’t interrupt, don’t raise your voice, listens attentively, work towards a common understanding. We see this reflected in many of the heuristics and design principles we use on a daily basis. Alan Cooper expanded on this idea in “The Inmates Are Running the Asylum,” in the concept of “polite software” [1] —

Polite software:

Is interested in me
Is deferential
Is forthcoming
Has common sense
Anticipates my needs
Is responsive
Is taciturn about its personal problems
Is well informed
Is perceptive
Is self-confidant
Stays focused
Is fudgable
Gives instant gratification
Is trustworthy

We talk a lot these days about designing for social interaction on the web, supporting new ways for people to interact with each other online, but we can’t forget that many of those same rules apply to the interactions between people and technology. Christian Crumlish and Erin Malone recognized this in their work on principles for social experience design —

Talk Like a Person… Revealing the humanity of the people at the other end of the wire has a softening and welcoming effect.

Play Well with Others… [W]e’ve found that the more you can build your app upon the rock of proven, well implemented, open standards and technologies, the easier it is to participate fully in the social potential of the web and the always-on digital environment we now live in.

Politeness is far from the only critical factor in good interaction design, but I’ve found it to be an incredibly useful guiding principle both in my day-to-day work and a useful metaphor in describing the goal of interaction design as a practice.

Leisa Reichelt has a nice summary in her 2008 Web 2.0 Expo workshop slides

Breaking Down the Process: TapMetrics.com

2009-08-11T17:55:00Z

Having the opportunity to refine an idea or concept into a solid and successful product is one of the things I love most about my profession. Here at Viget, we often do just that, on a foundational level, with our start-up clients. Working with the founders of TapMetrics was no exception.

TapMetrics is a tool that consolidates iPhone application sales data, user feedback, software metrics, and other information to allow both business development folks and developers to manage a portfolio of applications. The fellas at TapMetrics, working within a limited timeline and budget, decided to focus our team's efforts on refining their tool's existing information architecture and alpha interface. With that in mind, Kevin and I worked toward an end goal of delivering fairly high fidelity wirefames for some of the tool's core views. The plan was to let TapMetrics' business owners and their team of keen developers take the details from these and run with them, then refine the design after implementation.

Getting Started

Diving into TapMetrics was a fun process. We started with a great brainstorming and research session with Nolan and Chris. Our conversation centered around their hopes, as business owners, for TapMetrics as well as the praise, gripes, and wishes their alpha testers had voiced while using the tool. A good majority of the feedback concerned the following:

All available information for a particular iPhone application should be centralized and presented in a unified way.
An application's analytics, messages and alerts should be communicated effectively and appropriately, based on their context.
The process of managing, importing and exporting an application's information should be straightforward and as streamlined as possible.
iPhone application information should be leveraged for insight into application management and strategy over time.

From there, we wrapped our heads around all of the data TapMetrics can gather and leverage from the iTunes Store and took a peek into the application's current interface with some general usability heuristics and the above list in mind.

After taking stock of things, we created wireframes that represented an account owner's Dashboard View and an Individual iPhone Application View. In these wireframes we addressed the following:

Managing Applications

We wanted application owners to have access to all their business and technical information in one place. Our design for the application hub brings it all together, with a front-page focus on what's currently happening with an owner's application:

For each application, we organized all the data TapMetrics makes available (analytics, reviews, buzz, messages and others) into separate sections. In addition to these data-centric sections, owners have access to the administration settings of an appplication and an extensive help section:

A Dashing Dashboard

To keep application stakeholders in the know about all of the applications they own and manage through TapMetrics, we decided an up-to-the minute dashboard showing vital and trending information would do the trick. The word dashboard gets thrown around a lot these days, and while a "dashboard" in itself is not a cure-all for the usability of a product, the act of prioritizing information and communicating associations between data can go a long way toward taking the pulse of an application. We focused on placing time-sensitive, meaningful, summarized information in the dashboard, to communicate that pulse to owners right away:

Along with statistical data about applications, TapMetrics also provides some great insight into the traction they have with consumers through iTunes Store reviews and with the general public through "Buzz" (references to applications) across a set of owner-selected sites. Because this information can have a huge impact on an application's success, we wanted to make sure the most recent social activity "bubbled up" to the top of the site:

Visual Displays of Quantitative Information

TapMetrics lets owners dive into a wealth of analytics, including location, sales, download, and device information. We wanted to encourage this diving, so we created some additional parameters to help owners understand trends across time and space. New controls for selection of pre-set or custom timeframes will allow owners to zoom in on a specific moment in time, such as an update release. Owners can also toggle between a graph and map display for different trend contexts. To get a larger picture within the dashboard view, owners can line up different applications' analytics side-by-side to compare:

Communication

It's imperative that product owners are aware of any questions, issues or feedback their consumers may have. TapMetrics' ability to gather consumer messages and send broadcast announcements is really useful. We wanted to make sure that utility was front and center, so we placed recent messages and alerts in prominent, organized places. This layout will help owners address consumer feedback as efficiently as possible:

Thinking Ahead

Since TapMetrics is a young product, we wanted to think about possible future directions even as we completed this set of short-term design suggestions. With all the rich data an application owner can access and monitor, allowing an owner to set goals for progress over time makes complete sense as an added feature. Goals could be set around sales, as well as consumer ratings, reviews, buzz, crashes and technical statistics. These goals could be set for a single applications, or across all applications, for total sales, customer service and reputation:

I really enjoyed working with the team at TapMetrics to take their young, promising product and make it even more effective as a one-stop-shop for iPhone application owners. I hope Chris and Nolan get a lot out of the concepts we designed, and continue to build upon them to improve the already solid and useful web application. I can't wait to see what they have up their sleeves next.

Lessons from Thomas Vander Wal: Reputation and Social Comfort

2009-07-28T13:01:00Z

Earlier this month, we hosted a workshop here at Viget led by Thomas Vander Wal centered on Social Design in the Enterprise. I think it went great, and thanks to those who attended as well as to Thomas. A few of us went bowling afterward, and for those who didn't: you missed out.

Thomas led us through a series of challenges and practices that try to help the necessary challenge of pushing the needle in an enterprise environment -- while the consumer web may be satisfied with a 1-9-90 model and widespread participation inequality, the enterprise web requires a much higher level of participation. Thomas was a tour de force when it came to knowledge-dropping; I don't think I'm unlike other workshop attendees when I say that I spent the weekend sparking new ideas as some of the concepts Thomas talked about sunk in.

The thing is, while some of these concepts are crucial to enterprise products, most of the concepts are still very relevant to the consumer space as well. I just want to take a second and look at two things that I found interesting during and after the workshop.

Reputation

The enterprise has a big advantage over consumer social tools when it comes to reputation. Inside an organization, everyone's reputation is either known or easy to find out, and participants in enterprise social tools generally know the audience consuming anything they write and produce. The larger the organization, the less this is possible, but there's always way to find out about someone else within a company.

This is both a blessing and a curse. In organizations that foster open communication, are tolerant of risky ideas and failure, and actively reward contribution, participation is far more likely. In those organizations that don't, the fear of altering one's reputation with a bad idea, misunderstood information, or just spelling errors is going to keep may along the sidelines.

When it comes to the consumer web, reputations are much different, as we only see them in one context, if we see them at all. Users hide behind often-fictional personas and avatars, knowing that their reputation in a particular online community is unlikely to affect or be affected by the other parts of their online and offline life. This is a good thing sometimes, when we want people to do something they might not otherwise do, and it's often useful for promoting voluminous action. Much of the time, though, it negatively affects the community by allowing users to create provocative, inflammatory, false, or misleading content. While some users may care about their reputation within a particular community, there are few consequences for not caring.

Improving communities probably has a lot to do with improving reputation systems, and improving reputation systems probably has a lot to do with making a connection between a user's persona in one community and in others, including offline life. When working on SpeakerRate, we've been playing around with this idea by encouraging users to validate their accounts against a LinkedIn profile, which we perceive as having a value significantly higher than one's SpeakerRate profile, and which reflects the user's offline life in a significant way. If you look like a tool on SpeakerRate, it could possibly reflect on you past the friendly confines of the app.

While this could have a negative impact in the sense that some folks might be afraid to post something connected with their real identity, it also conveys to new users that the community is built on mutual respect, open discussion, and constructive criticism.

There's a lot left to do when it comes to making decent reputation systems, and it'll be interesting to see how that science advances.

Social Comfort

Thomas also talked about a concept he called Social Comfort, aka SoCo. He attributed a major piece of a user's likelihood to use a product to this factor, which involves three major pieces:

Social comfort with others in the community.
Social comfort with the tools involved.
Social comfort with the subject matter.

Going too deeply into each of these areas is beyond the scope of a blog post, but it does mean that effective communities have an emphasis on feeling like you really know others in the community, tools that are a pleasure to use and easy to learn, and provide security in the understanding of the subject matter.

Does your social app provide users with a high level of social comfort from all three areas?

If you missed this workshop, we should be having another one on another subject before you know it. Stay tuned!

Workshop: Social Design for the Enterprise

2009-07-07T22:54:00Z

If you're in the DC area (or even if you're not), it's worth checking out the workshop we'll be hosting next week with the renowned Thomas Vander Wal as he teaches attendees how to design and execute social products in larger organizations. Here's the description:

It's tempting to follow the lead of mainstream social networks and applications when you bring social principles to your organization, but it seldom works out as planned. Firewalls, organizational structures, training, and interaction with direct customers are all too common hinderances.

This workshop, led by InfoCloud's Thomas Vander Wal, focuses on building, deploying, and using social tools inside (and outside) organizations based on deep understanding of the foundations of social tools and how people interact with each other using them. We'll work through tools (features and functionality), user experience (ease of use), sociality (how people interact with each other), and encouraging use.

While the design and human interaction problems involved are often overlooked and not well understood, this workshop will provide models and frameworks that can help you think through these problems and find success for your organizations and clients.

We're keeping the workshop fairly small, but we've still got a few tickets left. Check out the workshop's page here. We hope to see you there!

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".