Neil Wehrle

I recently (December 8th) gave a talk at the betaday 2010 – a small private conference put on by my company, betaworks – covering the history of product development there. I was excited to present because of the occasion, but also since I got to talk about product development.

John Borthwick has a simple framework he uses to describe our approach to creating products, and it goes something like this: Inception, Iteration, Scale. The overall approach is similar to Paul Graham’s Six Principles for Making New Things and lean startup techniques like Minimum Viable Product. A key distinction from most startups is that betaworks intentionally makes products that turn into companies, and its companies are held in a loose network, fostering learning and growth. Here, then is a short description of each of the phases:

• Inception: this is closest to Lean Startup/MVP ideas, in that we try to have a single developer build out the core product use case end to end in a short period of time. What we do at the end here is some kind of assessment to determine if an idea is solid enough to make a bigger investment. In my talk, I refer to the origins of chartbeat, and while people gravitate to stories with clear beginings, most betaworks companies emerge from a primordial soup than a flash of divine insight.
• Iteration: the next phase is also closely aligned to current startup thinking, and is where we start making rapid iterations and pivots, looking to pick off substantial and hopeful edge cases that were overlooked previously. If we think we have something – and often the market will tell us – we usually need to scale it up. Knowing when to pivot or completely change a business model is difficult, especially when so many startup narratives are about founders sticking to their vision. chartbeat is a clear case of this in that the underlying technology had origins in a real-time chat environment and ended up powering a data dashboard.
• Scale: rapidly accommodating growth of a user base is often accompanied by corresponding growth in staff, the breadth and complexity of the app, and wildly spiking usage patterns. The betaworks network of companies share knowledge and experience with each other, so companies can move faster with fewer mistakes.

After my talk I was asked about the role of user experience at a startup and when to hire a UX person or team. The answer is, of course, it depends. My role at betaworks is pretty unique, in that I work across several companies at a time, and do almost everything (user research, interaction design, visual design, usability testing). I help companies grow, and to the point where they need to hire their own fulltime UX staff. To what degree a startup needs help with their UX (if at all) is dependent upon several factors:

• The type of company. Some startups may be backend and/or API focused, and only need a simple marketing presence to communicate what they do. Other companies are completely dependent upon low-friction user interaction or cultivating user-generated content and might need more attention. bit.ly spent a considerable amount of time scaling up its infrastructure and refining its API, only paying attention to the UI later on.
• Where in its growth cycle a company is. Generally speaking, I’d advise that companies outsource their UX for as long as possible (depending upon the above), since reasonably talented developers can get good mileage out of some good design patterns. Forming a close relationship with a single UX contractor can keep costs down while benefitting from gains in institutional knowledge.
• The kind and level of UX involvement needed and is possible. The term “UX” is often misused and poorly understood (entirely through the efforts of its practitioners) but goes far beyond the appearance of a product. UX methods and solutions run the gamut from strategic to reactionary, from game-changing to decorative. A skilled practioner will be good or excellent in several areas, and wise enough to know what’s good enough or when to call for help. A startup might not be willing or able to bring in user’s voices to product develpment efforts, or choose to direct efforts in the wrong area. Having a designer make concepts “real” through lightweight prototypes or designs, and validating those with users can be far cheaper and time efficient than having a team of developers code up something. The nature of the business should indicate which paths to go down.

Overall, this was a great opportunity to deliver my perspective on how UX is valued and integrated into the startups at betaworks, and something I’ll talk about more in the future.

I recently gave a talk at the O’Reilly Web 2.0 Conference here in New York. It doesn’t contain my speaking notes, but here are the slides I presented:

An interesting series of articles appeared in the New York Times Sunday Magazine this past week covering technology in education. Interesting to me because of the variety of approaches discussed, from drill-based learning to home schooling.

One of the pieces discussed the use of video games as learning aids, and covered a new middle school here in New York that has a curriculum largely based around video games. It was a little hard to discern what level of integration gaming has with learning there, but there was a brief mention of what one might term normal learning activities (like reading) place. I’m a bit torn on the efficacy of this approach, and perhaps because this piece is a little lighter in facts and heavier on first-person interpretation. I am a little leery of breathless descriptions of people who only two years ago were running street art and puppet shows now commanding an entire middle school. There is some mention made of dopamine studies, but it all sounds extremely thin and premature.

My children are already well aware of what level they are on in most of their subjects where such measurements are taken (Reading, Math). They are fairly competitive, and I don’t know how much more pressure they need in that area. What does appeal to me are the constructivist principles that seem to be at work in some of the learning. Kids building their own games is a very old approach, so its good to see it updated here. There was mention of game design and design thinking playing a role in the development of the curriculum, which is encouraging, because if it is done right it can bring the invaluable knowledge the educational system has acquired with newer understandings of motivation and reward.

I wonder if these principles can be used to instill a joy of long-form reading, and the kind of discussion that can accompany the development of close reading skills. Perhaps an “Om Reader”, like the OmmWriter, but with more incentives and networking can be a part of children’s learning experience. I don’t particularly like it, but the “Popular Highlights” feature in the Kindle seems a step in this direction. IDEO released a concept video of three approaches to reading tools, and while the last one named “Alice” seemed the most interesting, I found the other two to be fluffed out features, not standalone products.

It points to the desperation our society feels about the state of education in our country, and how little we seem to know about how children learn. My guess is that we know quite a bit, in a general sense, but we keep trying to scale this knowledge up and apply to all children, which is where it falls apart. Perhaps that’s the problem, and programs like this might help us make the brave decision to allow for much greater latitude in how our children are educated.

A couple of articles I came across provide insight into the development of our ability to read. Not only are some novel explanations put forward, but it comes at a time when one of my daughters has experienced what is described. Examples of how evolution can explain seemingly impossible developments in human are always interesting to me. As is often the case, an adaption suited for one thing is “hijacked” and put to use for something else.

What I’ve seen in my household is how my daughters will often flip letters (“b” and “d”, for example) when writing, and it takes months or longer for them to get the correct positioning down. In the Economist, new research has found that:

Learning to read requires the brain’s visual system to undergo profound changes, including unlearning the ancient ability to recognise an object and its mirror image as identical…[and] skills acquired relatively recently in people’s evolutionary past must have piggybacked on regions in the brain that originally evolved for other purposes, since there has not been time for dedicated neural systems to develop from scratch.

Since writing has only been around for 5-10,000 years, there hasn’t been enough time to evolve an adaptation for reading. I recall that the shortest known adaptation is lactose tolerance in adults, which I think started in Europe and has been spreading since then. My kids (and all early writers) are unlearning an evolved survival response that allows them to distinguish between reflections from real objects. Again, from the Economist:

Dr Dehaene thinks that the VWFA (Visual Word Form Area) may be responsible for the ability of some primates to recognise themselves in a mirror, or to recognise a tiger even if it is seen only in reflection—thus conferring an important survival benefit. That it is also crucial for reading might explain why children make a type of error he calls “early mirror reading”. It was thought that only dyslexic children were prone to confusing “b” and “d”, and “p” and “q”, and occasionally writing their names back-to-front, but Dr Dehaene has found that all children make this error.”

In a recent New Yorker article (“A Man of Letters” June 28, 2010), Oliver Sacks describes a case where damage caused by a stroke in a patient revealed the connections between many areas of the human body that allow us to see and read:

Reading, of course, does not end with the recognition of visual word forms–it would be more accurate to say that it begins with this. Written language is meant to convey not only the sound of words, but their meaning, and the visual word form area has intimate connections to the auditory and speech areas of the brain as well to the intellectual and executive areas, and to the areas subserving memory and emotion. The visual word form area is a crucial node in a complex cerebral network of reciprocal connections–a network peculiar, it seems, to the human brain.

Sacks describes how our evolved capacity for rapidly recognizing objects by their shapes, even when we haven’t fully processed what we’re looking at, is at the core of reading. Type designers recognized this in the 1950s when working on the US Interstate: people recognized mixed-case words much faster than upper-case words because they could more easily discriminate the shape. Sacks cites research showing a limited range of shapes and combinations humans use to create alphabets of any kind, and their tight relationship to the kinds of topographies humans innately recognize. While we may think the alphabets of the world to be very diverse, they are actually limited and tied to closely to our evolved abilities.

I’m sure there are more important takeaways from this than to carefully consider when to use type treatments (any good designer should know this), but I’m always happy to find connections like this that link personal and professional interests with real-life experience.

Visiting my Dad in Illinois, we were driving around in his Prius and I took a shot of (one of) the dashboards. I’m not a daily user of this car, so I’m biased, but I found it incredibly difficult to believe this is an effective in-car driving experience. The layout and typography are poor, and there is a lot of extraneous data (outside temp?) that distract. Even though the primary dash is separate, reasonably designed, and located appropriately, I can only guess that the marketing department had a stronger hand in this than they should have.

I saw this infographic at a rest stop that attempted to communicate the superiority of hand dryers over paper towels. The amount of chart junk dedicated showing manufacturing transport vs. the ecological impact I thought was ironic given the location at a rest stop. I’d be curious to follow up and see what the true distribution of cost, energy usage, and environmental impact is.

The new bit.ly launched today, which I designed the UI for (I did the old one too, but this time I had the incredible talents of Gregory Tomlinson available). Check out the tour for more information. On a related note, there was a nice writeup in the New York Times today about betaworks – great timing!

The chartbeat dashboard recently underwent its first major revision since launching a year ago. Below is a copy of a post I wrote for the chartbeat blog giving some background into the redesign.

The team has a strong vision for chartbeat, and to bolster our vision I led some quick-and-clean research into how current and prospective users view chartbeat. Our plan included heuristic evaluation, in-person usability reviews, and group-based cognitive walkthroughs, all to provide insight and momentum. The team arrived at a set of first principles to guide development, and we quickly settled in an iterative design-build-test cycle, where the fidelity of each step evolved as we built out the site. I’ve highlighted some of the core principles and selected design decisions below:

Structure the site around user goals
chartbeat is a tool for front-line workers, not just internal analytics teams. We designed the layout around a set of use cases, so users could walk through the data in a logical fashion, understand causality, and take action. The triad of panels at top allows users to understand “how many people, how did they get here, and what are they looking at?” in a snap. We also heard our users love the kinetic nature of chartbeat, so we extended that a bit with a Matrix-like stream of raw hits in the right-most column.

Data should be appropriately dense, clear and actionable
Data should be rich and deep, without compromising ease of use and clarity. As an example, the tree map in v.1 was challenging for users – they liked the intent, but it was difficult to interpret. Sites with extremely low or high traffic or with few pages skewed the chart so that it was impossible to analyze. We decided to use a small range of fixed sizes, ensuring the display of most pages, and using dots to represent visitors. Larger numbers and page titles increase legibility, while isolating the page modules with white space makes it easier to read them as units. We also standardized and gave meaning to the range of colors we used, so users can more associate meaning across the panels.

Everything should be on a single page
A key interaction design challenge chartbeat faces is letting users drill into richer data whithout resorting to traditional hierarchical navigation schemes. We came up with the notion of “pivoting” around a selected data element, where the entire page changes to reflect just that element. This way, chartbeat can serve as a site-level analysis tool and easily shift to isolate a page with a single click.

Use historical data as context, but keep it a real-time tool
Users love the real-time aspect of chartbeat data, but a unanimous request is to provide some context to what they’re viewing. Some amount of historical data was in the previous version, hidden behind a tab at the top of the page. Hidden, too, was a powerful replay feature that lets users isolate events and walk through it (“Tivo for your website” as Tony likes to say). By bringing the replay to the fore, we signaled to users that historical data is available by showing a trend chart. When users pivot on data, we also show a thin historical chart that can be expanded for more detail.

We’ve been doing some followup visits with users to understand their long-term usage and how it is fitting into workflows. One big finding has been that the clarity of the data brought many new features to the foreground for users, giving them new reasons to use chartbeat.

What do OXO Good Grips kitchenwares and the Apple iPad have in common? It may be hard to think of how chunky-handled potato-peelers and cutting-edge tablet computers may be related, but I think both are really “Trojan horses” of product design.

When I read the reviews, look at the UI, and play with it (admittedly, I don’t own one yet), I’ve come to think of the iPad as a device aimed primarily at the Baby Boomer Generation. This is significant when you consider how the iPad is marketed and discussed in the media: like most new technologies, there is a heavy emphasis on early adopters, younger people, and the tech-savvy elites. Apple is too experienced to introduce a product just for seniors or anyone else outside of the 18-34 demographic that content producers trip over themselves to attract. Despite the fact that ‘boomers have far more disposable income, the leisure time to use and buy lots of apps and books, and a strong desire to keep up with the “digital natives”, it would probably be suicide to market the iPad this way.

To the original question – what do these products have in common? Good Grips were designed using Universal Design principles to the accommodate aging hands of seniors. However, this veneer of utility masked the real market of style-conscious consumers needing a reason to replace their perfectly good utensils with new neoprene-handled models. The iPad is not your grandmother’s computer, but with its giant buttons, bright high-resolution screen, and ease of use, it could be. The tenets of Universal Design are centered on the notion that designing to accommodate the requirements of people with disabilities can yield products that by default work well for everyone else. The iPad is a big step forward that takes advantage of the most profound aspect of computers – their chameleon-like ability to adopt forms that belie their endless computational (and networked) abilities – and creates a new category of devices. Even though they have made a clean break with previous computer forms (iPhone notwithstanding, even other tablet devices adhered to the desktop computer metaphor), Apple knows full well to proceed with caution and let the market inform its evolution. Apple promotes it as an empty vessel as much as anything: most of the language from Apple uses word like “magic” and “never before” to describe it, leaving consumers and media to fill in the gaps.  Similar to many other products marketed to younger people, but adopted by older consumers, Apple needs to keep up appearances to through the gates.

A key usability heuristic termed the “Match between the system and real world“, says that software systems should mirror real-world scenarios, nomenclature, and procedures. In the real world, of course, things (especially social) tend to be messy, non-hierarchical, redundant, ambiguous, and often contradictory. A recent post from a designer observed that in his many years of technical support for family members, few could successfully navigate the file system of either PCs or Macs. I, too, have noticed this. People just don’t think hierarchically (I have research to back this up, just can’t locate it right now).

Amazingly, it has taken over 35 years for a software company to completely and successfully shield users from the rigid, hierarchical, and non-intuitive interface known as the “file system” of modern computers. The Xerox PARC Alto and Star systems had, among other numerous innovations (GUI, Ethernet), a user interface that completely hid the file system from users. It introduced the “desktop” metaphor, and that was all users could access – no applications, no file system, just documents. While this approach was nominally copied by Apple and Microsoft, nobody could successfully abandon the file system. Ever since, the user experience of computers has been like an extended version of the ugly, awkward transition of MS-DOS to Windows, where users were sometimes bounced around and forced to open the hood periodically.

Apple’s iPhone did this remarkably well on many counts, and seems poised to repeat this success with the iPad. The key is that these aren’t explicitly positioned as computers, but computer-enable consumer devices. I’m sure that Apple kept hitting a wall when they tried to bury the file system both technically, and from users – extremely vocal technically adept users shouted down any effort in this area. It used to be Macs were labeled “toy” computers because of the slight layer of abstraction the GUI afforded. They seem to have solved the problem by going full circle, back to the original efforts of the Xerox crew.