Single Vision for App Dev

My last blog post talked about the important of keeping the design of the app as simple as possible. In order to make some of the difficult decisions needed to ensure the app design stays true to its original intended purpose, you need to establish (BEFORE beginning to design and code the app) the main purpose or "need" for the application. The process I am about to describe is actually a process used by Systems Engineers to design and develop highly complex systems. The reason this process is used for complex systems is that without establishing this single and simple vision you can end up building the WRONG system. 

A need statement is nothing more than a very basic sentence or phrase that states why something is needed. The only rule that needs to be followed when developing this needs statement is that the statement can't have a solution built into it. For example, if you were writing a needs statement for a kitchen timer app the needs statement shouldn't contain the phrase "kitchen timer." Kitchen timer is a solution to the need to keep track of specific durations of time while cooking and preparing food. The reason for this rule of not stating a solution in the needs statement should become obvious in the next few steps of this process. 

Now that you have established the basic need, the next step is to list out important aspects you would like the solution to employ in order to meet the need. We call these goals and the goals should be high level strategies that are absolutely essential to meet the need. For the kitchen timer example, three goals of the solution might look something like this: 

  • Goal 1: Support both time duration and local time relative timing events
  • Goal 2: Provide non-visual information and feedback to the user
  • Goal 3: Minimize the need for the user to interact with touch gestures

Goal 1 is all about having the ability to set timers based on a time duration or a user defined time offset from the local time. For example, while cooking in the kitchen you may have a casserole in the oven for a certain duration and you might also want to start chilling some wine 30-minutes before the expected arrival time of the guests. Goals 2 and 3 are about the use case of physically cooking in the kitchen. You might not always be within view of your kitchen timer so having non-visual feedback (tones, alarms, voice messages and vibration) would be useful. In addition to moving all about the kitchen the user may also have their hands covered in food. A goal to minimize finger touch interface and maximize things like gestures (think of using the back of one of your knuckles to trigger a timer when your fingers are covered in goo). Voice commands could also be used to help meet this goal (can you say Siri API?).

We have arrived at the last piece of the vision for the solution we are aiming to design and that is the objectives. Objectives are simply ways to measure whether we have achieved the goals. Objectives are high level technical performance requirements, but more importantly they are a measuring stick to keep you honest as a developer. Typically these objectives are really important. If you find yourself during the design process worrying about other aspects of the design and you are aren't meeting your objectives you know you are focusing on the wrong things.

For the kitchen timer example, the following could be objects that address the goals we just created:

  • Objective 1: Timer function shall support 4 timers at once
  • Objective 2: Timer function shall support clock based timers
  • Objective 3: Timer function shall use 4 different vibration alerts
  • Objective 4: Timer function shall use 4 different alert tones
  • Objective 5: Timer function will respond to a swipe gesture
  • Objective 6: Timer touch target will be at least x pixels wide

So how does all of this fit together and help a developer focus on what's important? Below is how the objectives flow up into the goals and ultimately back to the need:

As you can see from the diagram, this exercise has created a very clear set of objectives that can be measured during app development. The examples shown here are greatly simplified. In reality you will end up with much more specific and more easily measurable quantities for your objectives. The important thing to take away from this is that spending a few hours fleshing something like this out for your next app could really pay-off when later down the road when you have to start makind critical design decisions. Remember, it should all link back to the basic need you are satifying with the app. If it doesn't, then you are going down the wrong path.

Yes, I am still workng on developing my 1st iOS app and no it's not a kitchen timer. When I release the app I'll post my needs, goals, and objectives and see if all of you and my customers agree that my app stayed focused on the need that spurred the creation of the app in the first place.

Simplifying App Development

I am in the middle of developing my first iOS application and throughout the process it has become more and more clear to me just how important "simplification" is. When I first started my application I had a large list of features that I wanted to support. It shouldn't have been a surprise for me when I finished my first user interface mockup that the interface was too cumbersome and complex. I really didn't like it. So I took another cut at designing the interface and that design wasn't much better. What was I doing wrong?

My first app is an incredibly simple utility application, and because of that I didn't want to end up with an interface that required any type of instruction on how to use or navigate through. So I chose to go back to the basics and base the app on Xcode's Utility Application template. This is the basic utility template Apple used for the Stocks and Weather apps that come pre-loaded in iOS. There are two main advantages to using the Xcode templates as a starting point. The first advantage, especially in my case, is that the utility template has a control scheme that all iOS users are familiar with. So if I start with that basic scheme the user will automatically know how to get to the app settings screen of the utility. The other advantage to using the Utility Application template is that the controls pre-built into the application don't get in the way of the app itself. What do I mean by that? When you look at the main screen of the Stocks or Weather app you don't immediately see controls. Instead you see either weather or stock information. The little "i" or information button on the main screen of the app doesn't detract from information you really want the user to be paying attention to.

So how did I get my long list of features to fit into such a simple app control scheme? I didn't. I had to eliminate many of the features and control options I had planned for the app, but this ended up being a really good thing. Why? More control or settings options for the user is not always a good thing. I know what some of you are the user more options is good and taking away options is bad. Yes, options are good but if the main purpose of the app is to provide a simple service or set of data then more options and controls simply get in the way of the whole point of opening the app in the first place.

Most applications (especially utility applications) are accessed for only short amounts of time by the user. Do you really want the user spending that incredibly short amount of time making decisions that I would characterize as secondary to the prime use of the application? For most applications the answer is no. So in order to simplify the control of my app down to something that would fit the basic control structure of the Utility template without sacrificing important features I made some of the decisions for the user. I made these control decisions based on what the users would be using my app to accomplish. How did I know with such certainty what a user is going to be expecting? Simple...that's the answer, simple. The app was designed with a singular need in mind and everything that went into the design of my app was based on that one need. Some of the best apps in the app store are apps that do only one thing and do that one thing really, really well. My next blog post will talk about how you start the app design process with this singular need in mind and ensure the app doesn't stray from that focus as you progress through the coding and completion of the app. 

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.