From Cranky Product Manager:

Seems that we software product managers and marketers are not so different.  In fact, we are way worse.  If a software company has shipped product for more than 5 years, the product/package/price list probably has 100+ lines, each with its own method of calculating price and with multiple dependencies between items.

And we are thereby annoying the heck our customers. The complexity of our product lines:

1. Forces repeat customers to spend time they don’t have researching purchases for products that they already know quite well
2. Increases customers’ workload, by preventing them from delegating the purchase
3. Makes customers feel like they’re being taken advantage of
4. Makes customers feel like they’re not being respected or understood.

Seems like common sense…here’s what Don Norman says:

I found the traditional "white goods" most interesting: Refrigerators and washing machines. The store obviously had the Korean companies LG and Samsung, but also GE, Braun, and Philips. The Korean products seemed more complex than the non-Korean ones, even though the specifications and prices were essentially identical. "Why?" I asked my two guides, both of whom were usability professionals. "Because Koreans like things to look complex," they responded. It is a symbol: it shows their status.

…

Why is this? Why do we deliberately build things that confuse the people who use them?

Answer: Because the people want the features. Because simplicity is a myth whose time has past, if it ever existed.

There’s a certain audience that loves Apple’s pricing model for OS upgrades. And there’s another audience that wants to drive to the price that fits their needs (Microsoft). And they want to be told about every feature that’s in the product, whether they are going to use it or not (Check out BlackBerry’s site if you want a perfect example).

Users want a pleasurable experience, but they want things, as Don Norman points out:

Marketing rules – as it should, for a company that ignores marketing is a company soon out of business. Marketing experts know that purchase decisions are influenced by feature lists, even if the buyers realize they will probably never use most of the features. Even if the features confuse more than they help.

What’s your poison?

 Comments | Comment

Or, Design Your Own Mobile Application With These Nine Easy Steps…

2011 is the year of mobile.

This year is the tipping point that’s really going to turn the World Wide Web into a “platform doesn’t matter” medium.  If you’re doing User Experience and you don’t have a mobile app in your portfolio, you’d better get cracking.

We’ve been working on a few applications as prototypes (iPad, iPhone, and Android), and I’m at version 1.1 of Pick An Excuse (finally iOS 3 compatible). I’ve made a few mistakes along the way but have found that designing apps for mobile devices isn’t that difficult.

If you have even an inkling of an idea, you should work on your own application — just for the experience. Mobile applications are just that — applications — aren’t as hard to design as you would think.

It’s All about Context, Baby

I do all my best user research at the local bars here in San Francisco, California. It’s a fairly connected crowd, and there’s always someone that has a device out. They always have an opinion about their phone, because people identify with their devices more so than other technology. Think about it, when’s the last time anyone talked about what television brand they own?

Watching people use devices at Tony Nik’s is one of my favorite pastimes. They send instant messages, answer emails, and check on local restaurants, all while having a Dark and Stormy. Fascinating.

Why?

It’s because of the context. They aren’t sitting at home eating Bon Bon’s while using the phone, they’re at a bar, at a restaurant, at work, or somewhere else.  The phone may not be the primary focus of their attention.

The fun thing about it is that all I have to do is ask a few questions, and they’ll tell me everything they love about their device — without having to buy them a drink.

Keep It Simple

There’s nothing worse than downloading an application that’s overly complicated. I was asked to download an application that did some really cool things, but it required quite a few clicks to get around. It was obvious the developers weren’t optimizing for the user experience and was stuffing as much functionality in the app as possible. Sometimes the best applications do one thing really well.

My advice: come up with something that’s silly or fun and that doesn’t have any profit potential whatsoever. My application is a wonderful conversation starter that compels me to grab people’s iPhones and download the application (and I’ll be doing the same for Android too!).

Additionally, set a budget for how much you want to spend. There’s nothing that makes you want to limit the feature set more than spending your own money.

Make It Social

It’s a phone!

It’s for talking (or texting) to people!

It’s a social device!

It’s connected to the Internet, dammit!

The Pick An Excuse application is extremely social. You can send excuses to friends, share on Facebook, tweet excuses, and send them as texts. Most of the best mobile applications have some kind of social component (Foursquare, Facebook) that allows for some kind of integration and/or mashup.

There’s also a ton of services out there that have almost open APIs that allow you to pull in interesting data.  For example, Yelp! allows you to pull in reviews as long as you credit them. Foursquare has a bunch of APIs. There are many ways you can create an application that pulls data from different sources, make it fun, and have it seem complete and polished.

Adjust the User Experience

There’s nothing worse than pulling up a website, and you can’t read the small type on a mobile device.

You’re designing for a device that’s not much bigger than the size of a business card.  Additionally,  Most of the applications that should be designed for it need to be able to be used with one hand. There’s always the other hand holding the device, so designing for simple interactions is they key. Swiping is good, typing is not.

Surfing the web or using an application is a completely different experience. Certain things don’t work. For example, you can’t really hover over things, so you don’t have to design for those interactions. Lots and lots of typing is a pain in the neck on most devices too, so you have to simplify purchasing to the exact information you need. Large websites are a bad idea, because too many clicks mean pages that will never be visited.

The design has to be flexible too (Oh my god, we’re back to multiple browsers! At least most of them are using WebKit), but it’s mostly around the width of the device to make sure things line up.

Don’t Reinvent the Wheel

One of the troubling things I find about a lot of mobile applications is the need to design a “different” user experience. Apple has provided this wonderful library of features, icons and user experience guidelines, and yet I see applications that have icons in a different location and custom actions that aren’t nearly as easy as they should be.  Let’s be honest, Apple knows better.

Unless you’re designing a game that requires an immersive experience, using a paradigm that’s different from all other applications means the user is going to have to relearn your application.

That’s not necessarily a good thing.

Apple’s gone to the trouble of producing top notch guidelines that almost guarantee a good user experience. The closer you get to the standards, the better chance you have getting the application approved on the first try (I did). That’s very important in keeping the cost down.

Why reinvent the wheel (and piss off Steve Jobs in the process)?

Mobile Necessarily Doesn’t Have to Be Native

One of the big assumptions about developing for mobile is that the applications have to be in the iPhone application store to gain traction. It helps, but it’s not true. As the mobile revolution takes place, you’ll see more and more websites that have a separate display for mobile devices.

Granted, most of them aren’t very good now (go to MSNBC now to see an example), but as time goes on, people will get better at designing for mobile.

One of the next applications I’ve been working on is actually a mix of web and native. We’re using the WebKit container to display the content and native functionality for some of the features. It creates this interesting hybrid where you have the flexibility of the web with some of the speed of a native applications. For example, we’re caching many of the images and the CSS.

Even though it’s technically a web page, it looks like a iPhone application.

And that’s cool.

Mock It Up in HTML (HTML5 Even!)

The best thing about the device is that it can connect to the Internet. That means you can mock up the user experience with simple HTML pages, and test it on your phone. Apple has produced a kick-ass guide for developing for the iPhone, and you can replicate much of the experience as you would have with a native application in HTML. You can come up with the idea yourself in rough form, and then show it to a developer when done and say, “Hey, this is what I want built.” There’s nothing better than a visual example.

Mock it up.

Test it with friends.

Repeat.

Because it’s a mockup, it doesn’t have to be perfect, but you have a pretty good idea if it’s going to work or not. That way, you can work out some of the ideas before you get to development, and that will save you time and, most importantly, money.

Get a Technical Architect

Here’s my story:

The worst thing about new technology is there are all these small details you have to consider before implementation. I ran into that with the first application I designed, Pick An Excuse.

The implementation went well. I gave them pixel perfect mockups, and for the most part, the implementation went pretty smooth.

And then…

The application was designed for iOS 4, which cut out half of the market. There wasn’t a single iOS 4 feature.  A bunch of my friends wanted to download the application, but couldn’t. The application didn’t have a single feature in it that required iOS 4, yet I had to pay my offshore firm to downgrade it.

This was because I didn’t discuss what I wanted exactly at the very beginning. It would have been nice if that was a question I was asked during development, but it wasn’t.

The solution: get a strong technical architect that you can discuss every detail with. Devil is in the details especially in the mobile world. I have one now, and we discuss everything about the experience. He’s great, because he fights for the user too.

Have Fun with It

Remember, it’s your passion project (and your money).

Have fun with it. Experiment and play, because there’s nothing better than pulling out your phone out at a bar.

 Comments | Comment

There’s a really interesting marketing message in there.

 Comments | Comment

 Comments | Comment

Doug Bowman on Design at Google:

Without a person at (or near) the helm who thoroughly understands the  principles and elements of Design, a company (Google) eventually runs out of reasons for design decisions. With every new design decision, critics cry foul. Without conviction, doubt creeps in. Instincts fail. "Is this the right move?" When a company is filled with engineers, it turns to engineering to solve problems. Reduce each decision to a simple logic problem. Remove  all subjectivity and just look at the data. Data in your favor? Ok, launch it.  Data shows negative effects? Back to the drawing board.

That data  eventually becomes a crutch for every decision, paralyzing the company  and preventing it from making any daring design decisions.

Yes, it's true that a team at Google couldn't decide between two blues, so they're testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. I can't operate in an environment like that. I've grown tired of debating such minuscule design decisions. There are more exciting design problems in this world to tackle.

Part of a great deck. Everyone should download it.

My editorializing — the change in CEO doesn’t really address these comments, because it seem to be inherent in the culture.

41 shades of blue is the wrong thing to test.

 Comments | Comment

From UX Matters:

In his  Alertbox post on "Mobile Usability," Jakob Nielsen points out a number of constraints affecting Web site use on mobile devices: small screens, awkward input, delayed downloads, and poorly designed mobile Web sites. In comparing the design of mobile Web sites with the design of Web sites for computers, I realized that complex context is another important factor that differentiates the two platforms.  For Nielsen's report, controlled usability testing in a lab was one of the primary methods for studying mobile usability, so it's understandable that his report didn't consider context.

…

In addition to the four problems Nielsen wrote about, I'll cover design for complex contexts of use in my discussion of constraints on mobile Web sites. In practice, being aware of these constraints lets us approach these problems with caution and come up with better design solutions for mobile devices. Based on my analysis of more than 20 mobile Web sites, I'll point out some ways of working within these constraints.

Great article.

 Comments | Comment

From Smashing Magazine:

Peter Drucker is one of the most influential business writers of the last century. His ideas have shaped the ways we conduct business today. One of Drucker's main ideas was the notion that without a customer, there is no business. Furthermore, customer satisfaction is the key to the success of any business, or in his words: "The single most important thing to remember about any enterprise is that there are no results inside its walls. The result of a business is a satisfied customer."

…

The quest for good customers starts early on. It starts with deciding who your ideal customer is. Different companies have different ideals and cultures, and a variety of parameters are important for making this decision

The list of parameters is really good. Read on…

 Comments | Comment

Some interesting notes in this:

I'm fascinated by the way Facebook operates.  It's a very unique environment, not easily replicated (nor would their system work for all companies, even if they tried).  These are notes gathered from talking with many friends at Facebook about how the company develops and release software.

It's been over six months since I assembled these observations and I'm sure Facebook has continuously evolved its software development practices in the meantime.  So these notes are probably a little bit out-of-date.  It also seems like  Facebook's developer-driven culture is coming under greater public scrutiny.  So I'm feeling more comfortable now about releasing these notes…   HUGE thanks to the many folks who helped put together this view inside of Facebook!

…

During monthly cross-team meetings, the engineers are the ones who present progress reports.  product marketing and product management attend these meetings, but if they are particularly outspoken, there is actually feedback to the leadership that "product spoke too much at the last meeting."  they really want engineers to publicly own products and be the main point of contact for the things they built.

…

Arguments about whether or not a feature idea is worth doing or not generally get resolved by just spending a week implementing it and then testing it on a sample of users, e.g., 1% of Nevada users.

I wonder if this method really does scale well. I don’t think it would work everywhere. But, they do test. That’s amazing.

How many other organizations really do?

 Comments | Comment

And the answer is…Facebook isn’t good at it:

This is something I never considered, and she clarifies that people only find it useable because the value they get from using it is so high that they are willing to jump over a terrible barrier to use it, and it is so sticky so it’s one of those sites that can have terrible design that people still get used to and manage to learn via rote [like early LiveJournal, if anyone is familiar with that].

She says that she hears from nearly everyone she knows [who doesn’t work at Facebook] that the site is confusing and that it is impossible to find where anything is or how to do anything at all.  I do notice that in many cases I need to show her how to do things that many of us Facebook employees don’t think twice about.

…

So: this worries me on two fronts – that Quora’s design may be silently-failing shutting out an entire large demographic (my wife is typically muchmore representative of the average internet user than I am; I am pretty much a total freak), and that Facebook’s highly-opinionated, highly-insular design culture has perpetuated a site design philosophy that’s endemically confusing to not just a non-trivial segment of the population, but possibly a  majority of the internet-using population, and it’s been masked by the site’s utility and stickiness.

Does that make Facebook the world’s tallest midget?

Read on.

 Comments | Comment

Great chart. This is freelance work in one diagram.

 Comments | Comment

From Business Insider:

Microsoft’s upstart search engine now delivers results that are just as good or slightly better than Google’s, according to a post on Search Engine Land by a marketing manager for legal directory Avvo.

Conrad Saam conducted 20 searches on both Bing and Google, avoiding easy navigational searches like trying to find the right URL for a particular company. Instead he split searches between tough informational questions, like “attorney Tom Brady,” which Google mistook for a query about the famous NFL quarterback, and transactional searches like “Cheapest flights Seattle to Launceston”. Then, he subjectively rated the accuracy and authority of the results.

Bing won.

Proof being the best doesn’t mean you get branded as being the best.

 Comments | Comment

From Yishan Wong:

OpenID simply stands no chance.  It is like saying to people, “Hey, I notice you have a lot of keys on your keyring.  Wouldn’t it be more convenient if you could unify them all so you wouldn’t have to carry all those keys?  (sounding pretty okay here so far…)  All right, here, instead of using those keys, you should take this  extremely convoluted and foreign-looking mobile phone, into which you have to insert all of your keys, type in a special password, and then oh, well, it works on most locks but not all of them, so you’ll only be able to replace some of your keys with it, so now you should carry this new weird mobile phone on your keyring too.  Also, it doesn’t work as a phone.  And it has other companies’ brand names printed all over it.  And it calls one of those companies whenever you use it.”

OpenID is not flawed in some minor product way that requires just a few tweaks, it is so massively flawed (perhaps in its very conception) that anyone in their right mind would immediately know that it could never possibly be successful, the very notion that there’s merely “something wrong” with it is a Joseph Goebbels -“Big Lie”-style question wherein the nerds who came up with it have somehow been brainwashed into thinking that it could somehow ever be a viable thing that real people would want to adopt.

Well said. Read more.

 Comments | Comment

This guy is going to get a job because he deserves one. Here’s the video — the “do no evil” Googleites required that you go to YouTube to view it.

Social media made it possible.

I love the internet.

 Comments | Comment

I’m involved in something called the Product Design Guild in San Francisco. It’s pretty cool. We talk about ideas and do guerrilla usability testing of concepts. There’s a really smart group of people there, and they know great products only come out of testing an idea over and over again.

At one of the events, I’m “training” developers and product types in usability testing for a number of startups. The document I wrote I think is good enough to share and explains the basics of conducting usability tests. I’m convinced anyone can be trained to do it or at least write the test. Usability tests don’t have to be really fancy — only digital agencies looking to bill or drain the retainer would do eye-tracking on a half-baked idea — and the feedback you get is incredible.

Here’s the document for download in Word format.

Step 1: Write The Usability Test (With Tasks that Actually Work)

• Create five tasks you want the user to perform.
  The task should require at least six to nine clicks to complete the task. The tasks could be signing into the system or uploading photos and setting permissions.
• Write scenarios for each task.
  You should explain the task without telling the user what to do. An example would be, "You were at a family picnic where you took photos of your nephews and nieces. You want to share those photos with your family on the Internet on Flickr. Where would you go to sign in, upload those photos, and set the preferences so only your family can view them?"
• List follow-up questions you might want to add.
  The magic of usability tests are the answers you get outside of the scenarios. So you might want to come up with additional questions within the screens you are testing.

Step 2: Find Participants of All Sizes (Sort of)

• Find people that fit your target audience.
  Very few sites have a target audience of "everyone.” Ideally, you would test people that would use your site. In the example above, you want to use people that liked sharing photos with their family and friends.
• Find people with a range of experience.
  If you find five professional photographers that share photos constantly, you'll get a narrow view of how your site is performing. It's best to find users that could be both expert users (a professional photographer) and users than might not have as much experience (an uncle that just bought a camera and uses Facebook sporadically).
• Find people that will HATE your product.
  There’s nothing worse that running a usability test and the user (read: idiot) using the mouse gushes about what they like, and they still can’t figure out where the login button is. The best suggestions I’ve gotten have been from users that provide more negative feedback (“You know, this is done better on this other site”) than constantly good feedback.

Step 3: Perform the Usability Test (In 60 Minutes or Less)

• Do a dry run.
  There's nothing worse than finding out on the first test that your script doesn't work. Before you jump into the testing, you should run through the test before performing it in front of test subjects. Be sure to work out any software or site issues before doing it in front of users.
• Vary the tasks and keep the tests in the 15-30 minute range.
  For the purposes of most applications, you'll be testing three of five tasks with each user. The longer the test, the more often the user will get bored with doing the test. Keep the tests short and snappy.
• Do not guide the user.
  Use words that explain what they need to do, but are not contained within the site. Say "sign in" instead of "login.” Use "find files" on the hard drive instead of "browse.” Remember that you are testing the terminology the site uses as much as the design of the site.
• Ask questions.
  The beauty of usability testing is that you can ask questions that are also outside of the test. You don't necessarily know where the user is going to go. Instead of simple yes/no questions, ask open-ended questions, like "What do you think this would do?"
• Let them talk.
  People are amazing – once they start talking. They'll tell you all sorts of things. I've had participants tell me their complete business process, including profit margins, during tests. The best feedback is sometimes outside of the what I was asking.
• Record the sessions with some kind of screen recorder and take notes.
  I've used everything from Camstudio to WebEx to record results, but sometimes the best way to take notes is simply pen and paper. Don't get hung up on the tools. Eye tracking software is ideal but also expensive. You can get close to the same results just by recording what the users do with screen capture software.
• Record the results on a range of pass/fail.
  In the past, I've used the pass/fail method on a task but found on a scale of 0 (they passed) to 3 (they couldn't find anything) was a better approach to grading tasks on a step by step basis and in aggregate.

Step 4: Evaluating the Results (By Reading the Tea Leaves)

• Look for patterns.
  A focus group of one is not a good thing – too many usability professionals and product managers do this. I tend to discount those as preferences for that particular user. If two or three users say close to the same thing ("The button is hard to find."), there's a usability issue you may want to look at closer.
• Highlight comments that can make your site better.
  The best feedback from testing is something that you didn't expect. Highlight some of the comments that might be outside of the tasks but make great sound bites for describing issues with your site.
• Remember results are subjective, so discuss them with the team.
  Put a team of three usability professionals together, and sometimes they'll come to three different conclusions about the test. Ideally, you could combine qualitative results with quantitive results (i.e. stats from watching the conversion funnel).
• Combine testing with other data collection methods.
  I sometimes use a site called Attention Wizard that calls itself a visual attention prediction tool to see where users might click based on contrast of color values. If you combine testing with other validation methods, you'll get better results.
• Test your assumptions again.
  Testing is not a one-time thing. You should test as much as possible (I've tested as much as every two to three weeks in an engagement), because the more you test, the more you get to refine your product. I’ve had a couple of clients where we tested over 15 users with different tasks, creating a great amount of data that helped in product design.

Extra Credit: Other Resources

Other Blogs

• A List Apart's Guides to Usability Testing
• Discount Usability Testing; 20 Years
• Example Usability Questions
• Budget Usability Testing
• Start A Usability Testing Program In Five Days

Free Software

• Camstudio – PC/Free
• Silverback – Mac/Free for 30 days
• Screencast O Matic

 Comments | Comment