Designed to be used

I have become curiously interested in this post that talks about how it’s difficult to correctly write an application for the iPhone. The assertion is that writing software for the iPhone is harder than for a desktop, not because of the technology, but because:

“everything counts so much — every design choice, every line of code, everything left in and everything left out.”

Very eloquently and precisely put. If you’ve ever used any sort of mobil…

I have become curiously interested in this post that talks about how it’s difficult to correctly write an application for the iPhone. The assertion is that writing software for the iPhone is harder than for a desktop, not because of the technology, but because:

“everything counts so much — every design choice, every line of code, everything left in and everything left out.”

Very eloquently and precisely put. If you’ve ever used any sort of mobile computing platform, not just the iPhone, you know how much proper design can make an application really useful – or totally useless.

But then again, isn’t this the case with any application? Aren’t the best ones those in which the designer applied Brent’s assertion for iPhone software? Some applications seem to have their genesis in the charter “build an application that allows the user to perform all these actions” while others are built on the charge “build an application that helps the user solve this problem” — it’s the battle of functionality versus purpose.

Take a look at ChartChooser based on Andrew Abela’s “smart charting” guidelines. It doesn’t help users figure out how to pick a bar chart or pie chart. What it does is to help them answer the “what’s the right way to show this information” question. There’s not a lot buttons or features, it just does one thing well. There are certainly other good (better?) examples out there as well (FlipVideo, Evernote, Tivo, to name a few). The better the software, the less the user will think about it when using it to get their job done.

In line with this thinking, we put together a short list of some design principles that we use to keep the user productive:

• Solve a problem – Make sure the end product provides a specific solution to a specific problem so the user can easily understand how it helps them.

• Enable casual use – Minimize the “barrier to entry” for new users by avoiding feature overload, minimizing clicks for each task, and by not letting polish become bling.

• Tell a story – Relate the data to the key questions, answering them in a logical order and revealing layers of detail as users express interest in knowing more, not before.

• Lead to action – Empower the user to finish their task quickly (btw, the “task” is not “using software”).

• Encourage exploration – Use the experienced guide approach to give the user enough context to understand the problem and then point them in the right direction to learn about new factors that will expand their insight.

 Link to original post