Strategy « Little Springs Design. 2001

Archive for the ‘Strategy’ Category

“ah ha” moments vs. “setting expectations”

Tuesday, May 25th, 2010

Heard a reference to this on the radio this morning. Looked it up, and the best quote I can find is from Rob Goodlatte, a product designer at Facebook who worked for over a year on the vaunted/maligned new user experience. See the whole interview for more.

...Try to figure out what the ‘ah-ha’ moment is in the new user experience. Last year, we brought in some users to test our registration flow. The tests were going all right until we got a woman who had the worst experience. Everything that went wrong did. She got a tough captcha, had trouble logging into her webmail account, and got error after error when filling out the forms.

But then something awesome happened. She got asked some basic information about where she went to high school, and in the next screen, her face just lights up because she saw someone she recognized as a suggestion. As a result, we designed an entire roadmap around that ah-ha moment.

Nowadays, we let people continue with the new user flow even if they haven’t confirmed their e-mail yet, so they can get to the ah-ha moment sooner. This boosted registration by 5%, which is phenomenal.

Another ongoing test is to eliminate everything before the a-ha moment. Just type in your e-mail and we’ll try to show you people you could be connected to. This way, you don’t lose the people who would otherwise be frustrated by having to go and confirm the account…

As far as I can tell, Facebook is all excited about their new UX because at some point in the process most people “get it,” and are suddenly pleased by some portion of the experience (they have “uh oh moments” too, but I can’t find a solid print quote about those right now). Facebook might have taken those lessons to make the “ah ha” moments appear sooner, but they still miss the whole point: users still have to put up with the system for a while before they get any payoff.

This all avoids a key mantra I was required to work from, which was “setting expectations.” Sure, some of this is social or cultural, and those with a big enough budget (Apple) can use advertising and other marketing to set expectations, but you can work on this with the interface itself.

This is so baked into UX that I can’t even find the initial reference to it, but it pops up all over. For example, here’s some Microsoft UI guidelines:

Screen subtitle
Example: You can also download a new picture from the Internet.

Even with careful effort, the screen title may not be sufficient to adequately explain a complex task. The subtitle allows you to elaborate on the screen’s purpose. You can use a subtitle to help clarify the purpose of the page, provide additional task description, or help set expectations. Users who don’t read the subtitle should be able to use the page successfully. Just like the title, the subtitle should avoid describing details for completing the task.

The same issue arises with entire UI paradigms, like how to discover gestures. This is okay if it’s a secondary feature or another way to do stuff, but what about those times the user can’t do basic things until they get to an “ah ha” moment?

In fact, I say the name (“ah ha”) is wrong. I’ve seen the same both anecdotally in real life, and in testing. It’s really an “about !@#$ing time” moment. Frustration cannot be alleviated with a delightful moment later on. The users are very likely to simply abandon the process, or your whole product. You have to set expectations, follow through, and if at all possible exceed expectations.

Posted in Design, Design Tips, Strategy, Theory, Usability testing, User research | No Comments »

apps switch a lot, devices hardly at all

Thursday, April 22nd, 2010

Looking up some obscure bit of software setup, I googled around and found it in a blog post by the developer. I’ll just quote the beginning here:

As I’ve written previously, when OS X took over long-standing Photoshop shortcuts, it created a tricky situation: break Photoshop users’ habits/flow by changing PS to match the OS, or deviate from the new OS conventions?

The title of this post is one of those key tenets we operate on at Little Springs. We apply it to mobiles, but it’s really true everywhere. The vast majority of users, in the vast majority of situations, use a single device for all their work in a particular context. They switch applications a lot, but hardly ever change devices.

Sure, they switch from phone to desktop computer, but that’s such a change most people reset their brains pretty well to the marked differences. And some people in various regions swap SIMs all the time, and have night and weekend phones that are different from daytime phones. Even those, however, switch daily. They switch apps dozens of times an hour on each of those devices.

What this means is that your application should almost always use the OS-default behaviors. For mobiles, that’s putting softkeys in the correct locations (don’t flip them), making menus look like the device menus, supporting all gestures in the expected manner, and so on. This falls naturally into our avoidance of pixel perfect design. Use rules, and define a lot of the behavior as inherited from the device, instead of being always the same (looking at you now, Opera Mini for touch devices) or only being on one device, because of the “difficulty” of designing for multiple platforms.

Okay, I am sure the Adobe guys will argue that their tool is so heavily used that it’s practically a software workstation and therefore the tool should follow it’s own conventions. I’ve spent time in production environments, using Photoshop 10 hours a day and I say that those users exist, but are miniscule population, they still use their computers for other tasks (email, time tracking, file sharing systems, other Adobe apps with /different/ UI conventions), and anyway are going to invest the time in setup and training. Offer them a simple Photoshop/OS standards option if they want. The typical user should, by default with no extra work, get the OS-level defaults.

And a few others will argue this stifles creativity. I say “try harder.” There’s a LOT more interface and interaction room left around the edges to work in. If you just have to have something unique, pick an un-used command, gesture or corner of the screen and have fun with it.

I have installed fully eight browsers on my Android device, and almost all of them are pretty Android-ish, while also being pretty different. Often, weirdly so, with gestures and tilting and so on. But the core is something I am used to, which gives me some comfort zone to learn the application, and a point of departure for the new neat parts. And when it’s not (e.g. the Menu key doesn’t do anything) I get pretty lost.

To me, there is no tricky situation, because there is no choice: design for the OS conventions, even if they change, and break your existing design.

Posted in Design, Design Tips, Gestures, Mobile applications, Strategy, Theory, UI Design Patterns | 1 Comment »

history is context

Friday, April 16th, 2010

Despite historically being a personal computer maker, Apple is clearly moving to be some sort of “digital lifestyle” company. Forget the cute name change (dropping “Computer”) and other direct comments about this. They are all self-serving and much more can be learned from examining behaviors.

A key “behavior” of a company is the products it releases. Let’s look at the highlights of these “non-computer” products:

A (mostly) ARM based platform, centered around pen/touch interaction with specific appeal to the PDA, mobile communications, networking and graphics. Add ons and applications are supported with a custom SDK, allowed them to be written relatively easily in an OO language.

Devices that support the platform include simple tablet-like PDA/entertainment devices, smartphones, ruggedized devices for verticals and larger devices with integrated keyboards.

Any of those specs throw you? A keyboard on the larger device perhaps? That’s because this is not iTouch/iPhone/iPad, but the Newton platform, and refers to the MessagePads, Seahorse, Tarpon, Schlumberger Health Terminal and eMate among the many devices made to support the platform.

And this all started in the 1980s.

I periodically rant in Twitter about the stupidity of tech pundits. Such that I often don’t read, watch or listen that much, as they infuriate me. This is exactly why. No one [well-read, that I know of] has talked about the above history in any but the slightest detail basically since it was happening.

But a straight line can be drawn from Apple’s computer platforms, though the Newtons to the iPhone platforms of right now. And if you act all pundity and think about what they did, that’s called analysis. You can come up with some useful intelligence from it.

My key takeaway from Apple is actually a public statement, the Digital Hub concept. Delivered way back in 2001, and which I think they are clearly still working from.

You get one desktop computer, you attach PDA-type devices, entertainment devices and portable devices to it. You attach to the internet. And you get to continue being productive (work) as well as being entertained. Remember, this was the Information Superhighway era and there were Info Appliances (all to often, actual appliances like refrigerators with computers embedded) proposed and sold that would do specific tasks and network in their own way. It was not clear that the general purpose computer, the PC had a future outside of offices and servers. In fact I am a failed futurist – I thought the PC was dead and we’d all have info appliances for specialized tasks, and iPad like things and smart refrigerators. Instead, we have a faster, shinier ten-years-ago sort of computer world.

Anyway, back to Apple. They are still working on this whole philosophy and it’s easily visible in their mobile platform. Who else would require tethering to a computer to get software updates? Who else would assume (not just require, but assume) that the center of your media library is the computer, not the portable device. Etc. The core information architecture follows precisely from this assumption.

And – without getting too deep into it – their strategy for OS and application control has been unchanged since at least the Mac Clone business was killed in 1997. This extended straight to the portable platforms (nothing at all on the iPods, and strict control only when the market clamored for, and hacked into, ANY openness on the iPhone platform). Even before this, the little Pippin software was all routed through Apple. It even informs Apple’s own apps, like the iWorks suite; pretty, but built from a singular point of view. Trying to move outside the intended scope is difficult or impossible.

It’s not a shock. It’s not a regrettable surprise. And no matter how much I like to argue they could add something like an “untrusted app” feature, or better type controls, or a color picker that isn’t insulting to colors, without sullying their brand, it’s really not likely. Because this is now baked into the DNA of the company.

We spend a lot of time developing this knowledge at Little Springs. We have a wall of old phones and spend a lot of time showing what even 2-3 year old devices worked like to the sometimes annoyingly young staff members and interns. Some of us have been in mobile specifically for over a decade, and that’s just forever. Just myself, I’ve been on projects for the first musicphone “ever” and the first camera phones in the US, and built an app store something like 10 years ago.

All of this we try to keep in mind, and pass on to the rest of the company, and when we get our act together, mention in the blogging and on the wiki so everyone in the world can share in it. The next time you are trying to figure out something, ask one of the old timers around your office (or, email us I guess) to cast their mind back, and see what you can learn from the not-really-very-old history of technology.

And it doesn’t just make you feel good. Knowing what has been done in the past helps you exploit the concepts, or avoid those mistakes if they are fundamental (e.g. not just that the technology wasn’t advanced enough yet). Knowing what the competition is doing lets you predict their next move, and understand their current moves. For example, I’d say you are totally safe assuming Apple will continue to place the Mac at the core of their strategy, and protect it at significant cost. If you can exploit that, you have a leg up; you can design and market for the appropriate niche.

This works for any product – I just used Apple as a well-gossiped case. What are you competing with, or wondering about, or building that you think is all new? Are you sure it’s totally fresh and new? Are you sure you understand the competition as well as you can?

Posted in Business, Design, Strategy, Theory | No Comments »

micropayments and so-called micropayments

Wednesday, February 24th, 2010

Somewhere in my Twitter feed, I was pointed to Rita McGrath’s Why I Hate Micropayments on Harvard Business Review. A nice read, and points to several problems. But I’m not ready to throw the baby out with the bathwater.

When originally conceived, micropayments were pennies, fractions of pennies, or maybe small fractions of dollars. This has unfortunately migrated into $0.99 or even $2.99 “micropayments.” Maybe these are “centipayments?” Nah, too geeky. “Minipayments” is better.

I think the minipayments evolved because you can’t make micropayments work financially for a single site. With credit card fees starting at $0.30, a $0.05 payment isn’t going to fly. Even Paypal’s current offering is $0.05 + 5% for micropayments.

I’ve seen some attempts to create cross-site micropayment systems, but they were way too small and folded soon after. At one point I had sent $10 on each of three systems, but only ever got $3 worth of content out of any of them.

Premium SMS is great, except that you only get at best 25 cents on the dollar.

Problems with minipayments

Right now, minipayments have business and user experience problems.

They are large enough to make you think about clicking, to actually track the money. I could have gotten a song for that! Or a cup of coffee! Or a turnpike toll!

Each micro-purchase is made with a separate financial decision, unlike turning on a light switch, sending a text message, or driving to the store. Each of these other decisions have financial consequences, but few of us think about it.

Most of these decisions also have a high time and attention cost. Entering credit card data, for example, is slow. Even password entry creates a barrier to entry. These extra user steps remind the user of the dollar cost as well.

There are places where minipayments are making sense. Apple’s iTunes store is clearly an example. Arguably, other app stores are also successful.

These success stories have addressed part of the minipayment problems. Customers have a single iTunes account, they aren’t really paying attention to how much they are spending, and Apple is left to get the money to the content creators.

But a central store for web content simply won’t work. The “store” needs to be highly distributed.

Other successful models

For sites with known value, small annual payments are useful. Flickr’s professional account is $25 for a whole year; $2/month is invisible to nearly all.

Monthly fees are more problematic, as customers get reminded every month of the cost. We subscribe to a few services, and seeing $50 here, $25 there, and $100 over there every month is painful. I find myself stripping down services like this.

Annual payments could work for some content companies, but customers would have to know the value. I’d happily pay $20/year for Harvard Business Review content, but I will not pay $4/article on nearly any site.

Making micropayments work

In short, we need an ecosystem for acquisition and payment of content, especially long-tail content of all flavors. If done correctly, the ecosystem could allow bands to sell their songs directly, application developers to sell their apps directly, and of course some web pages to be behind paywalls.

Micropayments need to be beneficial to the content owners, the payment providers, and to the end users. Here’s one way how:

A large brand, such as Visa, Paypal, Google, or mobile operators, creates a micropayment platform. Actually, we need to see several of these.
- Mobile operators would simply use their payment gateway. For more, check out Visionmobile’s Why mobile can bring back the value to the internet
- Google and Paypal may need to require the account to be primed with a small amount of cash, which can be withdrawn at any time and also applied to other purchases.
- Visa and Mastercard could make micropayments available to good customers carrying a balance, or perhaps add an annual $10 fee
Payment providers create a signup for content owners intended to be fast and simple, more like signing up for Adsense than for an App Store.
- Protecting against fraud may involve a refundable deposit, scaled against projected sales volume, for unknown providers
- Content owners should sign up for as many payment systems as possible
- Payment provider provides buttons for their call to action
Credit or debit cards associated with micropayments get charged once per month, or similar, perhaps just refreshing the account balance. It could vary by provider.
A pre-pay option could be cash-based, much like buying minutes
Content behind a paywall would have an array of payment buttons next to it, much like the social media share buttons on blog entries right now.
Purchases are one-click or click + passphrase, based on security settings
- Purchases are limited to one per 3 minutes (fraud protection)
- More than, say, $5 spent in an hour triggers an authentication request
- No purchase can exceed $3 without an authentication request
The payment provider returns an approval code that allows the content to be displayed.
Payment providers have easy-to-integrate code for hiding and revealing the content, ideally using a standardized micropayment API

By batching the transactions to a weekly or monthly level, we reduce the effects of transaction fees. The same function makes the price effects of the purchase less visible to the customer.

By allowing purchases with a click or very short code, we reduce transaction friction for end customers. By providing several types of accounts, we provide flexibility for end customers to choose the right type, such as mobile phone, debit, or prepaid.

I agree, this isn’t the way to save the newspaper industry. But it’s more likely to help than to require that I pay $5 for a week’s access and have to sign up for a specific site. And it could be highly disruptive for a number of long-tail publishers.

Posted in Business, Strategy | 2 Comments »

Are you wasting your mobile advertising dollars?

Wednesday, February 3rd, 2010

I was in a game on my Android. I kept seeing this kinda-teasing ad for a game; I thought it might be relevant to me as a casual puzzle game player.

Finally, after hours of play, I clicked on the ad. Many users do this, in higher rates than on the desktop-based web. The advertiser paid for me to click this link.

What should the link do?

Take me to a landing page directly related to the ad
Already know my region and device
Be optimized at least for mobile
Have a call to action on the page
Give me access to other information in mobile-accessible format

What did it do instead?

Site home page, not landing page
With no information about what the game was, not even platform(s)
Demanded that I go through a two-step process to enter my region
Took me to the product information page, coded in Flash

Posted in Business, Mobile web, Strategy | No Comments »

the changing mobile data landscape, part 2

Thursday, November 5th, 2009

If you haven’t, go check out part 1 of this series, in which I argue about the increasing role of feature phones in mobile web, and possibly apps.

I think a major shift in how we pay for mobile data is coming, within a year or two. And content companies need to figure out how to conserve bits. They aren’t free.

The role of data plans

Let’s take a look at unlimited data plans for a moment. Unlimited data plans are great! They provide enormous freedom! No worrying about how much data you use! Terrific!

And it is terrific. It’s great for people who can afford to spend $70 per month for each phone in their family. That’s not terrific for everybody. And it leaves people like my father, who want smart phones and that freedom but aren’t planning on watching video or tethering, paying for heavy users.

Variable pricing is inevitable

Unlimited data plans not only reduce access to a larger number of people, they also cause congestion problems. There is no cost to using the network, and there is cost to not using the network. It’s annoying on many devices to switch to wi-fi; it’s inconvenient to change your email or web habits.

As the operators increase available bandwidth, demands will go up. Video streaming, data cards, and tethering become more popular. People enter the world of mobile data from no experience to 3G cards, possibly with the intent to replace their home connection.

As the experience degrades (think AT&T access in places like New York and San Francisco), the operators’ brands take a major hit. Vehicle traffic planners have known this for years: roads fill to capacity. The existence of the larger roads change drivers’ behavior, even to purchasing houses further from town.

Some sort of change in pricing model is inevitable. Mark Lowenstein over at FierceWireless provides a few options. You can read a deeper discussion on the problem, and the solution, over at Slate.com.

And yes, Verizon already has a tiered data plan.

Global concern

I’ve just set out the argument for why the U.S. will not have universal unlimited data. That was the tough part of the argument; the economics for unlimited data are better here than in many places. In much of the world, pre-paid plans with pay-per-kilobyte are the norm. And this includes hundreds of millions of users (over 300 million in India alone) who do not have computer access to the Internet.

Increasing role of smart phones

As we discussed last time, feature phones are becoming more capable. Further, they have cheaper data connections than do smart phones, because on average they are used less. (There’s that tiered pricing again).

On top of this, smart phones are being pushed deeper and deeper into the feature phone market. Nokia has done this for years, and customers do not even realize they own a smart phone. Blackberries and Windows Mobile devices are being used as feature phones. Android phones “for the masses” are being deployed.

As smart phones get pushed deeper into the market, they will be selected by prepaid users more and more. Many of these users will still be paying per kilobyte.

Design implications

Right now, the bulk of the mobile web industry is moving to rich web interactions. But at what cost?

In a world of pay-per-kilobyte, is that 12kb JQTouch framework worth it? Sometimes, yes. But frequently, no.

It’s what we’ve been preaching all along: keep the page size down. Okay, we’re no longer limiting you to 1300 bytes (the standard was 1492 but there was this one Sanyo device …), but let’s do our best to keep sizes down.

If you design for speed, you’ll get a long way towards designing for different types of connection.

I’m hoping that HTML5 will be able to help us out. Imagine a local cache of the entire JQuery and JQTouch libraries available for any page to use without re-downloading. Perhaps a JQuery browser plug-in?

Similarly, the content industry should be pressuring mobile operators to publish not just the type of device, but the speed and cost of connection. If we had this information, we could really optimize content and the whole experience for the current situation. If the connection is free or cheap, and the current speed is fast, we send down the enriched experience. If the connection is dear, or the congestion is bad, then send down the lightweight experience.

Posted in Business, Design, Devices, Mobile web, Strategy | No Comments »

Little Springs Design. 2001 – 2010.