If I were to ask most entrepreneurs working in the web-based application space (not just social apps - all the rage these days) what the process that brought them to their idea was, I suspect many would tell me “it was a problem that needed solution” but that only a few actually made a conscious decision to study the problem before moving to action.

Perhaps due to the old days writing about startups for Techcrunch, I love to know how people got to the problems they’re trying to solve with their companies - I love ideas but more importantly I love the process towards refining them. In several conversations with entrepreneurs working on their products, I noticed how many were out-of-touch with the real needs of their audience, and were set to please the early adopters, the 2.0 crowd, the people like you or me - clearly not the way to critical mass.

Enter ethnography

Enter ethnography - a method to look at user needs through observing people in their naturally setting rather than through research or, like we usually see in this space, guessing work. Ethnography allows you to design (in the broad sense of the word) products that are more in touch with your audience - to solve real problems, and not those you think people have.

Examples: How do you think Sergey Brin and Larry Page got to the idea of an improved search? Likely, by observing people (and themselves) use previous search engines and recognizing how lousy both results and the experience were. Or (to use a product design example) how IDEO realized how children toothbrushes needed to be thicker for a better experience because of the way kids grab them? Through observation. Ethnography.

Or our own example: we launched Goplan (our online project management and cooperation application) after realizing how competitor products were so poor in terms of user experience, and after realizing how new companies (particularly companies working with several remote people - clients or peers) need to spend less time on phones and more time actually collaborating. The need to build a product came out of observation of both the problems of other companies and our own.

“If you want to understand what motivates a guy to pick up skateboarding, you could bring him into a sterile laboratory and interrogate him… or you could spend a week in a skatepark observing him interacting with his friends, practicing new skills and having fun. Ethnography is observing people’s behavior in their own environments so you can get a holistic understanding of their world - one that you can intuit on a deeply personal level.” - LiAnne Yu, cultural anthropologist

Using ethnography in your own organization

You likely do part of it already - albeit not consciously. You probably notice problems (like that one time you had a hard time finding something on some website because navigation was poor) but ignore them. Try spending some conscious time observing and noting down problems - both in your own solutions and in those of others. Not only will you find issues, but you’ll likely think of great solutions that can evolve into products or new businesses.

Watch people interact with both your product or competitor products - again, not in the lab, but in their own environment - and collect data that can meaningfully guide you through the changes you need to make to bump your experience up a notch.

You were likely following the news, so I’ll cut things short - today was the WWDC, and together with a bunch of other cool news, Apple launched a new website. “Great!”, I hear you say correctly. The new website is beautiful. Except for where it isn’t - content organization.

The screenshot above portrays the new navigation scheme on Apple.com (specifically, the new iPod+iTunes page). I have to wonder what crossed their minds that made them mix products (like the iPod models) with accessories and user actions (”Download iTunes”) in the same navigation bar. I mean, that’s mixing apples (pun intended) and oranges.

I know once you do something cool - like that awesome new navigation - you want to use it everywhere, but this is Apple - come on guys, you sure as hell can do better than that in terms of information architecture.

One thing I’ve explored often is how many web-based applications fail because of a lack of proper planning. One thing that I haven’t stressed enough though, is that proper planning doesn’t always mean spending months on end thinking about every single detail, but actually thinking about things in the right order.

Traditional feature-centric design

Usually developers start planning applications by thinking of everything they want it to do - and let’s face it, it’s pretty easy to get excited: since you’re getting some functionality in, you might as well do all the other hundred cool things too, right? Well, wrong.

Getting excited is great, but it may just as well hinder the application development process. Focus slips, pretty soon you’re trying to solve all the world’s problems. You may have heard of scope creep - this is just the same, but it’s your fault, and is definitely avoidable.

Top-down product design

The solution is actually quite easy although it may seem odd if you haven’t done it before: design interface first, then underlying code. Result: no functional slippery slope - you know exactly what you need to build to accommodate the UI functionality. As a side benefit, you get to have something you can experiment with as a prototype sooner, which means you can get more input sooner and iterate over it.

Give it a try on your next project - your developers will love knowing exactly what they need to build, and your designers will love not having to design that new page for the brand new functionality that just crossed your mind.