Little Springs Design

quiet time is over: new carnival

Barbara — Tue, 18 Nov 2008 22:24:07 +0000

The latest Carnival of the Mobilists is up on the Mippin blog.

And now that I’m back from a big trip, We’ll be posting a bit more often.

recommend us to a friend!

Barbara — Thu, 13 Nov 2008 23:30:00 +0000

You’ve probably noticed that not everybody reads RSS feeds, even one as (potentially) relevant as ours. The use rate may be as low as 11%, though that data is somewhat questionable. I’ve especially noticed that mobile designers, product managers, and marketers in large companies don’t read blogs. As a result, they are unaware of the huge array of resources available to do their jobs.

If you know someone like this, please take a moment and suggest that they
sign up for our newsletter! With the numbers above, we should have at least twice as many subscribers for our newsletter as for the feeds, but the numbers are reversed from that prediction.

Each newsletter contains highlights of the month’s blog content, occasionally supplemented with more content and usually clustered in ways that weren’t obvious while we were writing the original articles. It comes once a month, so really doesn’t fill up the mailbox, and content is always highly related to mobile design.

And we don’t use the email address for anything else, unless of course you ask us to.

getting the details right

Barbara — Wed, 12 Nov 2008 23:15:14 +0000

I keep fussing about details, because no matter how much wow factor your service has, missed details can erode your brand over time. Yesterday at the Mobile Device and User Experience, Scott Weiss (now of Human Factors International) talked about how the great transitions and visual design of the iPhone provided a “halo effect” that delayed users from noticing and becoming frustrated with the inconsistent back button placement, difficult text entry, the fact that the device never does learn anything about text input.

I just tried out the ABBYY Business Card Reader for S60 so I didn’t have to bring all the cards home. I’ll spend the money on the app, but I’m not sure why it consistently puts FIRSTNAME LASTNAME into the first name field, with nothing in last name. It seems a particularly easy bit of code, so what gives?

It’s way too easy to pick on pretty much any device and any service on getting details right. Scott does a great job of pointing out iPhone issues (though my chief irritants have to do with browser behavior), but what about Nokia? Well, here are some issues I found irritating. When I swap out the SIM on my E71 and launch messages and try to view one … nothing happens. I have to reboot it again. And then, there is the lack of keyboard shortcuts, especially on my QWERTY device. Not to mention, I learned that my device had predictive input at an industry conference, not having noticed it in the device.

By the way, XT9 is terrific! It learns words immediately. Love it so far.

Another example of missed details is the latest Gmail client. Two major problems for me:

I keep getting cognitive dissonance when it announces that I have 6 messages in my Inbox but I can’t find them; I must go Options > Refresh to actually see the new messages

It doesn’t realize I’m using a QWERTY device and thus my delete “shortcut” is # (two key presses) and there is no shortcut for archive

Why are these details wrong? It depends.

Not considering target audience and their goals, activities, needs, desires. The G1 is so developer-focused that small hands will actually cramp while typing.

Insufficient development & testing resources, and after all something had to give (think about the abrupt transition from Flash to Windows Mobile on many devices especially HTC)

Legacy code (I’m looking at you, Motorola and Nokia)

Insufficient knowledge of the domain (it’s shocking how many companies approach us and do not have an approach for dealing with device diversity

Piecemeal design, like a rambling home added onto by many owners in many architectural styles, without a consistency of purpose (like parts of the iPhone UI and also like the location of my very first job, the Winchester Mystery House

Product management processes that rate bugs on a scale of 1 to 5, then get all of the severity 1 and 2 bugs and some of the severity 3 bugs done before launch. Oh, and typically the worst UI bug can be is a 3.

How do you fix it? It’s hard. If you’re designing a platform, try to make the presentation layer flexible, including screen and even functionality. This will allow a bit more time before things start getting clunky. Rethink your paradigms every once in a while; don’t assume that a great user experience 8 years ago remains great. Features have been added, content has scaled, device capabilities have shifted, input mechanisms changed, and user expectations have evolved.

Set standards for user experience testing. Usability must score a certain level, perhaps benchmarked by the competition, before the product can launch; a bad task score must be launch gating. Don’t just test high-frequency things. And don’t just test usability: test learnability, speed to expert use, satisfaction by expert users. And definitely test the things that drive revenue and costs. Measure how well the experience matches with your brand goals. You do have brand goals, don’t you? A story about what you provide?

Get a second opinion. Even if you can’t invest in a lot of testing, get knowledgeable but outside resources to play with

you and your UX department

steven — Fri, 07 Nov 2008 15:48:05 +0000

One of the discussions I hear occasionally from user experience types is how to get good user-centered design into actual products. Most products come from companies whose core competency is something other than design; they are product or software or finance-centric. And that's fine.

A common refrain is, as recently discussed here is that UX should never be a department, but must be ingrained in the company. The theory is that if it's one department then no one else will bother to work on it.

There's only one problem with that concept: no one but us UX folks have this discussion. There is no reason good design, or user-centered-anything will occur without an organizational structure to guide them to it. You can be sad about this, but I've learned to live with the truth that this is how corporate entities work.

That's not really a bad thing, though. People do like to work together. Policy and procedure get followed, at least in principle, so your activities will be performed. And when you understand the systems, you can work within them. I have been contacted a lot (when I worked at a Fortune 50 company) by people who had only a vague notion of what our team did, but had heard good things about us from others who had executed projects.

If you are toiling away in the basement with no respect, you might just be shaking your head and laughing that this could ever exist at your company. I, for one, have been on a team that moved from an obscure corner to a 60-person team with responsibilities in CEO decks. To get there you need to:

Exist – You have to have a department. However small it is, make sure it's a single team with a name that means something. If you have a choice, and you might later on as your company reorganizes itself, where is the best place to be? I am not sure. I suspect getting a C-level team would be good (with your boss, the Chief User Experience Officer) but how likely is that. I've worked in or with teams in Marketing, Product Development, Operations and IT (and probably others) and none were perfect or terrible. But do understand the culture in which you are operating; IT and Marketing have different measures of success.
Get in the process – Assuming you are talking about interactive design, software development processes rule the world. Whether this is good, or any process is well-designed, is a whole other disucssion and not something you will be able to influence right away. You need to get in the process, formally. This will take a couple steps alone:
1. Understand the process – Most people do not understand software development processes. However, most developers don't either, or have forgotten over time. Get some books, hire the right people, and talk to the process managers (they probably exist). You can use the process to your favor if you know it well. Also note, many software processes (though not many web processes) have an interaction design phase, that is just poorly understood.
2. Sell your position – You need to be able to talk to VPs, product managers and process boards. You'll need all the knowledge of why UX is important, why this will improve development, why this will help the company bottom line and be able to do it off the top of your head. You might not be able to do this; when building a team, often the manager is a key job for the core designers to find. Get someone who can do this for you.
3. Build the process – Once a line item is accepted as being your responsibility, you aren't done. There are still options as to how it gets worked, and those will determine how much influence your design actually has.
4. Defend your step – You have to keep working as you said you would, maybe even push the boundaries, and explain the value all the time. Being complacent or skipping out of some projects can cause you to be left behind, even if the official paperwork says you have a seat at the table.
Getting signature authority is best; no project can proceed without your department's approval. But this will not happen day one, and with it comes extra responsibilities. Can your team support these efforts with it's current headcount?
Market yourself – As implied above, it's largely political. You need to sell your job role, and keep selling it over time. Teams change, processes and priorities change and new products emerge all the time. You need to make an active effort to market the value of your team all the time. This freaks out a lot of people, who think marketing internally is evil, and confuse marketing with advertising. Look up some definitions, and think about how you approach product design; expressing core values is not that different for your team.

If you still think this is just cynical and short-sighted, so be it. My long-term goal when at the big company was still to get everyone thinking about user experience (and customer experience, and related topics) and I've seen it start working. Design leadership and examples of how you can help, are good ways to start moving your company in the right direction.

latest Carnival

Barbara — Thu, 06 Nov 2008 22:57:03 +0000

Go check out the latest Carnival of the Mobilists over at MOPocket.

exploring device data

Barbara — Sat, 01 Nov 2008 17:05:01 +0000

The good folks over at dotMobi and DeviceAtlas, most notably James Pearce and Andrea Trassati, have provided us more goodies. This time, they’ve given us Data Explorer so we an see how device characteristics are distributed across the device universe.

Check out the introductory video. It’s great stuff if you care about how your content is rendered.

Now if we can merge some of this data with the frequently-used data coming from AdMob, M:Metrics, Opera, and so forth, we can get an idea of how many of those 128 pixel phones are actually using the web.

help systems for mobile

Barbara — Thu, 30 Oct 2008 15:41:12 +0000

I was recently asked about designing help systems for mobile. I put a draft version of our help system design recommendations up on the mobile design resources wiki. Obviously this is not a full design, but it should get you started. Please edit as your experience suggests.

touch screen usability: election edition!

Barbara — Wed, 29 Oct 2008 20:20:42 +0000

Ah, election season. Here in the U.S., early voting has already started. In one state, nearly 20% of registered voters had already voted by Monday. But all is not well in the land of democracy. Or the Republic. Or whatever.

Terrified by the hanging chad paper ballots of the 2000 elections, many states went to electronic, touch-screen voting machines. Ignoring the myriad security issues, let's talk user experience. First, please note that the usability community has had a formal voting usability project since 2001. It's frustrating to watch new machines come out and ignore established security and usability freely available standards. (Some have gone back to paper, with scanners to quickly read the votes. Paper is an interaction method, and one that's pretty well understood; good or bad design can happen in any media.)

We have three key constituents here: election officials, poll workers, and voters.

Many poll workers are essentially volunteering. When I did this in California, I was paid something less than minimum wage, though this was 18 years ago. It's social: neighbors come in and announce that they are here to cancel out each others' votes. You see people you don't normally see. It's a great way for a retiree to spend a day.

Please note I said nothing about "technical" or "computer savvy". So, issue number one is training the poll workers on how to help voters and manage the machines. This problem is pervasive for most interactive voting machines. I've not seen any problems with the fill-in-the-bubble paper votes with on-site scanners in my precinct. Another benefit of the scanner system: you only need one machine for 1-2 precincts, as it only takes 10 seconds to do the computer part of the process.

Now the voters themselves. Hopefully, you've got all walks of society voting, from semi-literate computer novices to folks like typical readers of this blog. All need to be able to vote. Fortunately, there's lots of help, but voters are going to feel somewhat pressured to move quickly. This is especially a problem where states do not send out sample ballots, so voters are seeing the layout for the first time.

Touch screen kiosks are easy to set up and perceived as easy to use. After all, touching is "natural". Unfortunately, it's not that simple. One early voter in Decatur, Tennessee had the voting machine "switch his vote" from one candidate to the other, and was told "the error sometimes occurs when a person??s finger touches close to the line of the box the candidate??s name is in".

Ah, parallax. A problem with touch screens, particularly with kiosk. The touch surface and the display surface are not the same, so what is being touched does not necessarily match what the machine thinks is being touched. The two have to be aligned, but the person doing the aligning has a particular point of view that doesn't necessarily match the voters. And the things can lose alignment over the course of the day.

Too bad the developers did not follow simple kiosk design guidelines. For example, check out SAP's Interaction Design Guide for Touchscreen Applications (Experimental). Don't use it for mobile web design, as you'll have to do a lot of analysis to make it work for that environment, but it is precisely written for kiosk design. And if you read it, a some simple heuristics valid for most touch interaction emerge:

The touchable area of a control and its visual representation need not be the same size. That is, the target can be larger or smaller than the graphic.
For most situations, provide a separation of at least 3 mm between targets. If a touch does not fall in the target area, do nothing. The user will tap again.
The graphic should generally be larger than the target. Ideally, the graphics are also separated.
Use large graphics for buttons, around 2 cm square.
Provide immediate feedback for the action, such as changing the visual state of the actual control. Bonus: change the label to add a checkmark or some other natural visual.

Excellent resources:

Touch Usability blog and the voting problems entry
Usability Professionals Association Voting and Usability project
Voltage blog best practices of touch screen design

And of course election officials sure can write their requirements to address real needs of voters. Since they seem to use the "requirements" put forth by manufacturers, instead of those independent groups above, probably the best way to change this is to get people who care, and usability professionals best of all, onto the election boards. We're all too busy around here, but please, you should go help out.

Of course, the ballot marking is just a part of the system. Even just taking the polling place into consideration, there is traffic control and flow, paperwork, queuing, interfaces and backlogs on other machinery (e.g. making smartcards for the kiosks), etc. Or, how about if there is a problem with the machines, like the Diebold timeout issue? See the image at the top of this post for a too-wordy potentially untruthful "solution" to help voters. I say the answer is not to 1) lie about the reason, 2) give an excessively-wordy notice out, 3) on small paper, and 4) then take it away from voters before they actually get to see the machine (Steven snuck one out, though).

If this is all too heavy, and you are tired of voting news, try this take on the real value interactive maps add to the TV news. The relevant bit starts about 5:30 in.

don’t just build for yourself

steven — Wed, 29 Oct 2008 14:56:59 +0000

I like process and procedure. I didn’t used to, and working with new designers it’s often hard to persuade them it’s worth it, but a project or two is usually enough to show them it works. We work with the client, gather information, interview users, codify everything, parse and organize it, and design systems that can be actually built and meet the needs of the identified user base.

Which is why I could not disagree with this blog post more if I tried. Oh, unless it’s the much longer version this other guy posted which is where the first post came from.

One telling line from that post is:

For our Case Study, I will not do any research and the product will be entirely fictional. This is the approach used by most real companies.

Ah! See, like I mentioned above, there is a formal method to talk to users and gather information. And another thing a lot of people outside of UX don’t get is that users lie. This is why we don’t do focus groups. There are lots of other ways to get at what people do want, how they really use their existing products, and act in their life, etc. If you just ask them what they want, you’ll build a product or feature they will continue to claim they want, right up till they do not use it.

And that’s important when you get to the core idea these blogs brought up. Which is that you should trust yourself. I claim that you lie also. I know I do. The problem with focus groups and other preference-based surveys is that people are not trying to lie to researchers; they also lie to themselves. So you don’t know what you want either. Really.

Back at Sprint our team decided to make our own “enterprise” software package. Okay, it wasn’t for the enterprise, but it was internal software for a team of 40+ people. When announced, everyone ran back and made a list of desires, and developers started coding it. Then we assigned a team, interviewed each other, gathered data, etc. and designed it. Guess what? Totally not what had been coded and asked for by everyone, and in the end so exactly what was needed that everyone actually used it (unlike the enterprise software we were avoiding using by building this product).

Which is a good point. My products (usually) work great. I mean, they reduce calls to customer care, get good reviews from users on forums, improve customer satisfaction scores, increase the close rate by 250%, improve sales. Real, measurable results. And 90% of the features and design widgets I put into this work is distinctly not what I want for myself as a user. In fact, I don’t use most of the consumer-oriented products I have built.

Whenever I rant like this a lot of the tech people I know get all upset with me, and take it to mean they can’t do anything. Not at all. Developer input is important, software and database design are important phases, but user input is also an important phase. Just like a DBA can help you build the data store, user experience and usability folks can help you design what your customers actually need and use.

Carnivals

Barbara — Mon, 27 Oct 2008 18:33:39 +0000

I’m late pointing to the latest Carnival of the Mobilists, so much so that I’ve two now. Find last week’s Carnival at London Calling, and this week’s Carnival at VoIP Survivor. As always, this is one of the best ways to get an understanding of a good cross-section of mobile bloggers.

Want more? Go check out mobile.alltop.com or the mobile version at mobile.alltop.com/m for writings of lots of mobile bloggers, perhaps even “all the top” mobile bloggers. You’ll find some familiar faces (like us!) and some new ones.