In The Face Of Overwhelming Functionality

How building iPhone and ASP.NET apps can teach you the same lessons.

SharePoint team site, .NET application, iPhone app, or web application; no matter the type, I've learned (mostly the hard way) that creating software isn't necessarily about creating the most functionality or relying on added flexibility. I've been working on two commercial applications and both of these development projects have been lessons in getting really clear with myself and fellow team members about what the core things these applications do, and trying to make sure they do it well. (FYI: Warning… shameless self promotion ahead.)

Focus On The Core Stuff And Do It Well

Last week the first iPhone app I've been collaborating on, Voice Writer, went up on the iPhone App Store. (iTunes page link.)

The co-creator and I at Vozle have been working on several mobile and cloud application ideas. With more ideas on the table than we could possibly do in a lifetime, we elected to have our first app perform just one basic function, capturing information, and attempt to do that in a way that's most natural to the user. The app does just what the name says; you write with your voice; capturing notes, information, research, and ideas "in the moment", using voice rather than just a keyboard like most software. The app takes care of translating the voice into text for you and has some nifty correction abilities that are natural to use.

We both debated quite a bit about what to put in the first version, and frankly we probably took out as much or more than we left in. This weekend came an indication that those decisions and the UI design are accomplishing what we had hoped. A user, Kenneth from New Jersey, sent the following in an email.

"Thanks for creating a straight-forward app that does what it does well."

Wow. As a software designer, complements don't get much better than that. Now, one email doesn't mean the app's guaranteed to be a huge success, but it does confirm for me what I've learned; focus on the core stuff, do it well, and design for usefulness not the most functionality.

In parallel I'm working on an ASP.NET / LINQ to SQL application for PCI compliance. (The company I'm a consultant in, The CISO Group, started operations today.) A good bit of the discussion amongst the team has been about adding this graph, or that extra screen, or this feature… essentially what the app should have in it. Since the application is about reporting compliance, the user (a merchant) is going to want the easiest, least hassle process, that's quick and also helps them in spots where they may not

be up on the all the security lingo or knowledge in a compliance assessment. While the application is still in development, I'm starting to show and test the application with users to see where the design holds up and where changes are needed. My hopes are that the focused approach of the design is the right one, but ultimately users will validate or change that decision.

One side note: While creating the UI design for this app, I tried out a new tool I'm really high on called Balsamiq Mockup. Balsamiq does one thing, emulates (and speeds up) the process of creating hand drawn screen mockups. That's it. I doesn't do anything else. And that's actually good, because it keeps the designer (me) focused on the design goals and the usefulness, not the implementation or UI gadgetry.

Substituting Flexibility For Clarity

I think one of the reasons the above lesson is so relevant for me is that I've made the mistake more than once of opting for the opposite: If you're not sure, design for flexibility. I'm convinced that when this happens, it's a sign I've not done my homework and haven't made some really important decisions.

I first learned this lesson observationally, then later experientially when testing software with users. In design sessions, there are often discussions that sound something like, "The user has lots of options. The user can get to that screen by pressing this button, clicking on that arrow, or enter some data in this field. They all do the same thing. Lets let the user decide." This follows the philosophy that giving the user more options is better, and that the user can chose what works best for them. Logical, but as flexibility increases, complexity frequently does as well.

Observationally, I've noticed a pattern. Designing in flexibility is often a coping strategy developers (and don't take that the wrong way, fellow developers) frequently use when the folks giving direction aren't clear about who the user is, what the core task is or what the app is really supposed to do. When there's a lack of clarity, a developer will usually opt for building in extra flexibility so whenever those things are figured out, they'll have the best chance of hitting the target. Seems pretty reasonable, and I've certainly done that enough times.

What I've learned through testing software with users and supporting them, is that more functionality or added flexibility isn't always better. Frequently multiple options that do the same thing, or presenting the same information in multiple places or multiple ways, just adds confusion and causes users to question what to do or the reason for the redundancy. The user might stop to ask, "Why are there two options? What's the difference between them? Are they really the same, or are they different? There must be two different ways to do this for a reason? What if I chose the wrong one? Is the data in that graph the same as this other chart? Why is it here twice?" I've even had users ask that the app just give them one way to do something and they'll adapt to that. Essentially the message from software testing with users is "don't make me decide" unless there's a distinct advantage for the flexibility.

As I think about the two iPhone and ASP.NET apps I've been working on, whether conscious or not, they follow these ideas of focus and clarity. With more user feedback, we'll see whether or not this is the best design approach. That's one of the things that makes creating software both challenging and fun.

Note: The blog post title was adapted from the line "Keeping Your Cool In The Face Of Overwhelming Functionality" in the book iPhone Application Development by John Ray and Sean Johnson.

Like this? Here are some of Mitchell's recent posts.

Recent Podcasts:

Mitchell's book recommendations: Also visit Mitchell's other blogs and podcasts:

Visit Microsoft Subnet for more news, blogs, opinion from around the Web. Sign up for the bi-weekly Microsoft newsletter. (Click on News/Microsoft News Alert.)

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2010 IDG Communications, Inc.