Designing Data Products - Data Fluency: Empowering Your Organization with Effective Data Communication - page 228

DESIGNED TO BE USED
By Ken Hilburn

I have become curiously interested in a recent blog 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. ” 1

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? Some applications
seem to have their genesis in the charter “build an application that allows
the user to perform all these actions,” whereas others are built on the charge
“build an application that helps the user solve this problem”—it's the battle
of functionality versus purpose .

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 that users 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 not let-
ting 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 users to finish their task quickly. (The “task”
is not “using software.”)

⬛

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

⬛