Thoughts on the ever-changing science and practice of making things

BOSTON, USA – My article on the never ending march of tech did not just hit a nerve, but set off a flurry of passionate comments. One idea that came up in the comments was that hardware differences are starting to diminish, elevating the importance of software in product differentiation. But moving from hardware to software does not remove the importance of user-centered design.

I’ve mentioned a few times the disconnect between what a designer hopes and what a user gets. I’ve collected a few recent links that ask questions around design issues, such as adding apps to smartphones that are close to app-complete, juxtaposition of conflicting expectations, good enough being the enemy of perfect, and a design scorecard proposal.

Read on to stimulate those brain cells. These are some really good articles I’ve collected for you today.

Clashing expectations
The folks at Near Future Laboratory have a great article on urinals. I know it might seem far-fetched, but a public style urinal in a private bathroom set the author off on an exploration of our expectations of public and private spaces and how meanings of things get munged in different contexts.

A designer must not just think of the technical and physical bits of their product, but also take into consideration how people might want to take it into use. Or, you get, as the author says “communications devices that end up being more like something an astronaut would use than what a normal, everyday person would introduce into their everyday practices of connecting to other people.”

All that mental stimulation from a urinal.

Adding when nothing more needs to be added
And speaking of astronaut phones, Steve Litchfield has a quite interesting article on how, despite all the hooplah around app stores, folks, for the most part, could get by with a few (he said at least 3) apps beyond the full set that come with most smartphones.

Steve did a quick Twitter survey and then charted out the responses. Two interesting observations: 1) there are indeed a set of three key apps that many folks used; 2) that there were 40 other apps that only one person suggested as an important app.

I suppose that on the one hand most could get by with a smaller number of apps. But, on the other hand, to really serve that long tail, exemplified by those 40 single apps, app stores better focus their efforts on app discovery. Otherwise, there is no long tail and folks will just gravitate to a few apps, and who would need an app store for that?

What do you think?

Stopping when there’s nothing left to take away
On the flip side of giving users everything they may potentially need, there is the goal of simplifying (or not being any more complex than you need to be).

Wired has a great (albeit long) article with examples from different fields of how folks are satisfied with simple and accessible products, as opposed to hi-fi, whiz bang, poly-featured products [link via russb].

I would claim that the bulk of the 4+ billion mobile phone users who are using basic voice and text phones are quite content with the features of their phones and are not affected by any running obsolescence. Their devices offer them just what they need, and the benefits they could get from added features is not enough for them to change.

Indeed, SMS, and now Twitter, are great examples of popular services that were built around, not only simplicity, but very tight constraints. And both are popular because they are accessible and sufficient enough for their users.

Why is simplicity so hard? Where does our desire to be so complete come from?

Can we be satisfied with a service that lets you build your own mobile web page with only five links?

Keeping tabs on costs
Russell Beattie, who works for Nokia in the US, has been an active thinker and maker of mobile devices, software, and services (check out his latest on redesigning the mobile browser). Over 6 years of listening to what he is up to has taught me to not be quick to judge what he says, but to mull it over carefully.

He’s floated an idea that there should be a scorecard in design that is based on what he calls “action cost,” what I might even call “cognitive costs.” It’s simple: when designing actions, tally up what it costs a user to think and make decisions to follow the pathway to complete the action.

What Russ is trying to do is codify the complexity of the software. I’ve seen diagrams from Francesco Cara, of Nokia, at LIFT 08, showing a map of the menus in different phones, revealing that over half of the choices in an N95 were under settings, a stark deviation from previous devices.

How does one codify complexity? I’ve thought of this in other domains, but, myself, failed to come up with any ideas related to software.

Russ does give an example using an N97. It might be interesting to build comparison charts to understand complexity across devices and products. The magnitude of the number is not significant, but the comparisons would be. This would help make decisions on whether a change in software increases or decreases the complexity of the actions users must take.

Do any of you have ways to measure and manage complexity in software design?

Image from Dave Duarte

Related posts:

• A mixed salad of Nokia thoughts
• Comment of the week – Thoughts on today versus tomorrow
• The science of mobile QWERTY keyboards… discuss