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.

Don't Be Too Hasty To Do-It-Yourself or Pick-Something-Off-The-Shelf

A common question I get from folks that want to create an app or website with a backend system is what I would recommend they choose for a toolset. Should they use something baked into the platform like iCloud? Should they use a multi-platform service like Parse or Heroku? Should they write their own backend system from scratch?

The answer? It depends.

Honest. That's the truth. That's not an attempt to evade the question.

Rather than immediately jumping to answer the question, I always ask my own question to gain more context:

What are you trying to accomplish?

There are two different ends of the spectrum for that question. On the one hand, you have the Marco Arment (formerly of Tumblr and Instapaper) camp:

The common wisdom, which Justin suggests, is to go directly to a highly abstracted, proprietary cloud service or a higher-level hosted back-end — the kind that are so high in the clouds that they call themselves “solutions”. But the “BaaS” landscape is still very unstable with frequent acquisitions and shutdowns likely, and hosting on VPS-plus-proprietary-services clouds like Amazon Web Services or higher-level services like Heroku or App Engine can get prohibitively expensive very quickly. Developers who build everything on these services by default would probably be shocked at how cheaply and easily they could run on dedicated servers or unmanaged VPSes.

On the other hand, you have the Brent Simmons (Q Branch / Vesper) camp:

Well, my first thought was I don't want to run an actual server. I don't want to do that. Life's too short; I have to write code.

I often see debates on Twitter, blogs, or podcasts about the merits of both approaches. Depending on the particular biases of the author or host, the result is typically choosing one of the two extremes. Before jumping into one side or the other, however, it's important to understand the fundamental assumptions being made and what each side is attempting to accomplish.

The fundamental assumptions behind the Do-It-Yourself side, as exemplified by Marco, are that you are trying to create something that will need the greatest amount of flexibility and independence. By picking this extreme, you are deciding that the control over your own destiny outweighs the burden of creating and continuing to maintain your own backend solution.

The fundamental assumptions behind the Pick-Something-Off-The-Shelf side, as exemplified by Brent, are that you are trying to create something that will need the least resistance in reaching fruition. By picking this extreme, you are deciding that the effort saved by outsourcing outweighs the risk of not completely owning your backend solution.

Of course, these are two opposite ends of a spectrum. The solution that meets your particular needs will probably fall somewhere in the middle.

By all means, if you are intent on creating The Next Big Thing, then it makes sense to do things yourself and not be at the mercy of platform owners. However, if you are building something as a hobby then it makes sense to offload the things that aren't core to your interests.

It also makes sense to consider whether this is intended to be the start of a business or is intended to be a learning experience. In the former case, you have to weigh the tradeoffs between controlling your livelihood and getting to market quickly. In the latter case, you have to weigh the tradeoffs between focusing on breadth versus depth.

Folks, don't be too hasty to do it yourself or pick something off the shelf. It's not a simple decision.

Announcing The More Than Just Code Podcast

I'm proud to take part in announcing a new podcast that is now available. That podcast is called More Than Just Code.

It's a weekly show that covers topics that impact iOS and Mac developers. As the show's title suggests, we also consider the business perspective on each week's topics (i.e. 'more than just code').

The show is co-hosted by a transcontinental panel of developers: Tim Mitra, Aaron Vegh, Mark Rubin, and yours truly, Jaime Lopez.

Folks, check it out (and subscribe!): http://mtjc.fm/

Update Feb 25, 2015: New website URL, folks.

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).

Hiring for 'Culture Fit' is Absolute Garbage...and Absolutely Important

Perhaps one of the most irritating terms to arise during the current tech renaissance is 'culture fit'. What, pray tell, does the term mean?

Ostensibly, 'culture fit' is intended to mean that a potential job candidate will immediately 'gel' with the existing team. Once critical 'culture fit' has been achieved, a company will reap the benefits as the Borg-ified development team bangs out line after line of beautiful, scalable, and coherent code. Launch parties ensue, followed shortly thereafter by an IPO. Investors cheer. The team eventually celebrates being flush with success and cash by sipping Mai Tais on a tropical beach.

Unfortunately, that isn't the reality. In the best case, the team suffers from a lack of diversity and is held back from achieving great results as it becomes mired in groupthink. In the worst case, 'culture fit' is a means by which a team can turn into a members-only club that keeps out individuals who are deemed different (for example, by being women).

'Culture fit' is a terrible thing, right? Something that should inspire us all to grab our pitchforks every time the foul utterance escapes some fool's lips?

Actually, no.

Why? If for no other reason, because no one wants to work with a jerk. Making sure that someone isn't going to turn into a team cancer or a morale-killing psychopath is important. The workplace isn't meant to be an episode of Game of Thrones, folks.

Development teams shouldn't be looking for a candidate's 'culture fit' if by doing so they are only evaluating the rather shallow layer that can be quickly and easily perceived. Does this person look similar to me? Does this person have the same background? Does this person have the same interests? These questions aren't important.

What is important? A person's 'culture fit' in terms of their values. Specifically, the values that matter for the company's success. Take, for example, Atlassian's stated values. That company places an emphasis on being honest with its employees and customers. The best way to evaluate a candidate's 'culture fit' for Atlassian is to determine if the candidate shares the same emphasis on honesty.

Folks, you should evaluate potential job candidates on their competencies and their ability to embrace the company's values. Don't use 'culture fit' as an excuse to exclude people who are 'different'.

Much Ado About In-App Purchases and Arcades

Drew Crawford, over at Sealed Abstract:

See, in the in-app purchase model actually predates phones. It predates video game consoles. It goes all the way back to the arcade, where millions of consumers were happy to pay a whole quarter ($0.89 in 2013 dollars) to pay for just a few minutes. The entire video games industry comes from this model. Kids these days.

Crawford's post was in response to an article by Thomas Baekdal about in-app purchases destroying the gaming industry with the latest example being Electronic Arts' (EA) butchering of the classic videogame Dungeon Keeper. (Both Crawford's post and the original post are worth reading, and I think it is especially valuable to view a few minutes of the two videos in the original post.)

I've written about freemium as a damaging force in modern game design, so my opinion on the original Baekdal post should come as no surprise. I do appreciate Crawford's post for its content on modern app economics and Crawford's musings on potential developer strategies for navigating the various issues with app-based businesses.

However, where Crawford's post goes off the rails is the segment (highlighted by the quote above) attempting to relate today's in-app purchasing model with the arcade model of yesteryear.

The two models could not be more different.

The only similarity to be found, if you squint really hard, is in the vague notion of paying for an amount of gameplay time. The critical difference--and this is at the heart of the problem with modern freemium design--is that the in-app purchasing model has nothing to do with player skill.

Think about those old arcade games. Pac-Man. Galaga. Street Fighter 2. All of those games could be played and conquered with a single quarter if the player was skilled enough. The amount of money that a player had to pay was directly tied to his or her own skill level. By comparison, no amount of skill is going to help you acquire those Smurfberries any faster. Only cold, hard (digital!) cash will suffice.

Even the worst 'quarter munchers' like the Teenage Mutant Ninja Turtles or Simpsons arcade games had an element of skill involved. Nothing was quite as sweet as seeing how far you could get on a single quarter.

Admittedly, racing games generally fell into the 'pay more play more' model, but that was often mitigated by the game having a 'winner gets to race again without paying' feature.

Folks, claiming that yesterday's arcade business model is essentially the same as today's in-app purchase business model is akin to saying that receiving a high five is essentially the same as getting a slap to the face. I don't think I have to tell you which one is fun and which one hurts.

Quoth the Flappy Bird, 'Nevermore'

Flappy Bird, the latest iOS casual game breakout hit, has been pulled from the App Store by creator Dong Nguyen. Flappy Bird, for the few people who somehow avoided the hype, was a simple game where players tap the screen to make a bird fly over pipes that block their path. The game was renowned for its simplicity and frustrating difficulty. Players were apparently engaged enough to keep playing the game and also interested enough to tell their friends to play (ultimately resulting in the app hitting #1 in the App Store). It was reported that Dong Nguyen was pulling in $50,000 per day in advertising revenue for the game before the app was removed from the store.

Why would an indie developer pull such a successful game from the App Store?

Watching this story unfold online was a sad commentary on Internet culture and the human capacity for envy. For example:

Perhaps the worst part of this whole story is the hatred that Nguyen received from other indie developers. Time and time again, presumably jealous developers were attacking Nguyen from every angle:

• 'This game is crap that could be created in a weekend!'
• 'I spent 2.5 years on my game, and it hasn't had this level of success. Unfair!'
• 'Must be a scam. This game has been in the store for months and suddenly hits #1? Must be paying for downloads!'

Of course, now that Flappy Bird has been successful there are now a bazillion clones cluttering up the App Store. Funny how the industry works like that.

Folks, this isn't the first (or last) time that we will see stories like this.

Patch Laid Off a Bunch of People Over the Phone

Matt Burns, at TechCrunch:

The ax came down at Patch today. TechCrunch has confirmed that a number of Patch employees were let go this morning with another round of layoffs happening later today. We’re hearing hundreds were laid off, focused mainly around editorial staffing. Employees are being told to pack their virtual desks and clear the premises today.

If you haven't listened to Jim Romenesko's audio recording of the teleconference, take the time to do so. It must have been difficult for those people to hear their jobs being eliminated in a short 1m 30s.

I've said it before, folks: treat employees with respect, especially when firing them.