Gently Guiding Users to Do the Right Thing

Imagine that you are designing a mobile app that lets users add a profile picture via their phone's camera. How would you go about preventing users from uploading pictures of their 'naughty bits' as their profile pic?

One option might be to do advanced image analysis on the picture once it has been taken. This could potentially be a very good way to weed out images based on their similarity to forbidden images. Unfortunately, this adds complexity to the system since the image analysis algorithm needs to be developed internally or selected from off-the-shelf components. In addition, this design implies that the user's profile pic probably can't be added immediately to their profile. No matter how fast the image analysis algorithm is, the feature will never really feel quick.

Let's say you decide not to go the sophisticated route. Another option might be to put a warning on the screen before the camera is displayed to the user. That's a very inexpensive option since you only need a warning dialog prompt or perhaps just warning text on the screen. Unfortunately, you never want to be in a position of telling users to "Please don't poop on the tables" if you can avoid doing so. While trying to catch the small percentage of users that were going to do the wrong thing, you end up admonishing the majority of users that were going to do the right thing.

The best solution is simple: display the front-facing camera by default. The user is most likely interacting with your app in a way where their face would naturally be aligned with the front-facing camera. The path with the least amount of friction is the path we want the user to take. The user simply launches the camera and snaps a photo. No muss, no fuss.

This simple user interface design choice helps to reinforce the idea to the user that they should take a photo of their face and not their naughty bits. In fact, it would take more effort to switch to the rear-facing camera than it would be to simply tap the shutter button.

Folks, sometimes users just need a gentle push in the right direction. Trust that your guidance will lead to the desired result.

You Can Afford to Design with Affordances

There is a refrigerator at the office that has both a water dispenser and an ice dispenser. The first time that anyone new to the office attempts to dispense a cool, refreshing glass of water ends with that person being splashed with water.

Care to guess why?

The design of the water dispenser is unexpected. In fact, many people first attempt to push their cup against the curved metal plate in the back (which dispenses ice, not water). After realizing that they pushed the wrong plate, many people will push the flat metal plate at the top (which does in fact dispense water). Unfortunately for them, they usually push the water dispensing plate while keeping their cup adjacent to the ice dispensing plate. As you may have noticed from the picture, the water is dispensed from the tiny spout at the top of the dispensing nook.

The end result? Splash.

Why does this happen? Why don't new users immediately grasp how to use this dispenser? Quite frankly, because the designers of this dispenser didn't make proper use of affordances.

Affordances provide users with a hint as to how something is to be used. They take the infinite number of possible actions that might activate a feature and reduce those possibilities down to the proper actions. The critical quality of an affordance is that it must be obvious.

The designers of the water/ice dispenser made a mistake by having the water dispenser's plate be flat in shape. There isn't anything about a flat, vertically-oriented metal plate that says 'push a cup here'. In contrast, the ice dispenser's curved, vertically-oriented plate practically begs you to push a cup against it.

The ice dispenser's curved plate arguably makes things more confusing for the user than having a flat plate would in this instance. The ice dispenser's affordance attracts the user to keep their cup located in the wrong spot in order to successfully dispense water. Ideally both plates would be curved, or neither plate would be curved.

Folks, take care when designing your user interfaces. Make sure that you are creating affordances in the design that make things easier for your users. They will thank you for it.

Bonus Content:

The folks at Extra Credits have a great video on the use of affordances in game design.

Please Don't Poop on the Tables

At one point in my career, I was caught in the middle of a contentious change to an app's user interface. The app allowed users to communicate with each other about products via a chat feature. One side of the team wanted to add a disclaimer that said something to the effect of 'Please don't use Feature X to ask about blah blah blah. Use Feature Y instead." The other side of the team didn't want to add this disclaimer because 'people won't read the disclaimer and it clutters up the UI'.

I was on the side that didn't want to add the disclaimer. In my view, the reason that some users misused the chat feature (and therefore annoyed other users) is because the user interface did not make the correct choice obvious to users. Adding the disclaimer felt like we would be admonishing users for our design mistakes.

The 'add a disclaimer' side of the house was not convinced. The debate raged on for quite some time until I was able to break the stalemate with a hypothetical situation. I told my colleagues (paraphrasing here):

Imagine that you went to a restaurant for dinner. As you approach the door, you notice a sign that says "Please don't poop on the tables". Would you eat at that restaurant after reading that sign?

I suppose that the proprietor of that hypothetical establishment might have had a perfectly good reason to put up such a warning sign. Likewise, the folks that wanted to add a disclaimer had a perfectly good reason in mind. Unfortunately, the intended effect (avoiding unwanted behavior) is overshadowed by an undesirable effect (scolding users when they haven't done anything wrong).

Folks, we all know that users probably won't read the manual. The best way to handle undesirable behavior is to guide users towards the correct behavior with an excellent user interface. Avoid telling people to not poop on the tables.

Fail Faster

The fine folks over at Extra Credits have an excellent video on a topic that is near and dear to my heart: failing faster. The gist of the video is that it is important to learn how to use tools such as low-fidelity prototypes to validate an idea. The key takeaway is that you want to learn from your mistakes as quickly and as cheaply as possible. Waiting until you have the perfect idea all figured out takes too much time (and really, you won't have it all figured out). Likewise, immediately jumping into writing code means that fixing your mistakes is much more expensive to do (and you will be more hesitant to do so).

I have personally been involved in this type of situation many times throughout my career. In one particular instance, I was part of a team working on a new major feature for an app. Unfortunately, the development process devolved into 'prototyping in code' as major changes were made on a daily basis to the visual design, user flow, and business logic of that feature. This was a terribly expensive way of figuring out how things should work. When we tested the feature with a few handpicked users, the flaws in our design were immediately obvious. We thought that the design was generally good and understandable (albeit with a few rough edges), but the participants in the user testing pointed out sizable problems with the design that made it clear that this feature was not ready to ship. It's as if we were blind to our own design.

After this particular experience, I championed the idea of using interactive prototypes for further design iterations. Each design iteration consisted of 'tappable screenshots' that our test users could try out and use to provide us with feedback. Making changes to a particular screen or to the user flow was as simple as dropping in a new image file from Photoshop or designating a new tappable area on an existing screen. The turnaround time for these changes could be measured in minutes or hours instead of days and weeks. In the end, the ability to 'fail faster' with the interactive prototype helped to make the feature better in a shorter period of time than what could be done with code.

Folks, I know it can be tempting to immediately jump into code; that's pretty much what developers are inclined to do. However, understand that it may not always be in your best interests to do that. Find cheaper and faster ways to validate your ideas.

Bonus:

There are many different tools that can be used to help you 'fail faster'. These are the ones that I use on a regular basis:

• Pen and paper or a whiteboard - you really can't get much faster and cheaper than this.
• POP (Prototyping on Paper) - this app makes it easy to take a photo of things that I have made in my sketchbook or whiteboard and add tappable hot zones with transitions.
• InVision - this web app provides a lot more horsepower in terms of the transitions, collaboration, and version control that it supports. I use this with Photoshop mockups to provide a more "real" feel than what POP provides.

The Windows Store is Filled with Scam Apps

Chris Hoffman, writing for How-To Geek about app scams in the Windows Store:

Why doesn’t Microsoft care about the cesspool of garbage they’re hosting and offering to hundreds of thousands of Windows 8.1 users? The only answer we have so far is that Microsoft doesn’t care how good apps are — they’re just approving everything to get as many apps as possible. It’s been nearly two years now, and we haven’t seen any indication Microsoft actually cares about the pile of garbage they’re hosting.

The various app stores have their fair share of problematic apps. Google Play, with its focus on automated store rule enforcement, allowed a scam anti-virus app to become the #1 paid app. Apple's App Store, with its focus on manual store rule enforcement, allowed a bootleg Pokemon game to become the #3 paid app.

However, in both the App Store and Google Play examples, these scams were the exception rather than the rule. The numerous examples illustrated by Hoffman in the linked article are damning for Microsoft. While Hoffman's stated reasons for why Microsoft allows these blatant scams to exist is pure speculation, it is speculation that makes a lot of sense. Microsoft's Windows Store and Windows Phone Store are woefully behind the App Store and Google Play in terms of quality and quantity of apps. There is no subjective way to measure the former, but the latter is easy to measure (and is arguably even easier to inflate). There is a strong incentive to increase the number of apps in the Windows Store.

Folks, we all know what happens to an app store's credibility when it allows such garbage to become commonplace.

Teach Users How to Use Your App by Having Them Actually Use Your App

It's late at night. The empty cans of Red Bull tower over your desk precariously. You've done it. You've finally created your beautiful, polished, delightful app. The blood, sweat, and tears will all be worth it once you hit that delicious button to submit to the App Store.

You hesitate. You have a sense of worry gnawing at the back of your mind. 

What if users don't immediately comprehend my glorious design?

What shall I do?

I know! A tutorial! That's the ticket!

Netflix app for iOS (image via http://www.mobile-patterns.com/coach-marks)

Suddenly, your beautiful app isn't so beautiful anymore. You've decided to smack the user in the face with a brain dump tutorial.

...

Why is it that so many apps fall for this trap? The most common reasons seem to be that app developers run out of time to properly implement a tutorial system or the developers fail to realize that the onboarding experience is an integral part of the app that requires just as much design effort (perhaps even more effort) as the rest of the app. Yet, it is still common to see apps that don't give much thought to how users will learn to use the app.

Whatever feelings you may have about Facebook's Paper app, they at least took a relatively uncommon approach to the problem of teaching users how to use an app with an uncommon design. While it may be somewhat heavy-handed at times, the tutorial system in Paper clearly took a bit of time to design and implement. In fact, the Facebook Paper team gave a presentation on how they approached the problem with contextually aware tutorials.

Developers can look outside of the traditional app development industry for inspiration as well. The game industry has spent decades working on this very problem. Take, for example, this analysis of the first level of Super Mario Bros. by the folks at Extra Credits:

The game designers at Nintendo carefully crafted the first level experience to teach players the skills that they will need throughout the game. They did so without dumping a bunch of explanatory text right at the start of the game or requiring that a player read the manual.

You might very well ask, 'how can these same design principles be used when creating an app?'

For starters, you should consider what your first-run experience is like for a user. Does your app have a bunch of empty states? Design a way for those empty states to have a call to action or design the app's first-run experience so that the user doesn't have those empty states to begin with (for example, pre-populating an app with content that the user is reasonably expected to enjoy). Does your app involve a complicated ecommerce transactional experience? Design a way for users to get progressive disclosure on where they are in the process.

Folks, Super Mario Bros. doesn't bombard players with every possible bit of information they could ever need at the beginning of the game, and there is little reason why apps should be any different. Teach your users how to use your app by having them actually use your app.

Bonus:

If you enjoyed the design analysis done by Extra Credits, you might also enjoy these videos (warning, they are longer videos and may include profanity so be careful at work).

Vinyl Records and Microsoft Azure

As a follow-up to a previous post about Microsoft needing to be everywhere, I thought it would be appropriate to describe a recent interaction I had at a developer event.

As it so happens, I met a Microsoft employee and we started talking about what we do. The topic naturally turned to my job as an iOS developer for my current employer. Upon hearing that I developed iOS apps, the Microsoft employee asked me why I don't develop apps for Windows Phone. I responded that while Windows Phone is a technically solid platform, it just wasn't enough of a factor in the industry (e.g. installed user base) for me to jump onboard. I told this person that, if anything, I would probably look to Android as my second platform of choice. They seemed satisfied by my answer.

As is common in these types of meetups, we later exchanged contact information. Since neither of us carried business cards, we exchanged phone numbers. Later that evening, I received a 'Nice to meet you!' message on my phone. I went to the Messages app to respond, and was taken aback by something I noticed. It didn't say 'Text Message' at the top. It said 'iMessage'. This Microsoft employee who had asked me about my hesitance in developing for Windows Phone was in fact an iPhone user.

...

Back to the question of me getting involved with developing for Microsoft's platforms: would I actually do it as either my 9-to-5 job or as a side project? Honestly, probably not. I suppose that I might be convinced, in a fit of hipsterism, to develop a Windows Phone app while listening to vinyl records, waxing my mustache, and munching on artisanal cheeses, but it just seems unlikely. However, based on the renewed vigor of Azure (and some trepidation with Facebook owning Parse), I could easily see myself using something like Azure Mobile Services to power an app.

...

The purpose of this anecdote is to illustrate the difficulty that Microsoft has had and will likely continue to have in convincing people to use and develop for its platform. Despite an initiative to provide its employees with free Windows Phone devices, clearly Microsoft has not been able to capture the hearts and minds of its own employees with its platform. Likewise, Microsoft has a difficult road ahead of it trying to convince developers to support its platforms.

Folks, this is why Microsoft needs to focus on providing Azure-based services to the entire world. It's their best chance to stay relevant.

For Microsoft to Win, It Must Be Everywhere

We have to let go of this notion that for Apple to win, Microsoft has to lose.

-- Steve Jobs

Those words were uttered by Steve Jobs at Macworld Boston in 1997 as he described the groundbreaking deal between Apple and Microsoft.

That announcement set the stage for one of the greatest corporate turnarounds of all time. While it may seem foreign to those who came of age in the era of web apps and smartphones, at the time of this announcement, Microsoft was an unstoppable behemoth and Apple was a staggering challenger. Since that historic moment, Apple has become one of the most powerful companies in the world and Microsoft has seen its influence on the industry diminish.

How did we get here? As it has been said, Microsoft lost the API war. But it's more than just that; Microsoft twice failed to quickly adapt to major shifts in the industry. First, it was late to the shift to the World Wide Web. More recently, it was late to the shift to the latest wave of multitouch-enabled mobile devices. With each successive failure to adapt quickly, Microsoft lost more and more of its grip on the industry.

You can't show up late to the party and expect everything to be the same as it was at the beginning of the party.

Microsoft reacted to the rise of the WWW by attempting to put a stranglehold on it (Internet Explorer and ActiveX, anyone?). Microsoft saw the web--and applications that ran on the web--as a danger to its monopoly. It stubbornly refused to participate openly in this fundamental change in the industry and was left behind.

Similarly, Microsoft failed to quickly adapt to the rise of multitouch-enabled mobile devices. Instead, it stuck its head in the sand and didn't realize that the game had changed and its products in the mobile space were no longer good enough. (As an aside, this same fate befell the other juggernaut in the space, BlackBerry. Google, however, was wise enough to scrap the BlackBerry-ish design that Android had at the time and started from scratch.)

What, then, can Microsoft do to regain prominence in the industry? Simply put: For Microsoft to win, it must be everywhere.

What exactly does this mean? Wasn't Microsoft everywhere to begin with? Actually, no. Microsoft was where everybody had been but wasn't where everybody was going. The Microsoft of old was 'everywhere' by having Windows on everybody's desktop. For Microsoft to move forward, it must look further back into its past, at a time when it made software for darn near every platform out there. If you had a platform, chances were good that Microsoft wrote software for it.

It's not about apps, though. Certainly, apps help but Microsoft isn't going to be able to win the hearts and minds of developers and consumers with apps alone. Instead, Microsoft is going to have to be 'everywhere' with services.

Services are the new frontier. It's an area where its competitors are weak and Microsoft is strong (even if it isn't the strongest). Microsoft might not be able to convince developers to hop onto its Windows 8, Windows RT, and Windows Phone platforms, but if it can convince longtime Apple champions like John Gruber and Brent Simmons to jump onto Azure, then it can convince anybody to join. Likewise, consumers may not be all that jazzed about Microsoft's platforms, but they sure do love Xbox Live. The Office 365-based apps aren't doing too shabby, either.

Folks, Microsoft may not be able make a dent in the mobile space (or the upcoming wearables space), but it stands a good chance of making a huge splash in the services that power those experiences.

Selling Copies of Windows and Office is not Microsoft's Future, Redux

Remember when I said that selling copies of Windows and Office were not Microsoft's future? Well, here's a first step towards that future, courtesy of Paul Thurrott:

In a bid to counter the threat from low-cost PC alternatives like Chromebooks and non-Apple tablets, Microsoft will reported slash the licensing cost of Windows by 70 percent. But the price cut will only apply to low-end Windows devices that cost less than $250.

Traditional Video Game Consoles Aren't Dead Yet, Folks

Wow, what a difference a year makes. Last year, there were some pundits who were convinced, absolutely convinced, that the traditional video game console was doomed. Doomed, I tell you! I took the time to write about why I thought that such talk was a bunch of malarkey.

Turns out, I was right.

What has happened in the past year? Well, the Sony PlayStation 4 and the Microsoft Xbox One were released to the public, that's what happened. Guess what? Both of those consoles were record-smashing successes. Sony sold 4.2 million units. Microsoft sold 3 million units. Folks, even poor ol' Nintendo managed to have success with software sales for its 3DS handheld console (though the less said about the much-maligned Wii U, the better).

This was my statement on the reality of the console market in a post-PC, mobile device-driven market:

What then, of the rise of mobile gaming? To those who say the console is in trouble, the success of devices like the iPhone and iPad as well as the success of titles such as Angry Birds point to a future where consoles aren't relevant. This is a narrow view of the world that doesn't take into account what is happening in the industry. Mobile gaming isn't taking gamers away from traditional consoles...it is expanding the term 'gamer' beyond its traditional form. Just as the Nintendo Wii helped to bring games into the mainstream by making games more accessible to non-traditional gamers (e.g. the elderly), mobile games have further expanded the gaming market. And that's what it is, an expansion of the overall gaming market, not a reduction of the market for consoles.

Microsoft, Nintendo, and Sony combined for sales of roughly 260+ million units over an eight year cycle for the previous console generation. Yes, mobile device sales easily eclipse that figure in a shorter span of time. However, as I mentioned earlier those devices are causing the overall gaming market to grow, which is to say that they aren't necessarily causing the traditional console market to shrink.

Console gaming isn't dead, folks.