For a narrowly focused by very spot-on analysis of formats for eBooks (and how html is going to be the way forward) read Joe Clark’s article Web Standards for E-books at ALA.

And I’ll start by quoting, because he says it better than I could:

The internet did not replace television, which did not replace cinema, which did not replace books. E-books aren’t going to replace books either. E-books are books, merely with a different form.

I’ll also say that eReaders have essentially no penetration compared to anything else. any pronouncements are gonna look like Cliff Stoll’s oft derided article on the lack of future of the internet. Much like the Information Superhighway and other early internet-related pronouncements, we don’t know what will happen, but I suspect Joe is right, and eBooks are going to be yet another form of media, and paper mills are safe for a while.

My first list of random thoughts is things I keep hearing, and which I think are dumb. Having worked on an eBook directly for six months now, I’ve seen this all along about the Kindle and almost every new device, but “iPad will save the world” hype has increased it exponentially.

And now, a different but equally un-ordered list of random thoughts. These are more like design objectives, and business objectives for making a useful eReader:

• Books are not designed for annotation, bookmarking, etc. These are behaviors people created because they innately wanted them, and books support the methods. You have to support the /root need/ in your new device. How? I say starting with copying the existing methods, but new ones seem possible as well. Maybe someday I’ll show examples of what I think.


• How much would you read if every book was laid out differently? Some are right spine, some left, some fold up like a roadmap, etc.? Apps, with custom interfaces, for each publication are a clear non-starter. Not to mention issues with cross-referencing, or searching for bookmarks and notes, and social synching, and… all the other issues that trip up any number of services. Interoperability will be key.


• Battery life better START at days, not hours. If I had my way, the wall-plug would be hidden because you never use it; these need to be solar-charged, or similar. Minimal power consumption (ePaper types of technology, with NO consumption when static) seem required at least for now. There are color screens like this right beyond the next door. So we might be almost there.
  
• Cheap, cheap, cheap. Who wants to carry their ONE eBook around with them, and the people I know with one mostly carry it only sometimes. Why do waiting rooms have magazines? Because you have enough to do without carrying your own. Even in mobile-ubiquity days, a LOT of folks read those waiting room magazines. Need cheap enough everyone has several, and eventually they are given away.


• Rugged, approaching indestructable. A ruggedized device can be life chaging but this will only really happen when they are small enough to carry around we well. Alternatively, if the reader is dirt cheap, this makes up for some. But it’s not just disposal; how annoyed are you if you bring one reader with you on a trip and ruin it? It’s hard to ruin paper so completely you cannot read it later on. Who has not dried out an accidentally-soaked magazine to finish an article?
  
  My wife has a rugged phone, and it’s been very helpful to be able to carry gardening, talk when cooking, have it by the tub, etc. But it’s sort of an awful, featureless phone. We need small, rugged and full-featured to compete with paper seriously.


• Portable content. I don’t even want to talk about how the DRM works, but the end state has to be that I, as a person, can /always/ see my content on any device. E.g., I smash it and buy another, content is there seamlessly. If we want to get to a social scene, you better add a way to share that doesn’t involve me handing the device over. I had my phone off all the time, and it seems to make people nervous; it’s hard to get a phone out of most folk’s hands. When photos are shared, half the time it’s held up for others to see, not passed around. How will a reader get past this personal-device bias?
  
• Make it social and connected. Once you get past the table stakes of making it not uncomfortably un-book-like, work on where digital devices can be better, and that’s not the BS about carry a library in your pocket, it’s that it’s connected to the world. Better make a social media tie in, and better not be a unique one. Clearly, we’re not there in both vision and for business reasons; These silos of protected competitive space need to go away… but that’s a whole other blog entry I am working on.
  
• And be sure that data is handled in an information-processing-device sort of manner. Don’t be single session just because it’s easy; allow switching between books rapidly. Be sure search is easy to find and use, and is comprehensive. Display in multiple formats, and visualizations, and allow processing of content. I start thinking, why can’t the functions in math books be able to have actual values plugged in, and work?
  
• Be accessible, and not just for legal or regulatory reasons, not just for the stereotype blind user, but because if we’re going to use this everywhere, for all users we need it to work in all lighting, when you are tired, when you are driving and cannot read at all, and so on. Build true multi-media experience from the ground up. Again, no need to dream this up; there are rather good systems that exist, and just need to be implemented robustly, and universally.

Much of this discussion reminds me of every other technology that has come about while I have been a conscious, technically aware human. BD-Live just for one example, is wildly disappointing compared to the promise of interactivity . Since grade school I have been waiting for an experience half as clever and innovative as the Aspen Movie Map.

Despite all my griping, notice that I don’t say eBooks are a dead end. Or even that they must not be innovative. I say they have to be /usefully/ innovative, and to misquote what we say about mobile here “be a good book first.” It’s worth going back to first principles when a new technology comes about, and I think eBooks will be silly and niche until they are really, really designed to some useful principles.

* It’s not a secret project, so is a publicized devices, but my involvement is secret, so that’s all I can say about it.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars


Copyright ©2009 Little Springs Design, Inc.

And then it occurred to me that although I knew what I meant, I couldn't define "Collaborative Design" off the top of my head in any useful way. Normally I am not just opinionated about design and process, but have a solid reason for my opinion. So I considered this, kept quiet, and in the spirit of collaboration, later I sat down all by myself, and started to ponder what I think collaboration means.

And very rapidly I got almost nowhere. Even reviewing specific lists like Kelly Johnson's rules for Skunk Works project management wasn't that helpful; they are all too focused on their vertical market.

I came up with a few tactics, both derived from these and from my own observation, but I don't like simple step by step processes, at least unless there's an understanding of /why/ that simple process exists. It's not just my opinion; in industrial human factors a lot of accidents occur from mismatches between mental model and actual system behavior. So I need to find the underpinnings to make it work. But weeks pass while I have other things to do and no idea how to solve this problem yet.

Today, I was working on some stuff in the office (a slideshow, some "what do we do" language) and kept inviting people over to help evaluate, confirm and even create the content. Ten minutes later, Eric wandered by to ask where the best place for a help icon would be – an open-plan office is great for this stuff. And it all reminded me suddenly of this, because we were working /together/ on the problem. Even when asked about the help icon, I had to get scads of information from the designers working on the product full time, confirmed some of my other understandings, and then gave him options, and opinions on why each solution was good and bad.

And it occurred to me that this is exactly what I was doing earlier, and last week, and on all of the best collaborative products I have worked on. In fact, thinking about the method alone reminded me of projects I hadn't thought about in years.

A bit more typing and revising leads me to these principles and operational guidelines for collaborative engagement.

• Collaboration best employs the skills and knowledge of each individual. If a gap is identified, find the right person for that slot. This can be ad hoc (like Eric asking me to help solve a problem for a few minutes) or the way the whole project is set up, with a permanent team of these people all working together.
• Each collaborator contributes as they know best. That often means you trust someone's opinion, because that's their skill area. And it also means you keep quiet (or at least don't push too hard) when talking outside of your area. I know a little bit about database design, but try to limit my comments about data architecture, because I am not a DBA. And I hope they don't express an opinion on the color or alignment of everything I draw.
• There must be a product concept to start with. As I say it, you need a Problem Statement, Target Audience, Design Morphology, set Design Objectives and so on. Then stick them on a wall, stick them in the front of the documents, and constantly make sure that you stick with them. This carries through the whole process, so once the concept of design is done, stay with those templates and grids and the basic navigational architecture.
• Everyone is designing solutions. Technical contributors design data stores, software and so on. This is as legitimate a type of design as interactive or graphic design, so make sure everyone's contribution is as valued.
• Be a conscious designer. Every collaborator should offer (or be able to offer) an explanation for their decision, with upsides and downsides to each option. Inexplicable, unilateral proclamations to not engender trust with the team. And trust is the only way to make everyone believe in a decision and keep working collaboratively.
• Have a good team leader. Even for ad hoc collaboration, someone should clearly be the lead designer. For larger, and more permanent teams, a dedicated team lead is best. He should be only that, and maybe do other coordination and planning but never be a designer to avoid bringing his own opinions to the table. His key roles are to facilitate the process (make sure each of these other hints happen, make sure everyone actually works together and work through issues) and to make executive decisions. If a decision cannot be made, but either would work, he has to take responsibility for one, and that should be the end of the discussion.
• Discussions should be limited. Cutting discussions off is good. Sometimes it's that last 1% and any decision will yield a good result. If too far apart, it's often no good to keep going. While disagreement fosters creativity, argument just makes everyone entrenched. When collaboartion stops, it's time to stop the discussion, and take it up later. What these time limits are vary by the project, so I don't have any.
• The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people.*
• There must be a minimum number of reports required, but important work must be recorded thoroughly.* Remember to record all the discussions about design objectives in the same manner as drawings; they are a design deliverable. Archive all this stuff, but try to let the team do its job, and report to management only when needed. Regular demos and proof of value spreadsheets interrupt the process for the whole team.
• When it gets to drawings, there must be a simple, understandable and universally-employed method of drawing, revising, versioning and distributing the files to everyone on the team. This same system should be used for prototypes, final code, and bugs. Yes, this last never seems to happen, but team members get left behind every time there is a system shift, and that is a bad thing.

I also think it's important, with overused phrases like this one, to define what it is not, and to address the edges and fixes.

• Don't jump in after a design is locked, present a totally different design (or some change that will require a totally different design) and then claim that's collaboration. If there's a legitimate issue, and this change is needed, first you need to get agreement from everyone that the whole design is up for grabs. Remember, this includes making sure the timelines (and dollars) can handle going off and redesigning everything again.
• Generally, revisions are not a good place for collaboration. A second release is, sure, and so are specific aspects of a fairly locked product; I'm not saying it only works for some "pure" clean sheet of paper design. Collaboration works well to devise new solutions to a problem.
  If a design is solidly on paper, and changes start piling from other teams and individuals there will be problems. I don't just mean teamwork problems, and hurt feelings but problems...
• ... One-problem-at-a-time is a solid way to organize tasks, to approach bugfixes and so on. But it's a terrible thing for design (of any sort). Remember, everything has to be holistically approached. And not just because it's the right thing to do, or to make sure everything is pretty. No, once that design starts proceeding, things get tied together in arbitrarily complex ways, and simple changes become hard to keep track of. Components will fail, or throw errors, links will get lost, etc. Now, a good designer will get over these, but not without raising yet more issues, or making other changes... which presumably need to be addressed with the team again. And you rapidly get to a spiral of exponentially-increasing changes.
  Use design objectives, grids and templates as a ruler here. If you find yourself on the third or fourth "we'll just violate that this one time" it's time to stop entirely and re-address things. Can you discard this changed item? Can you identify another component causing all these issues, that can be discarded or redesigned? Maybe the whole product assumption is wrong. This has happened – lately, to me – and usually the results of a total redesign or reset of the design objectives are better than before.
• Don't make emotional decisions. Even if you are trying to design a product that is specifically supposed to appeal to the user on an emotional level (and really, most of them are), don't let gut feelings, anecdote and opinion rule. And as a general rule, don't vote. Someone should be in charge of that practice area, and if there's a disagreement, the team leader makes the call. Other methods invite emotional decision-making, which is rarely correct.

I am aware some people think I am hard to work with, because I am very opinionated and push for it. But I'm not really; what I push for is the design decision I have arrived at based on my knowledge in my practice area. When I run out of that knowledge, I look up more, beg for research or go to get the person who knows.

Some of the best projects I have worked on have resulted from being locked in a room for 16 hours a day, with all the right people brought in so we can work together. That sort of process is where I learned to push for the value of interactive design, and also to get out of my chair and ask the developers, analysts and marketing guys right now when you need to know something or get them to make a decision.

So, don't make a note for later, or promise to make a collaborative team next time. Get up or send that IM this afternoon, trust them to do their job and also to give you the right answer.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars

Copyright ©2009 Little Springs Design, Inc.

Kate Rutter at Adaptive Path recently posted about no longer using the word “web page.” I think that post went on a bit much about the philosophical underpinnings of the original term, and I’m not loving a lot of the terms she came up with. It reminds me more of some terminology I have created in the past couple months regarding eBooks (settled on “page” as a reference to the original book only, and “leaf” as the unitary, non-scrolling content in the current viewport).

As a general rule, I agree with tossing the term “page” for interactive products. I still think you have to know your audience and I use “page” and “web page” periodicially. It’s okay, as long as you know it’s wrong and work towards the right solution.

And here’s where it matters. Semantics matter, because they carry meaning. Replacing one word for “a fixed piece of content” with another is not that helpful. As I address briefly in my book on design process there is no difference now between applications and hypermedia. The whole concept of a page, leaf or card is suspect. More importantly, it constrains you as a designer.

My terms are along the lines of “state” and “view.”

I’ve started trying to clearly talk lately about the difference between interface design and interaction design – and other types, but these two get confused a lot. And interface design is not bad, but too many interface designers think they are interaction designers. Interface design is good and important, but (as I define it) it’s about the relationship of items within a single view.

Interaction design begins when the view changes, or between different views and states of the system, or related systems. Thinking entirely about decks views lets you loose sight of the basics of interactive design:

• Information
• Interaction

I fell into hating the term “web page” years ago, but not because I felt it was dated or over-used or because someone told me it was. It was a natural outgrowth of thinking about design from the ground up. Flowing directly from problems, to information design, to interaction design, to interface design… and having the revelation that there are no web pages anymore.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars


Copyright ©2009 Little Springs Design, Inc.

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:

1. 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
2. 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
3. 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.
4. A pre-pay option could be cash-based, much like buying minutes
5. 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.
6. 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
7. The payment provider returns an approval code that allows the content to be displayed.
8. 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.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars


Copyright ©2009 Little Springs Design, Inc.

Especially in my time at Sprint, building large scale account management systems, I've run through a lot of serious help systems, that had to meet specific financial and satisfaction goals. So, I've not just designed a lot of help stuff, but had some user research, and metrics on effectiveness. I am therefore pretty confident these methods all work. It should also be mentioned that this is not mobile-specific. That's a subset which I haven't worked out quite as well, but will try to someday. This is more like application and web systems help.

And after I gathered all my best practices to present to them, it occurred to us that these seem to be published nowhere else.

My guiding principles are that most help systems suffer from two distinct problems:

1. That you need help at all.
2. Internal organization and jargon.

Solving these will guide you to the right design.

Problem: That you need help at all

What I mean here is that customers don't want help. They usually don't want to pay bills, or change their settings. In their heart of hearts, they just want everything to work, seamlessly. When it doesn't that's a problem, and help gets called on in these dark times to get them out of it.

To solve for this fundamental problem:

• Design as though you have no help system — I almost never design a help tab or little question-mark icons into my basic system designs. Any user going to help is a failure of the design, so work to avoid that with other design principles. Don't throw errors. Make everything clear. Set expectations, and follow them up.
• Pre-empt help questions — When you come across a problem, very often you can solve it by sticking the "help" content on the page. Whether it's explanatory intro text, hint text below the form fields, or a balloon that pops up when you fill in that field wrong, you can tell the user how to avoid errors, or that something is wrong before it's a serious problem.
• Simplify errors — Though back to system design, this is the sort of thing that often tends to come up only when detailed help documentation is being created. One example serves to illustrate this best: A web-initiated SMS sender I designed once, which attached to a number of different back end systems. Any number of them could fail, in a number of ways. Development had cut down the 80-some errors to 15. But the user can't fix them and they all meant "something is wrong, try again" or "something is very wrong, try again later." So we cut down to two messages, with basically that text. If you have more than a handful of error messages, something is certainly wrong.
• Place help content contextually — "Help" does not have to mean a pre-packaged, self-contained knowledge base. Often, it should not be. I covered this some in the pre-emptive stuff above, but the principles apply more universally. If the user calls for help, it can appear on the page. When browsing help, make sure it's a new window, and you can regain focus on the application (or browser window) so the customer can follow along with your recommendations. Make sure interactive help is at least no worse than a book open on their desk.
• Contextually link to and within help — Launching help should pretty much never just open a help home page. Take the user to the help topic, or section, for their current location in the system. Sure, there will be a search, and other navigational elements to help them move around, but most of the time help is related to the location from which it was launched.

Problem: Internal organization, and jargon

All too often I encounter, or have to build, systems that are communicated in the way the company works, instead of the way the user perceives things.

• No FAQs — We've all seen it: the "Frequently Asked Questions" section of a brand new website. Frequently asked by who? And it's true, that almost all of these are just what some marketing team or other has dreamed up. Users see through this. They are as cynical about FAQs as you can imagine, and disregard them whenever they can find a better solution. Not that the concept is bad. If you can actually talk to the customer service arm of the company, and get the top 100 call reasons, go right ahead and narrow them down to the top 10-20 basic problems. Be sure to highlight them somehow (whether inline or as a topic area on the help landing page). But don't call them FAQs if you want any users to read them.
• Gather and organize information carefully — The best way I have found, on anything like a reasonable budget, to get help topics written is as follows: Get "help topic writing" to be a task on each developer's checklist. Right after successful unit testing, he has to write up the topic. These all get gathered up, and the product manager (or account manager, or development manager, depends on the dev team) reviews them to make sure nothing is totally unexpected. They can also turn impossible jargon into something useful, or reject them as too dense and ask for rewrites. Then the UX team organizes them in a sensible manner (see next bullet) and gives the final result (with reference back to the original topics) to the tech writer to clean up. With more time or money, you bring the writer in earlier and earlier. To the UX meeting, to review, even to interview the developers directly about what they wrote.
• Organize help like the application, site or service — Assuming that you have managed to build your product correctly, do not then fall back on the way the business is run for your help system. In fact, once you have all the help topics in hand, laying the product information architecture on top of them is often a good organizing principle for the topics. Sub-organize and cross-link all you want, but make the topics reflect the product. This also helps when you want to link to the help system from any location; there's a heirarchically-relevant location in the help architecture to send them to.
• Use common terms, not jargon and brand terms — Unless of course, your product is full of jargon and brand terms. And even then, also use the more common terminology along with it "Super FrogConnect, high speed 802.11g WiFi, can be configured..." Be sure to use several levels of terminology, to appeal to experienced and novice users, as well as tying it to the product.
• Teach the users, using good educational practices — I am not an instructional designer, but I know some. All I remember is that I have encountered normal distributions with visual learners on one end, and textual on the other; and on one help system I included diagrams of the new account management structure. Which worked great. And is especially important if something about your system is new, or breaks previously-established expectations. Be sure to hire a good writer, at least, and someone like an instructional designer if you can. They'll tell you more about this.
• Don't make users classify themselves — In theory, knowing the knowledge level, or intended use of the customer is a great thing. You can give them the correct experience, or here the correct sort of help language. In practice, this is a total non-starter. Even when people can classify themselves in useful ways (which is rare) they usually resent it. You don't need more ways to annoy customers, so just present the information and take your best guess as to how to communicate to them.

Be trustworthy

There's a sort of third principle that emerges when you look closely at these, and that's Trust. Sure, it's a common principle of all interactive design, but as I explain in my book on design process it's good to identify which of these principles are most important to the targeted users of your particular product.

Certainly, help systems need to be easy to use, transparent, preserve user data, identify them personally and so on. But trust is the biggest problem. Customers seeking help are (almost always) having a problem. You are already in a hole, and any friction is going to add to the frustration.

Aside from informing the rest of the design, this leads to one last best practice:

• Let your customers call you

This is rejected a lot by folks looking to cut Customer Care costs. Phone calls cost money, so anything to redirect them is good. But it's one of those where the conventional wisdom is wrong.

I'm not saying calls don't cost money. But customers already on the website are (generally) trying self-care anyway. They want to solve the problem themselves. Putting the phone number at the bottom of every screen doesn't drive more calls, it gives customers the confidence that they can try to solve the problem themselves. If they can't figure it out, they know there's someone to help them. Call rates often go down the more you add the number to the website.

This is not a theory. Several times I have seen this borne out by data, and I've heard the same from others, in all sorts of industries.

So, in summary, my best practices for interactive help are:

1. Design as though you have no help system
2. Pre-empt help questions
3. Simplify errors
4. Place help content contextually
5. Contextually link to and within help
6. No FAQs
7. Gather and organize information carefully
8. Organize help like the application, site or service
9. Use common terms, not jargon and brand terms
10. Teach the users, using good educational practices
11. Don't make users classify themselves
12. Let your customers call you

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars

Copyright ©2009 Little Springs Design, Inc.

In general, tips for speeding up a web site will help for at least some devices, but there are some extra niceties for mobile optimization.

Start with the giants: check out

• Yahoo: Best Practices for Speeding Up Your Website
• Google: Let’s make the web faster.
• Google: article focusing exclusively on mobile

Some specific tips:

• Each fetch request adds to latency, even more than most desktop users’ requests. Collect images into a single file.
• Design and develop as if all users were using satellite connections.
• Whenever you see a desktop maximum size recommendation, guess that you should multiply the number by 10%.
• Understand “make sure your size is no larger than 25k because that’s what the iPhone can support” type advice is not helpful for anything other than the iPhone. And 25k will take a while to download even on an iPhone.
• HTML 5, while not yet a standard, is becoming available for high-end mobile browsers. Local data cache can really speed things up.
• Design efficiently. Do you really need the JQuery library? It’s nice, but it’s big. Could you get away with a smaller framework?
• Use progressive enhancement. Design a great experience for less capable devices, and enhance it for more capable.
• Don’t get carried away with progressive enhancement: don’t send down code that a device doesn’t need.

Speed and effectiveness

Speed is not just about speed; we have to consider perception of speed. We talked about that quite a bit in part 1 of the series.

Good design is about more than just speed; sometimes slower speed can result in faster perceived speed and higher satisfaction. If a user is having fun or is easily achieving her goals, she will perceive the site (or application) as being faster.

And not all speed is the same. In general, interfaces that mimic physics, such as the buttons, sliders, and scrolling in most touch interfaces, must respond immediately. The illusion of physics must not be broken. But the parts of the experience that do not mimic physics, such as following a link, can have a delay.

So the design team must design well (there are lots of tips over at Design For Mobile), and must help the entire team decide when to break the speed optimization discussed above. For example, delivering larger image sizes than strictly necessary can enhance the experience. Using the occasional gradient can enhance the experience.

It’s a balancing act.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars


Copyright ©2009 Little Springs Design, Inc.

Amazon is quite proud of their $9.99 pricing for e-books. They claim that it is cheaper than paper. And it is … for one type of reading. If you read mass market hardbacks or trade paperbacks (the ones that are the same size as the hardbacks) then $9.99 is cheaper than $15.99 or $25.99.

I do that type of reading, but only for professional-related books. These books I might want to learn from, cross-reference, make notes for adoption at the office, and so forth. I will read while traveling, but not relaxing in the tub. I don’t really share these books with my friends, though I share some of the ideas with my colleagues.

In contrast, my personal reading time is spent almost exclusively with cheap paperbacks. They’ve increased in price to $7.99, which I think is too much, but I pay it anyhow. I actively share these with people I live with, and share with friends. These are the books I take into the tub, and are more likely to come to bed with me. I keep them for a long time, but if they get lost on a trip or wet in the tub, it’s okay.

Several of these books currently live on the shelves of the people I lent them to, and while I’d like to have them back it’s completely livable. You can tell which series I really enjoy, because I no longer have the first book in the series. It’s been loaned elsewhere.

Then there are newspapers and magazines. This content is temporary by its nature, and at least for me is more akin to skimming online news and blogs.

These are not the only types of reading out there. One of the key lessons in graduate school was how to read research papers. Reading for learning or book clubs might also look very different. Reading business documents, at least in my product development world, really needs a large screen and a strong social connection. The documents do not live in a vacuum, and their business context must be considered while reviewing the product requirements document. I suspect that legal reading is different again.

Each manufacturer/provider has presumed one type of reading. Kindle is targeting trade paperback/hardback reading, largely for pleasure. The Que is designed for business use. Hearst’s Skiff is targeted more at newspapers. Apple is going after content deals galore, including textbooks and newspapers. None appear to target my pleasure-reading needs.

I’m not really worried about device fragmentation in the e-reader market. We know how to design and develop for that. I’m more worried about the purpose fragmentation. Is one going to win?

Clearly the mobile phone will continue to win here. The Kindle’s ability to continue reading on the phone where you left off on the device is brilliant. But the problems with sharing and moving content to other places still plague them; I only want to purchase material I know to be temporary. This is an industry DRM problem, but Kindle appears to be extra protective. Still a no-go for me.

In the meantime, I’m still reading the occasional book on my phone, and carrying several paperbacks on trips.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars


Copyright ©2009 Little Springs Design, Inc.

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
  

  ---

  Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
  See our scheduled training on mobile design, including convenient webinars
  
  
  Copyright ©2009 Little Springs Design, Inc.

I could hardly disagree more. Criticism is a key part of discovering new ideas and working collaboratively. I am not brilliant enough to get by without help from others.

This opinion comes partly from my art school experience of all things. In general, I think art school was the best education I could have gotten. Not for the art per se, but for the criticism parts. After the first few years, getting the basics of the craft down, I had to (regularly, more than once a week) present my work, ask for opinions, accept them and act on it for the next review.

This taught me presentation skills, public speaking and an ability to think critically and rationally (not just emotionally) about my work, others’ work and what others have to say about mine. Yes, rationality, logic and business-like skills from art school.

Design criticism (and especially interaction design criticism) is a bit different, in that there are absolute truths and needs underlying everything. Art (at least the way I practice it) allows for individual interpretations. If your experience means you see something differently than I do, that’s usually fine.

For design, as a general rule, it is important that everyone understand the functions and the intent of the communications in the same manner. Individual interpretations that vary from the designer’s intent are generally a bad thing.

Design criticism is much like the peer review process. While scientifically-backed (theoretically, everything is confirmed by existing best practices or user research) there is additional help in having others… actually, Wikipedia has a great summary of this:

It is difficult for authors and researchers, whether individually or in a team, to spot every mistake or flaw in a complicated piece of work. This is not necessarily a reflection on those concerned, but because with a new and perhaps eclectic subject, an opportunity for improvement may be more obvious to someone with special expertise or who simply looks at it with a fresh eye. Therefore, showing work to others increases the probability that weaknesses will be identified and improved.

Even the simplest system I have worked on in the past decade is so complex I can’t hold the design in my head (and I am pretty good at this). The genius designer only goes so far, which is why my design documentation was created, and why I make myself stick to it.

Another way to think about this is in this posting about reviewing for journals:

In the early years, critique is about identifying holes and mistakes that make ideas less plausible. In the later years, critique is about identifying the germs of ideas worth development despite the current holes and mistakes.

In this sense, the value of critique is not unlike that of the concept reviews and brainstorming your may have done with the designers when they first came onto the project. Your critique (assuming the schedule allows for it) is not just to tweak the design, but to discover whether there is something totally brilliant or totally different hiding somewhere in there.

Design presentations to clients, and the critiques that inevitably follow, are all too often avoided, or are held with everyone defensively braced. Ideally, I have almost no big formal critiques, and share regularly. This doesn’t always happen though (scheduling, remote work, etc.) so the big review is still a part of my life.

I like to plan for them, and specifically ask for input from clients and others. I like to know my limits, and if something cannot or should not be determined by me or my team (e.g. there’s a good creative team at the client) I’ll leave that for them. And I prepare by putting together a good presentation, knowing the topic as well as possible, having answers or options for any decision that might need to be defended and bringing along any other designers who might know certain parts of the system better.

More often than not, clients reviewing design either focus on the wrong thing (the colors!) or seem overwhelmed by the massiveness of the whole project, and just sit back and let it wash over them. As much as it’s easy for me to not have to defend or revise anything, I like feedback, and need it to make sure the best product is going out the door.

As a reviewer, and especially as a client reviewing design you have paid for, here’s my ten tips for participating in a design review.

1. Look at the product. Review it as the designers wish you to. Feel free to take notes, but let the review be completed (whether a self-directed website walk through, or a presentation) before offering any feedback. Whether it’s a complex product, or your needs mean the presentation is out of first-time-user order, or the designer is just not that good as public speaking, you often will need to see the whole thing before you understand it fully.
2. Encourage everyone else to do the same. That is, take notes and wait till the review is over. Short circuiting this in meetings especially means you might not even get to the good parts, and spend the whole time arguing about the terminology of the signon process.
3. Follow up with details. Email is a great way to send more thoughts. Whether something didn’t occur to you at the time, or you are just a junior flunky and didn’t get a chance to speak up in the meeting, written commentary is useful. But do it quickly, before other changes are made or you forget the rest of what you saw.
4. Express your personal opinions on how you might use the product. User research is just lots of personal opinion and observation, codified, so if nothing else your opinion can be slotted into existing knowledge, and explained. The “worst case” is that it’s a brainstorming sort of point, and something else good can still come of it. Don’t, however, believe that your experience is necessarily of key relevance.
5. Relay anecdotes about use or understanding. Don’t spout pithy sayings “my mom couldn’t handle this” but do cite specific cases that seem relevant. Whether it’s the first impression of someone looking over your shoulder, or just what your heard some people say about the competitors product, that you worry this doesn’t do, it’s okay to bring it up if it hasn’t been heard before.
6. Quote solid information. Even if it’s “just” a marketing study or three year old use statistics. Ideally, the designers already know this, but if not it’s definitely time to bring it up. Even if they do, explaining that you have concerns about the design because of specific background information is a useful place to start a serious discussion.
7. Express personal opinions on style, aesthetic, etc. These might be trumped by brand standards, or consistency, or some other design needs. But bring it up. You might have found a hiccup in the standard implementation, or something else that needs to be fixed.
8. Everyone’s opinion is equally valid. Just opinion. If they have data to back it up, that’s different and usually trumps opinion. Even if you are the VP of everyone in the room, and authorize payment to the design agency, your opinion is still opinion. Your employees (and the vendor) were presumably hired because they are good at their jobs, so trust them to say useful things.
9. Allow the designer to counter your input. Don’t feel sad about it, because it’s not personal. If they have solid research, or experience, then think about trusting them on it. My guidance, whether reviewing other designers’ work or talking to clients, is “if you have a good-sounding story, I believe you.” Assuming you trust the guys you hired to do this work, you don’t have to understand what they say, but do make sure they sound like they understand what they are saying. Treat design like anything else you pay good money for, and trust their well-founded argument.
10. Review the changes later. Designers forget stuff, or don’t understand, or might make a new solution once they get back to the office. This is another reason you should write everything down. Don’t nag, but if you thought you understood that something different was going to happen, ask why. And feel free to ask for clarification; “we think” should be able to be followed up by “because of user research that indicates [something specific, with numbers].”

As a general rule, don’t be this sort of client, but do take ownership of the product. Offer the feedback that your position, background and knowledge of your business provides you.

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars


Copyright ©2009 Little Springs Design, Inc.

Here’s an email I got from him recently:

My Blackberry pisses me off in how it manages meeting notices.

If I don’t use my phone for a while, I might have several meeting reminders waiting for me when I go to use the phone. So when I pick up the phone, the first thing I have to do is unlock it by typing in a fairly complicated password. Then I’m immediately smacked with these meeting / task reminders.

99.9% of the time, I sitting in front of my laptop and I manage meetings/reminders on my desktop and not via the phone. But if even if I dismiss meeting reminders on my desktop, those meetings aren’t dismissed on the phone. Similarly, if I dismiss things on the phone, they’re not dismissed on my desktop.

So I hate the phone reminders. But that’s not even the biggest problem. The bigger usability problem is when I need to pick up and use my phone quickly. One example is when I’m receiving a call. And the other is when I need to make a call quickly.

When I want to recieve a call, I can pick up the phone and just press a button to answer without having to unlock the phone with a password. Typically I take all calls on speakerphone, though, so my desire is to press a button to answer the phone and then press the two button combo to put the phone on speaker. The problem, though, is that as soon as I answer the phone, I am FORCED to disposition each meeting reminder before the keyboard will allow me to switch to speaker phone. I MUST address each notice before I can go to speaker phone. Pisses me off.

And when I want to make a call quickly, the same problem occurs. I pick up the phone, unlock it with the password, and start dialing the number I want to call, only to realize that the phone isn’t even recognizing my typing because it wants me to first disposition the meeting notices. There is no way for me to make a call before I deal with each of the meeting reminders. Which is best exemplified by another common (and irksome scenario). ..

I’m on a conference call from 10:00 a.m. to 11:00 a.m. And I know that at 11:00 a.m. I need to go RIGHT into another call. So at 11:00 I hang up from the call I was on and immediately start dialing the next number I urgently need to get to, only to be again forced to deal with meeting reminders BEFORE I can make the call. I’m simply forbidden to dial until I give my calendar the attention it desires. If I end up being late for my 11:00 meeting, too bad.

Since when is my calendar more important than me being able to use the phone? Why can’t the meeting reminders wait?

I’ve had much the same opinion about some things my mobiles do, but haven’t had time to think much lately, so haven’t typed them up. But there are several lessons here.

First, end users matter. Some of his issues are a result of security software loaded by the corporate entity. Some of the others might even be surmountable by customizing the device. But it’s highly locked to him. He cannot do almost anything to his phone.

I did a fair amount of B2B (and government) work while at Sprint, and saw this a lot. Ignoring end users because they don’t make decisions. Yes, my friend cannot drop his service or change handsets, but his productivity is clearly impacted by poor user experience.

Second, you have to design holistically, or maybe, systematically. The Palm Pre I am using now is good at obscuring keyboard functions (including the mute and speakerphone functions, like my friend’s case).

My friend’s problem seems to be that every alert is modal. For the project I am currently working on, I almost let that happen by accident just by semantics. I called this subtle notification strip “alerts” in the documentation. By default the developers assumed that word meant they were critical and therefore modal. Luckily I (and the rest of the Little Springs team) was around and evaluating what SAs and developers were doing, and noticed this.

I have some detailed strategies aside from “constantly review” to correct this, but no magic bullet. Essentially, I say you need someone with a product-level vision, and I like to say that’s a dedicated designer.

For that product with the notification strip, it was blocked off for each and every screen and state wireframed out. Only a few things can be obscured by it, and those are carefully chosen; it’s okay if they are unavailable for a moment. This is my sort of tactic for holistic design, and so far seems to be working out.

Third, and maybe most importantly, people matter more than devices. I get similar behavior with my calendar reminders. I can get the same reminder:

• In google calendar as a popup
• In gmail
• Sent as an email to the corporate email
• Popping up on the phone

That’s not even considering that I have 2-3 computers I might be on, all with access to the same network of services. I could theoretically dismiss the same reminder TEN TIMES.

Sure, sure. I want it to be able to come up on all these, so I don’t forget about a meeting. I am forgetful, so need the help.

But I have to wonder why it cannot send a message to the network when you dismiss or snooze an alarm. Then dismisses (or snoozes) the alert in ALL your locations.

If I dismiss, that means I saw it, and should not have to be reminded again and again. I. Me. The person. Who cares about the the system?

Little Springs Design is a user experience design consultancy focused exclusively on mobile. For information on contracting our design, strategy, training, and testing services, please contact us today.
See our scheduled training on mobile design, including convenient webinars


Copyright ©2009 Little Springs Design, Inc.