Random Thoughts About Random Things

My Experience Developing an iPhone App

This was my first time working on an iPhone app and I quickly discovered the differences between working on a website and an app. I was the product lead for developing the 2.0 version of the iPhone app for Edmunds.com. This app (v2.0.2) was a complete overhaul from the first version of the iPhone app and thanks to a great team, many long hours and extensive user testing, the app so far has received a 4.5 rating in iTunes (January 2012). This was a great experience for me and I wanted to share my insights and discoveries during the process. Note: The current version of the app 3.0 and up has a completely different front-end and I was not associated with this version.

Make the app simple, but elegant.

iPhone users expect apps to be quick, easy and intuitive. As a team, we adopted the philosophy that if you have to explain how the app works, it’s a #fail. This philosophy helped our team agree on the overall app strategy early in the development process. Here are some of the concepts and ideas that were used to create the app.

1) Minimize the number of icons on a screen.

We decided to minimize the number of icons or buttons on a screen. Having fewer choices is easier for the user to navigate the app. How many times have you tapped on icons trying to guess what an icon represents? I’m just not a fan of having a tray full of icons at the bottom of the screen.

2) Use known or easily identifiable icons.

Use icons that are easy to recognize or understand. For instance, use a house for the home screen, magnifying glass for search or gears for settings. We discussed using buttons or icons with labels, but ultimately went with only icons to keep the screens clean. Using clearly labelled buttons or icons is not a bad idea either, just make sure the verbiage isn’t too long. Icons like hearts, stars and file trays don’t always mean the same thing from app to app and can frustrate users if not clearly labeled.

3) Wide and shallow is better than narrow and deep.

Unless necessary, try to have screens go only one level deep. This sounds easy, but can be difficult to implement. This is important as users easily get lost in apps and have a hard time orienting themselves. The last thing you want to see during testing are users who constantly tap on the back button for navigation or close the app and restart.

4) An app isn’t a website.

Remove all unnecessary items that exist in a website and just include core items in your app. Apps are not websites, therefore, don’t take websites and just put them into an app. In addition, avoid using website conventions in apps. Examples are breadcrumbs, thumbnail carousel trays, multiple landing screens, tabbed headers, direction arrows, etc.

5) Gestures are your friend.

Maximize gestures that are native to the operating system or device as a primary means of navigation. For the iPhone, we focused on tapping and swiping as the primary means of navigation. Stay away from complicated gestures if possible, especially on small screens like a phone. Use visual clues like HIG dots to let users know that there are multiple screens. Many users will naturally tap and swipe on the screen for discovery, but visual cues help. Don’t develop your app for newbies. If someone owns an iPhone, it’s their job to figure out how to use it.

6) Having fat fingers is not a crime.

Make sure the tap space for buttons or icons is large enough. I believe the rule of thumb is 44 pixels for the height and width at a minimum. In some instances, we made the tap zone for a button larger than then actual button size to facilitate the tapping process. During testing, pay attention to see if users are tapping the same buttons or icons multiple times. If this is happening, chances are your tap zones are too small.

7) Make screen transitions simple, but meaningful.

Be smart with screen transitions, especially on the iPhone. Don’t put an emphasis on “cool” transitions, but rather focus on transitions that communicate with a purpose. For instance, if there’s a screen with a list, tapping on an item in the list should horizontally slide the screen to reveal information rather than having the screen flip over or disappear. Remember, just because a transition can be done doesn’t mean you need or should use it. Think of all the bad PowerPoint or Keynote presentations you’ve seen with bad transitions.

8) “There’s no place like home…”

Always provide a quick way for users to get to the home screen, list or menu. Users should be able to quickly orient themselves and find content easily. Having a flat screen architecture facilitates this process.

9) Make ads tolerable.

If you need to have ads in your app, we did, place the ads in a consistent place on the screen so users can learn to tune them out. For most free apps, advertising is the primary means of revenue generation and although users dislike ads, many users accept ads if they are not obtrusive. We placed ads at the very bottom of the screen in a fixed placement.

10) Google maps won’t help with these directions.

Spend time to plan out the app navigation by creating a sitemap. Having a sitemap has always helped me put my thoughts down on paper and communicate my ideas to the rest of the team. People are visual and having something to look at is better than just talking about ideas. A sitemap can help focus on the key paths of the app. Remember, even if your content and functionality is great, if users can’t find what they’re looking for, you’re wasting time. I recommend testing the core concepts of your navigation early before any coding is started.

Create a sitemap for planning

Above is the final version of the sitemap that I created for the app. The sitemap provided visual communication to the team. Having a tangible “road map” facilitated team discussions on how and what to work on from iteration to iteration.

The sitemap helped the team gain an understanding of the core navigation. The sitemap does not describe what is on each screen or what each screen looks like, but rather the flow of the screens. I can’t emphasize the importance of thinking the navigation process through. Not having a clear idea or concept about the navigation is dangerous. The sitemap should be a work in process and updated as changes are made throughout the project. Our sitemap had many updates, but once we were able to finalize the core navigation of the app, and user test it, we were able solidify the main navigation paths and use it as the blueprint for development.

If your team starts developing one screen at a time, I guarantee there will be navigation issues. Discovering navigation issues late in the development process will lead to rework, delays or bad decisions to compensate for lack of forethought.

Creating Mock-Ups

Once the initial site map was completed, I created screen mock-ups for user testing. The test consisted of selecting a year, make, model, type and condition of a vehicle. Here’s examples of vehicle selections:

Year = 2012, 2011, 2010, etc.

Make = Chevrolet, Honda, Ford, Audi, etc.

Model = Accord, F-150, A4, Prius, etc.

Type = Sedan, Convertible, SUV, Truck, etc.

Condition = New, Used or Certified Pre-Owned

The first hurdle I needed to solve was how to test the navigation without any code. I used a mock-up tool called Keynotopia that has iPhone screen templates and screen elements which can be dropped and dragged into PowerPoint or Keynote. The great thing about using Keynotopia templates is that the templates display perfectly in your iPhone.

Another popular tool is Balsamiq, but I prefer using Keynotopia. Why use ready made elements that look like they were hand drawn, especially for user testing purposes? The one thing that I’ve encountered over and over in user testing is that users have a hard time understanding or accepting wire frames or crude mock-ups regardless of what you tell them or how the mocks are labeled. Initial testing mocks-ups shouldn’t consist of production level art, but should be a good representation of the product. Keynotopia solves the issue of creating quick mock-ups that look like an actual product.

Update: There’s a recent software program called MobiOne that allows non-developers to create app prototypes (iPhone, iPad, Android) on Windows machines and even upload the demo apps on devices. I wish I had this tool when I was creating the Edmunds app as it would have saved a lot of time. I would have created the same graphics, screens and transitions below, but wouldn’t have to create the demo in Keynote or PowerPoint and then use a PDF reader to display on a phone. The MobiOne software costs $99.95 and you’ll need an Apply annual developers license ($99) to display apps on an iPhone or iPad. In addition, another prototyping software for Macs is called proto.io which looks to have similar features and functionality as MobiOne. The pricing on proto.io is higher at $24 or $49 a month. Both seems like good solutions so if you have a Windows based machine try MobiOne and if you have a Mac try proto.io.

Here are some of the screen mocks I created for user testing using Keynotopia:

Home Screen

Make Selection

Model Selection

Year and Condition Selection

Type Selection

Vehicle Menu

The mock-ups created were quick and easy and good enough to represent a working product for user testing.

Mock-ups with interaction

Once the initial screen mocks were created, I used hyperlinks to simulation app interaction between the screen mocks. This can be done many different ways so I suggest you try it out and see what works best. You can’t simulate everything an app does, so pick and choose which interactions you want to test. For our first set of tests, we had users select specific vehicles based on the mocks and hyperlink paths created. If the user was able to get to the Vehicle Menu screen, the test was considered a success.

Here are some things I discovered while building my mock-ups. The first thing I discovered when creating the mock-ups was the inability to simulate a swiping gesture. As a result, for any swiping motions, I created left and right tap zones and asked users to tap accordingly to simulate swiping. Although the action is not the same, you can still determine if users intended to swipe or not.

The second tip is to avoid any unintended slide transitions while testing. To accomplish this, I create one large tap section that is the size of the entire screen and hyperlink it to itself or the same slide. This is done by using a box shape and making it the same size as the slide. Next, remove all the borders and make the box color transparent. This creates an invisible layer over the slide that can hyperlink to itself. For the hyperlinks that I want to make active on a slide, I simply create the hyperlinks and place the link(s) on top of the overall slide hyperlink. This is done by selecting a specific hyperlink and using the “move to front” function. This process can be tedious, but experiment and see what process works best for you.

The last tip for creating slide mocks is to copy and paste entire slides and then make individual edits on each slide. This will not only save a lot of time, but also avoid objects that “jump” when the slides are hyperlinked. We’ve all seen PowerPoint or Keynote presentations where it appears things are moving or jumping during slide transitions. This is distracting to users when they are testing your app so take extra the step to make your mock interactions as smooth as possible.

On the above Type Selection mock-up, in order to simulate the selecting a type of BMW 3-Series, I did the following:

1. Created the original slide and then made five copies of the slide for a total of six slides.

2. The first slide has no vehicle type selected, each of the other five slides has an orange box around each thumbnail to indicate that a specific vehicle type was selected.

3. Created hyperlinks for each thumbnail (type) on each slide that links to the correct slide displaying the vehicle type with an orange box around the thumbnail.

If done correctly, this simulates a user tapping on each thumbnail and having the orange box appear around the selected vehicle type. You’ll be surprised how real this appears and how effective the technique is during user testing.

Testing mock-ups on the iPhone

OK, now that you’ve created a mock app with interaction, it’s time to test with users. I’m not going to talk about the process of testing or how to recruit your testing panel as there are sites like Quora where you can find this information. What I will to talk about is how to get your mock-ups on the iPhone. In order to really test your mock-ups, you need to have users interact with your mocks on the iPhone. The best way to do this is:

3. Once the PDF reader app is installed on your iPhone, go into iTunes and upload your PDF file.

4. Open your file and check to see if your hyperlinks work and determine if the overall app demo is ready for testing.

There may be a slight delay between the slides when the user taps on hyperlinks, but this should not hinder your testing.

Launching the app is only the beginning

These were some the things I learned and used to develop and launch the app, but launching the app is only the beginning. You need to listen to user feedback and make frequent updates and changes for everything from bugs to enhancents to new functionality.

We set up a feedback link in the Settings section of the app where user feedback is sent directly to our email addresses. I made it a point to personally respond to every email within 20 minutes regardless of the day or time. I found the feedback to be insightful, brutally honest and consistent.

Look for trends and use this feedback to prioritize your next release(s). You’ll be surprised to see how appreciative users are when they receive a response, most expect no response or a generic pre-written email. I even set-up phone calls with users to discuss their experience and have sent updated screen shot mock-ups to get their review and comments. After all, what’s better than getting feedback from someone who has already downloaded the app, is using and familiar with your app and has taken the time to write you about what they like and don’t like about your app?

In closing

There are a lot of things you have to think about when creating an app. I haven’t even touched on all of the development, design, database, definition of user needs, revenue, etc. issues that you need to address. But, I hope that I have provided some helpful tips that you can do to get started on your journey. I tried to emphasize things are can be done early in the process to help plan your app and use some Lean Startup techniques.

If you’re not familar with the Lean Startup process, here are some great books:

At some point you need to ship product and this means submitting your app to iTunes for approval. Once the app is available in iTunes, the fun begins as you never really know how your app will be rated. However, if you take the time to plan ahead, test, provide a decent 1.0 product and listen to your users, you should be OK. Try and fix any bugs as soon as possible, but remember that each time you submit a new version of your app, the app rating is reset to the current version. The overall rating for all versions of the app is visible, but the current version rating is the most important.

Edmunds iTunes

At the time of this post, the app has achieved an overall rating of 4.5 stars in iTunes (version 2.0.2). Download the app and take it for a spin, you’ll see how the final product turned out from the mock-up screen shots above.

I hope you found this information useful. I’m assuming if you got to this point, there’s a good chance you’ve read the post. If you have any questions or comments, please feel free to leave a comment.

4 thoughts on “My Experience Developing an iPhone App”

[…] My Experience Developing an iPhone App – A blueprint of how to think about and implement an iPhone application from a product perspective. Disclosure: I’ve worked with Howard Ogawa at Edmunds.com […]