The first thing a user sees when she starts your app (Figure 7-1) is the user interface—the screen of stuff that pops up after they launch the app. We all know the value of a first impression and that you never get a second chance at one. Because there will almost always be one or more competitors to your iOS app in the App Store, if you fail to keep the user engaged from the very beginning, chances are she’ll just download the next app in the search results.
Figure 7-1. The goal of every commercial or enterprise iOS developer should be to engage your customer from the moment they launch your app
User Interface and User Experience (UI/UX)
First, let’s be clear about what we mean by user interface (UI) as opposed to user experience (UX). The iOS Human Interface Guidelines (HIG) document from Apple should, of course, be your first stop in understanding the differences, but I’ll give it my own personal spin. The UI describes all the visuals you see when launching an app on your device. It’s the buttons, the labels, the graphics, and everything else you see after the app starts. Think of the camera app (Figure 7-2) and how it gives you a button to take the picture, some options for what type of image or video to capture, and a few editing features. There’s a lot of power, but it’s clean and easy to understand. I would say that it’s so easy anyone can use, except I’m reminded of a specific instance when I was out with my friends and asked a guy to take our picture. It took him several minutes to figure it out. The point is that no matter how perfect you think your UI is, not everyone is going to get it quickly. This is where the user experience aspect comes into play.
Figure 7-2. Even a well-defined and clearly laid out app like the camera can be confusing to some people. With that in mind, you’ll force yourself to create the best user experience you can for your customers
To create a good user experience, Apple suggests looking past the UI to the app’s core functionality. What is the app trying to do? What is its purpose? What problem is the app solving or trying to solve? With the most recent releases of iOS, specifically iOS 8 and iOS 9, Apple has made more of the physical screen area available for content, and you should take advantage of that. Don’t add buttons or colors gratuitously to make things look pretty, however. This will only distract from the user’s experience and could get you bad reviews despite how much time and effort you put into making this the most beautiful thing in the store.
One of the key statements Apple makes in the iOS HIG is to defer to the user’s content. Essentially, content is king in the world of iOS apps. Although you want a beautiful and easy-to-manage UI, the user’s content is the heart of everything in the app. Another way of thinking about the user experience is to call it navigation. The user of your app needs to navigate all the controls and indicators and displays you’ve added to do whatever it is they need to do. Someone using a credit card payment app needs to quickly get their card info in, identify and confirm their purchases, add a tip if necessary, and sign the form. A gamer wants to know what’s going on in their field of play to get the best possible score and make it to the top of the leaderboard. Each application will have a different set of information that needs to be addressed, and each user will need to access it in a manner that fits their needs.
To start out, let’s look at information architecture and how to create a great experience for the user.
Information Architecture
The information architecture (IA) is more than just the menus you find on a website or the different levels of a table view as you dig down into more details about your content. The Information Architecture Institute ( http://www.iainstitute.org/ ; Figure 7-3), defines information architecture as the art and science of organizing and labeling websites, intranets, online communities, and software to support usability. Essentially then, IA is how you show your users the content and the actions that they can take. IA is the backbone of your app’s user experience.
Figure 7-3. The IA Institute’s goal is to make information clearer, as should yours be when designing your user experience
Your UX encompasses your menus, the items you show on any screen of content, the overall structure of the app’s UI, and even the terminology you show your users via the simplest labels and text areas. Your goal is to display this information to your user in a way that feels natural to them and how they normally would think of the content. The navigation through your app should feel natural and blend into the background. You want your user to focus on their task and not on the details of navigation.
Let’s be honest with ourselves for a moment. The chances that your app is the only one out there that does what it does is next to zero. Don’t be afraid to go out and explore what your competition is doing. What things work well? What things can be improved upon? Most likely, as part of the initial research your project owner will have identified key competitors with the client. As it is part of an open project, since we’re using the agile methodology described in Chapter 6, this information should be readily available and easy to access. Take advantage of the work already done by your team.
Talk with your users if at all possible, or at least with the project owner, who would generally be part of your agile team. The first thing you need to understand is how your users categorize their information. Then, very early in the process, using some of the prototyping tools we’ll discuss later in this chapter, perform usability testing and get important feedback from your customer to see if your ideas match with theirs. This usability testing is part of the incremental prototyping that is an integral part the Scrum process management methodology.
One thing to keep in mind is that although you can discuss what this looks like or the best way to do that ad infinitum with your team members, you and your team are not the users. So, no matter what you get out of a lunchtime chat, the best results will be obtained by understanding what your customers are looking for. This can be tough, as the software engineering team is usually further down on the org chart, buried in work and not often able to freely interact with clients, but this is where your Scrum Master can help. Her job, after all, is to facilitate your and the rest of your team’s creating the best solution possible and to remove impediments to your success. Let her do her job.
Gathering Information
Rather than just sending out a bunch of open-ended questions to your customers and vacuuming up anything and everything they have to say, a common current technique is to use card sorting, derived from when 3 x 5 inch index cards were used to collect information about tasks a client wanted included in their project architecture (Figure 7-4).
Figure 7-4. Card sorting is a simple method of identifying, categorizing, and organizing your customer’s task requirements
The process is very straightforward. You, based on the requirements handed down through the initial customer interviews, should have a list of tasks that your system needs to perform. Remember, at this point of the process you’re playing the role of UI/UX designer. You’re not writing code. This is particularly important if you are running your own one-person shop as a company or contract developer. Even if you work for an engineering team in a larger development organization, these techniques and your understanding of them will serve you well in the early stages of development.
You write the name of each of those tasks onto a card. At the end you’ll have many cards, potentially hundreds, one for each individual task. Try to make the tasks as simple as possible, and don’t pre-organize them. That’s what we want our customer to do in order to give us the basic structure of our information architecture.
You give the cards to your participants, generally the customer or their representative, and allow them to organize them into groups of similar tasks. Once the sort has been completed by the participant, look for stacks of cards that have a large number of tasks and break them into smaller groups. Generally, about ten cards per stack should be the upper limit. Once you have a nice breakdown of tasks, let the user name each group to see what they come up with. This gives tremendous insight into how they think about the problem based on the task list that you provided. This is the heart of the interactive feedback that is so integral to the agile process.
Be sure to, as much as you can, watch and learn as your participant arranges and groups her cards. If possible, have another team member take copious notes while you conduct the interview and sorting process (Figure 7-5). Look for areas where things seem easy and also identify where groupings give them pause. Learn from this experience not just what the groupings are but also where there exists difficulty in identifying something. If your customer is having issues, then it’s more than likely that a less knowledgeable user of the app will have the same difficulty. Remember, the navigation of your app should be transparent and allow the user to focus on the tasks they need to accomplish.
Figure 7-5. When conducting a card-sorting exercise with your customer, have someone to take notes while you observe and question to get the most out of the time
After working with several participants, identify where groupings are the same, are similar, and differ significantly. Problem areas will, of course, need resolution. In some cases, it might be that one or two individuals were simply not familiar with that part of the architecture and purpose of the tasks. These issues can often be resolved through renaming, a breaking down of a task or tasks into more fundamental levels, or even grouping smaller tasks into a more common set of tasks.
What comes out of all this—that is, the sorted set of cards with task names—is your information architecture, which defines the organization of your user experience.
Organizing and Understanding the Information
After each session with a participant, record the groupings they came up with into a spreadsheet. A simple way to do this is to use the participant name as the column identifier, and below that create a section where you put the name of each group name they came up with into a cell. Below that cell, order the cards by the task name, or card identifier if you used one.
The next thing to do is to rationalize the group names that your participants created from your list of tasks. It might be that several participants used the same group names in their sort exercise. This should give you a sense of when things worked and when they didn’t. For example, if just about everybody grouped tasks that dealt with providing information about the company under the category “About Us,” then it’s quite likely you should consider that as part of your information architecture. Most often you’ll see a lot of similarity to existing apps that function similarly. If group names differ, look for synonyms that are used elsewhere or look on a site like thesaurus.com to give you more generalized ideas for your architecture.
Another thing to consider is how most participants described the groupings. Did they label them as actions or as descriptions? You’ll then want to consider groupings as either verb-based or noun-based, respectively. Remember, the tasks have already been defined through the early stages of the agile process. What we’re doing here is organizing those into the way in which the user will interact with them; we’re creating the user experience.
You probably recognize that what we’ve discussed so far is very success based. By that I mean that we’re assuming that most users will do a lot of the work for us by organizing and creating group names that we can use. While that is the ideal situation, it’s not always the way things work out. This is where you have to have some flexibility, as well as be able to gauge your participants’ understanding of what is going on. If a participant isn’t likely to ever use or have understanding of one type of task grouping, don’t weigh their organizational structure quite as heavily as you might for someone more knowledgeable in a particular area. Though this may seem a bit counter to the idea of getting everyone to understand how to use the app in all cases, in reality, it’s just not always possible to make things perfectly usable for everyone.
Computer-Based Sorting
Though some people find the tactile nature of working with actual index cards to be very beneficial, and I count myself among them, the time involved in converting and entering the data into spreadsheets can be a hassle as well as a potential source of information corruption. Fortunately, applications exist for doing this using a computer.
xSort provides a very simple way to perform card sorting using your Macintosh computer (Figure 7-6). However, you’ll need to be with your participant to effectively use xSort. Also, the app does not come from a recognized Apple developer, so you’ll need to open your security options to allow it to function (Figure 7-7).
Figure 7-6. xSort for the Mac provides a free, very simple, and quick way to manage the card-sorting process when you can be face-to-face with your participants
Figure 7-7. To use xSort you’ll need to allow your computer to open the app specifically, which could put your Mac at risk. Personally, I avoid this type of situation
Most companies that are serious about using the card-sorting process with their customers will use an online subscription service such as OptimalSort from Optimal Workshop ( https://www.optimalworkshop.com/ ). They currently offer pricing monthly, yearly, or by survey (Figure 7-8).
Figure 7-8. OptimalSort offers a variety of pricing options depending on the needs of your analysis
You can go to their website and even work through an example to get a sense of how easy it is to use. Tasks are listed along the left-most column, and all you do is drag and drop each task somewhere in the middle. When you start a new grouping you just label that group as you deem appropriate (Figure 7-9).
Figure 7-9. OptimalSort i s easy to use and follows the hands-on card-sort model we’ve been describing, but also allows remote surveys to be conducted by your team
Remember, the goal of card sorting is to define the information architecture that becomes your user experience. Your goal is to organize the user’s interaction with your app so they can access the data they need and perform the tasks they choose while keeping the navigation as transparent as possible. Let the structure of the data, the IA, dictate what the user experiences. Use domain knowledge experts to show you what that architecture is so that your UX is built exactly as it is needed.
Problem
Once we have the user experience, how do we use that to create the user interface (UI)?
Solution
If you’ve started your own app development company or been hired as an independent contractor whether directly or using an online service, you’ll need to handle your customer’s user interface needs. If you work for an iOS development organization, then most of the time there will be graphics designers who focus on developing the UI, and you’ll only need to interact with them.
In most cases, particularly at major development companies, because of their background the graphic designer will use the tools with which they are most familiar. As you may already suspect, this will likely be products from Adobe such as Photoshop and Illustrator . But, for smaller operations where you need something really fast that is focused on your type of development, a good bet might be something less generic and costly that is tailored specifically for your needs. A non-traditional tool such as Balsamiq Mockups may provide you with an efficient and cost-effective alternative to the hundreds of dollars required to buy the latest copy of Illustrator and/or Photoshop.
Because this book is focused on software development tools and processes that you’re likely to encounter throughout your iOS career, I’m not going to teach you how to effectively use any one tool, as there are so many variations as to how things are done in any organization. For example, if you’re out on your own as a developer and stick to small projects, there’s no reason at all that you can’t effectively create your UI using graph paper and a pencil (Figure 7-10). Choose based on your needs, resources, time, and skill set.
Figure 7-10. A simple UI layout the author created using graph paper and a marker
I recently worked on the development of an app for an online dance card. The first iteration of the UI is shown in Figure 7-10.
If you don’t know, a dance card is a form given out at a dance event, usually to the ladies; gentlemen would approach her and pick a dance that they would do together later in the evening (Figure 7-11).
Figure 7-11. A typical paper dance card
My concept was to automate this using smartphone technology, WiFi, and broadband interconnectivity as well as local peer-to-peer (i.e., Bluetooth Low Energy) to allow anyone to request a dance from anyone else at the venue. The music schedule for the evening these days is not set, and quite often people will request a particular song or style that they’re comfortable with. Thus, the music list changes dynamically throughout the evening. At my venues, the music is managed on the DJ’s laptop and has wireless connectivity, so the songs are available to be identified. Combined with wireless access, a social networking (e.g., Facebook) mechanism for connecting, and true peer-to-peer so that anyone can ask anyone else, I created a very easy-to-use method for getting more dances throughout the evening.
If you were ever at a junior high school dance, then you probably know the feeling of rejection when no one asks you to dance or, if you’re a boy, the fear of asking that pretty girl to go out on the floor with you. MyDanceCard, the name of this app, solves that.
As an example of how this might be laid out using traditional tools, Figure 7-12 shows my initial login and signup layout I created using Adobe Illustrator.
Figure 7-12. My app’s initial login and signup UI layout using Adobe Illustrator
Going into the details of using Illustrator, even just focusing on iOS UI, is far beyond the scope of this book, and there are so many other resources that include pre-defined illustrator (.ai) elements that you can buy or get for free to lay out your design. Remember, you’re not creating the actual UI that runs on an iPhone; you are creating the wireframes—that is, the visual representation—of what the iOS developers will create and build in Xcode.
Balsamiq Mockups for Rapid Prototyping
Years ago at an iOS meetup I attended, I saw a presentation on Balsamiq Mockups , a fast, easy-to-use, low-fidelity tool for creating UI wireframes. Back then it was free, but as of writing, it costs $89USD for a single-use license that allows three users to have access. This is the perfect tool for creating my wireframes, as I operate independently most of the time, and even though I am pretty proficient with Illustrator, Mockups offers some really neat advantages over the Adobe product.
The reason we create wireframes in the first place is to follow our agile process through prototyping and save time by not committing to something too early in our development. With a prebuilt set of components and Mockups-to-Go, an active repository where other Mockup users can contribute their components (Figure 7-13), Balsamiq makes your UI design come together quickly and easily.
Figure 7-13. Mockups-to-Go offers a large set of free iOS and Watch components for you to use in your UI design
Because you’re creating a low-fidelity design, the reviewers will be more likely to provide honest feedback, and your work will never be mistaken for a final design. Continuing with the dance card app I’ve been discussing, you can see how I implemented in Balsamiq the login UI that I previously created with Illustrator (Figure 7-14). Note that in this version I’ve added actual images of one of the dance venues as well as a Facebook login. Even with actual images as well as the characteristic Facebook appearance, this UI would never be mistaken for a final design.
Figure 7-14. The dance card app’s login UI design using Balsamiq Mockups
You can add as many screens as you need as well as notes to clearly address the intent of any or all UI elements (Figures 7-15 and 7-16).
Figure 7-15. You can create multiple images showing the result of a user action with annotations
Figure 7-16. You can show both portrait and landscape UI layouts
Finally, Mockups offers a crude simulation capability to allow you to test the movement from one screen to another when activating a control surface. In Figure 7-17 you can see the properties for the selected button element, “Sign in with Facebook.” I’ve defined that link to be the Balsamiq page danceCardPlaylist, which is the page shown in Figure 7-15. So when we run the simulation, pressing that button will take us to the venue list page.
Figure 7-17. You can add links to control elements to create simple UI simulations
You run a simulation in Balsamiq by going to full-screen mode (Figure 7-18), where you get the hand cursor indicating an active control surface that you can use to walk through your UI and, to some extent, your user experience.
Figure 7-18. Balsamiq Mockups provides a rudimentary but effective way to walk through your UI design to show your reviewers the user experience
Summary
In this chapter we’ve briefly covered the aspects of user interface and user experience design that you’re most likely to come across in your career as an iOS developer.
Because the UI and UX are the first things a customer or user of your app will see, it’s critical that you make a good impression. But impression does not equal glitz and fancy colors or pretty control pictures. The impression you want to make is that your app is intuitive and easy to use. Your goal is almost for the user to not notice your hard fought efforts but to simply and easily use the app to get the task done.
While the look and feel of the app is certainly important, you want to achieve the easiest and most understandable user experience possible. Again, you don’t want the customer to think about it; you just want them to use it. Taking that into consideration, we focused heavily on information architecture, which is essentially your intended user experience. Through an interactive process with your customer or their representatives using techniques such as card sorting, you get the best information possible from those most knowledgeable about the product. By allowing them to sort and categorize the tasks early in the development process, they can participate in the creation of the user experience, allowing you to create the best product possible in the shortest amount of time.
Finally, we talked about how you would create a user interface from the analysis of the user experience and user stories. Depending on your needs and whether you work independently or for a large organization, you might choose to use paper for a quick design, usually best when dealing with an app with only a few screens of information. In a larger development organization with a true graphics department, tools such as Adobe Illustrator would most likely be used. And, if you’re a small independent developer and can’t afford or don’t have the time to learn the Adobe suite, look at a rapid prototyping tool such as Balsamiq Mockups. You get a quick, easy-to-learn tool with lots of user-contributed components for just about anything you might need.
But remember—whatever you come up with, the goal is not to make it pretty but rather to make it something your customer wants to use.