Category: Design Main Categories

Thursday 8/21/2008
Business, Design, Writing

You loyal few RSS subscribers know that I’ve failed to post for quite a while. (I have no visitors.) Since taking my job at Belkin I’ve been struggling a bit for time and against the urge to post things that might be too Belkin-specific. So I’m toying with a few overlapping ideas; I want to know what you think of them.

1. Make posting easier. Take advantage of microblogging techniques and mobile software to make quick posts possible from anywhere.
2. Make my “read-later” list public. Things I find interesting enough to mark for later perusal might be of interest to others. Tagging might be useful in this data set.
3. Do some sprints. Choose a topic and make short daily posts about that topic for a specified period of time, maybe 30 days or 90 days. Possibilities include “Today’s UX winner and loser,” “Would be better if…,” “GenX grows up,” etc. These topics could have different visual designs, although I’ve done a lot of visual design wheel-spinning in the past.
4. Open up the topics. Hinted at above. It doesn’t have to be 100% design or user experience.
5. Loosen the filter. Even half-formed thoughts are fair game, if reasonably presented in an effort to engage.

My goal is to reinvigorate my blog by allowing shorter posts and a broader range of posts. My wish is that this will foster discussion, get some things out of my head where I can refer to them later, and help me be a better observer of my surroundings and influences. What do you think? Does this seem like a good approach? Any tips or ideas?

3 comments

Thursday 2/7/2008
I Like This

Gianni Botsford Architects : 092 : Casa Kike . Excellent continuation of the cross-bracing into the built-in shelves. Pretty and graphic.

3 comments

Thursday 2/7/2008
I Like This

Exploratory Design — Homage to the Stamp

No comments

Saturday 1/12/2008
Design

Progress

I’ve recently spent some time using Wesabe , during which one Andre Arko implemented one of my wishes (“archive” an account), and mentioned that he’d be working on the transaction view in the near future. Excellent. Transaction view is where I spend the most time in Wesabe, having not yet dug in to the social components. Here’s a picture of the core of transaction view:

What are you looking at?

At first glance, transaction view seems pretty straightforward, but there’s a lot of power hidden there. And “hidden” is part of the difficulty. For example, there’s no outward sign in the above image that I’m looking at the “unedited” view of this account, a filter which shows only transactions whose payee names have not been edited to be more human-readable. Right away we need some differentiation in the links at the top right that control filtering. And if I am looking at a filtered view of the account, which ostensibly would not show all of the transactions, a running balance is unnecessary. Removing it would also help distinguish the filtered views from the “all” view. Perhaps like so:

There are more polished ways to achieve this effect, of course.

It isn’t apparent from the images above that they use some ajaxy goodness to update the individual transactions, but fail to update the filtered transaction count that appears in the upper right. I didn’t realize this until I absently clicked on “untagged (15)” in another account and was told that there weren’t any untagged transactions. That mistake shouldn’t be so easy for the user to make; it is completely preventable.

The banks aren’t helping

The merchants and banks are making life tough for Wesabe users. In some cases the payee name as it appears fresh from the bank is cryptic; in others the name is merely an address or even less informative. You don’t have much to go on if you are trying to apply meaningful names to these merchants. There may be an opportunity here to reorganize data a bit to make it easier for the user to figure out who the merchant is, though. I started finding merchant names by Googling addresses, but found that if I scrolled down and found the same address, the amounts and dates (if they were recent enough) were useful clues. Perhaps merchants could have their transactions grouped? If I saw a merchant with a string of $7.35 transactions occurring every few days, I’d recognize my post-workout meals at Baja Fresh and be able to act accordingly. Here’s an example:

Granted, I couldn’t tell from these (oldish) transactions that the merchant was Target; I had to go to my records for that info. But as Wesabe gets more users, and as more merchant names are edited, the likelihood that Wesabe will have seen a particular merchant name before will rise. Wesabe could suggest the most popular option, and make it available as a nearby link. There’s no need to say “Originally: 9100020206 North…” right below a text field saying the same thing (which currently happens on every unedited transaction).

I took some other liberties with this grouped transaction:

• There’s no need to repeat $ on every dollar amount (but it is nice to have on totals or current balances), nor is there much call for a negative on every debit. Distinguishing the (far less frequent) deposits should be sufficient.
• I re-explained “Tags that stick every time” by naming the field and changing its alignment. Suggestions based on the suggested merchant name immediately follow.
• Since the primary goal of this altered view is to name the merchant, I did away with the transaction-level tagging.

I’m not completely sure that this is the right way to group transactions, but it is definitely worth studying.

You got your social in my financial

Edited and tagged transactions pick up some social flavor in the Wesabe interface. Here’s a sample of the current “all transactions” view, with my little top-right change to make it obvious:

There’s a lot of repetition in this tight little display of transactions. We’re not seeing our transactions in a purely columnar ledger format, but dates are repeated as if we were. Tags and social content based on those tags obtrude on each other. A little reorganization is in order:

There are a thousand ways to go about this. I opted to group transactions by date, reduce the number of labels, treat Fan/User/Captive differently, and give social content its own flavor. (I also notice that I have a Starbucks payee and a Starbucks Coffee payee. A way to edit the list of payees, allowing consolidation, would be great.)

Could be great

As Wesabe gathers more data and more users, they’ll have even more opportunity to expand ease-of-use. But there are plenty of opportunities immediately apparent to keep them busy in the meantime. I am excited about using this product as it grows and changes.

One comment

Wednesday 1/9/2008
Business, Design

Trapped on Palm?

My Twitter question about money management alternatives for iPhone hasn’t exactly borne fruit, but there are buds on the tree. I’ve been a loyal but increasingly less-satisfied Palm user since the Palm III launched in 1998. All that is preventing me from ditching Palm OS and getting an iPhone is my personal finance workflow.

Maybe I’m a weirdo

I have enjoyed accounts that always balance, zero surprises, and an enhanced ability to understand and plan the movements of my money since I started using Ultrasoft Money and Microsoft Money together in mid-2000. I could (and can!) enter bank, ATM, credit card, even cash transactions into the Palm as they happen, syncing to Microsoft Money later. This works well enough that I tolerate a relatively cumbersome process to preserve this work flow even now that I am on a Mac at home. I open Missing Sync, turn off syncing, fire up Parallels, press the sync button on my cradle, then reverse the steps to sync my calendar, etc. Seven steps where one button press used to do.

Sure, there’s Quicken for Mac and Pocket Quicken, but everyone I know who has used Quicken on the Mac says that it is a festering pile, and each subsequent version is a higher pile with more festering than the previous. No thanks.

If only…

There are a number of up-and-coming personal finance packages for Mac, including Cha-Ching , Liquid Ledger (sold as packaged software at Apple stores), MoneyDance , iCash , Checkbook , and others. None of them support the entry of records on a mobile device.

This leaves a web-based solution. Names that get bandied about here include Mint , Wesabe , and the online banking offerings of Citi, Wells Fargo, WaMu, and Back of America. But none of these allows you to enter transactions as they happen.

Wesabe to the rescue…someday?

Actually, that isn’t strictly true. If you can find the "Create a Cash Account" button buried somewhere in Wesabe’s "upload" pages, you can create a cash account that will accept your input. That’s a start. This last bit of info was pointed out to me by Marc Hedlund, co-founder and Chief Product Officer of Wesabe (@ wesabe on Twitter). Marc heard my call for an iPhone-capable money management option, and mentioned that "Wesabe does that." An enlightening email conversation ensued wherein he revealed:

• They plan to make it easier to find the cash account setup functionality.
• They are working on the capability to enter transactions against other accounts.
• Auto-upload of account information gleaned from your bank is about to get a lot better, with essentially automatic support even for accounts that don’t currently support auto-update. The timeline for this was "in about a month," and we were exchanging email on new year’s day, so mid-February is probably realistic.
• They are working on making the setup of their desktop uploaders even easier. The OS X uploader needs to be manually invoked or put in your list of login items, too high a hurdle for consumer-level goods.

This looks very promising. None of the above list has launched, of course, so it isn’t real. Yet. I made some additional suggestions and complaints:

• Offering a cash account by default, and having the capability to add transactions to other accounts on by default, would require no configuration by the user (they wouldn’t have to find the spot where you turn these features on) and would seem internally consistent.
• A way to suppress an account without losing its transactions from history would be worthwhile.
• The information hierarchy around transactions is a bit messy; social content (related to the tags you give merchants and individual transactions?) is mixed right in with data about the transaction, and needs a bit of separation, for example.

Yes, but what do I really need?

After reading my extended complaining (this is hard to find, this is odd, your homepage has no background color), Marc asked the critical question: "Other than upcoming transactions, are you missing anything in what we provide today, in order to drop what you’re using now?" Ah, good. I had to think about it a bit. What parts of Microsoft Money and Ultrasoft Money did I depend on, and what could I discard? This required some thought. My list:

• Reconciliation. With updates coming rapidly from the banks, etc., this is really just a way to answer questions like: What showed up that I didn’t know about? Did I enter something in the wrong account? Why is my balance not what I expect? Am I current as of this statement?
• Recurring transactions. I make heavy use of these in Money; they’re great for paychecks, subscriptions, rent, etc. With the caveat that if a payment requires my action (such as sending a check), I need a reminder, not an auto-entry.
• Offline capability (maybe).

Those are the must-haves. I have made use of, but can live without, the next tier of features:

• Splits. Paychecks especially go into a lot of different buckets (taxes, insurance, HCRA, some to savings, some to checking, etc.). I suppose I could fake that with little constellations of recurring transactions.
• Reminders for scheduled transactions.
• Loan accounts.
• 401(k), IRA, and other investment accounts.
• Debt reduction and other planning features. The math for debt reduction planning is so simple that this could be a bit of content rather than a tool. Allowing creation of recurring transactions/reminders from such a plan would be a great feature, if the recurring transaction interface is solid.

My bad

It turns out that they do splits with a clever modification to tags; you can add a dollar amount to a tag for a particular transaction. This is easier to use than the split interfaces in Money or Quicken. They have a demo video for this feature that shows it off nicely.

As this all wound down, I told Marc I would relate my ideas about transaction view. I had better get on that (in an upcoming post). Also, the unmentioned player here is Quicken Online and their recently-announced iPhone-capable mobile version. Watch this space.

2 comments

Sunday 11/11/2007
Business, Design

A new grocery store opened in my neighborhood last week. Fresh & Easy claims to provide high-quality food at “unbelievable” prices in a friendly, small-store format. They further claim caring for the environment and an emphasis on local sourcing of produce.

Our little slice of Los Angeles is grocery-starved, so Thursday’s hotly anticipated opening was well-attended. When we visited on Sunday we found that the produce and well-hyped prepared food shelves were nearly bare. The store was only moderately busy, so we plowed ahead in search of a few staples and to check out the selection.

Afterward, my wife claimed she sort of wished she had a blog because she felt like writing about how disappointed she was. I felt similarly; it seemed that the store lived up to little of its advanced billing.

• One row of produce with all produce wrapped in plastic.
• Many rows of the usual packaged goods (cereal, toothpaste, etc.) but with surprisingly limited selection in each category.
• Low shelves to create an open feeling but with rows ending too close to the edges of the store, creating congestion at the endcaps.
• Dairy and other products paired with organic equivalents, but with excessive price premiums for organic, and par or higher prices for the standard.
• 100% self-scan checkout, but with none of the visual or geographic cues that would help patrons unfamiliar with the store (as all are at this point) queue up efficiently or navigate the checkout system quickly. People were so confused just trying to choose a line that staff were stepping in to ring people up just to create a sense of order.
• The offer of “$5 off your first order of $20 or more” was marred by a (common) alcohol restriction and a (surprising) dairy sctrictre, making our $32 tab (how did we spend over $12 on dairy?) ineligible for the discount.
• And the “free reusable shopping bag, replaced for life?” A common medium-gauge plastic bag with thin handles, little better than the usual grocery-store plastic bag we hope to displace with reusable bags.

Truly forgettable.

What does this have to do with software design? Your product has to do what it says on the box.

The top claims your product makes are those captured in the name of the product. Fresh & Easy needs to be thoroughly both. If it is Fresh-ish and sort of Easy, you lose. In Fresh & Easy’s case, the produce was fresh, but this freshness was masked and made uncertain by overpackaging. The environmental message was further diminished by this overpackaging. And there was little ease navigating the poorly-laid out transverse aisles or the unfamiliar checkout. Never mind that customers take longer to check out when self-scanning, and feel personally responsible for system errors while scanning, both facts further diminishing any sense of ease.

The secondary claims made in advance of a sale are also important; it is with these claims that you hope to position your product, align it with the wishes of the customer. Follow-through is essential. The non-environmentally-friendly and frankly quite substandard “reusable bag,” the high prices, the narrow selection (you can have Yoplait or the store brand of yogurt, for example), and the complete lack of pleasant retail surprises all fly in the face of claims made on the Fresh & Easy website and the several direct mail pieces they sent to neighborhood residents in advance of the opening.

To my wife, this lack of breadth, of depth, and of the human touch smacks of cynicism befitting Fresh & Easy’s parent company, UK retail giant Tesco. We were prepared to give Fresh ‘n Easy the benefit of the doubt, but we have already tagged the store as “emergencies only.” And we’re already calling it “Fresh and Sleazy.”

2 comments

Monday 10/15/2007
Design

Every time I elect to subscribe to someone’s RSS feed I am presented with this well-meaning page:

I have NEVER clicked on “Add to Google homepage.” I ALWAYS click on “Add to Google Reader.” Google probably knows this. I grab and shed feeds rather quickly, so this page is a frequent (and frequently annoying) interruption to my RSS-snarfing routine. In the words of Nancy Kerrigan: “WHYYYYYYY!!?”

Granted, this is a small annoyance. But fostering pleasure in use, beyond simple usability, is primarily concerned with removing (large and) small annoyances. Perhaps a checkbox: “Remember this choice?”

No comments

Tuesday 10/9/2007
Business, Design

I received an eVite today, the first in a long while. It was not a great experience.

Strike one: lack of context. The HTML email message was pretty, but nearly information-free: it contained the sender’s name, the name of the event, and a smattering of descriptive text (that the sender deliberately kept short). No location, no time, no date; for those I would have to click through to eVite.com.

Without at least the date I couldn’t assess the urgency of the message. Is it something I need to deal with right away? Can it wait until I get home and put my daughter to bed? Can it wait for a few days, maybe until the weekend? The most important information an invitation ordinarily carries is actually hidden! Furthermore, not all of the invite graphic is clickable; a faiir portion of it is not. Obligingly, I found a clickable portion and clicked through.

Strike two: poor prioritization. The most prominent elements in the page at eVite.com are the ones I care about the least. In order of apparent priority (what draws the eye first):

1. The main graphic for the invite
2. “Guest Options” links (mostly useless or out-of-place)
3. eVite logo and tabs
4. Two ads from the University of Phoenix
5. The guest list
6. “Reply here” box
7. A “New! Send to Phone” button
8. “Plan your next event”
9. “Free eVite Cards”
10. Footer navigation and administrivia
11. Information about the event, including venue, time, date, and blurb.

That’s right, the very reason I came to the page is the LEAST prominent segment of the page. For a moment there I didn’t even see it, and was ready to accuse eVite of completely fouling things up. As it is, they’ve taken the part of the experience that I care about the most, and shown that THEY care about it the least. This is backward.

Des Traynor points out that a quick way to evaluate the user-centeredness of a page is to grey out the portions that the user doesn’t care about, and see what you have left. Rather than do that, I’ll desaturate the page and highlight the parts I DO care about with big yellow boxes.

(I’ve obscured parts of the image that identify other folks.) There’s a lot there that I don’t need, and most of it is high on eVite’s priority list. The meat of the page, the main event, the reason this page exists at all accounts for (charitably) 28% of the real estate and much of it is de-emphasized.

Strike three: poor organization. eVite’s difficulties with the prioritization if the invite page probably mask other usability and appeal problems that appear there, mostly due to the “I give up” “Guest Options” box of links that appears to the left of the Guest List. Guest Options contains a jumble of links related to disparate user tasks and far-flung parts of the interface. “Invite more people” and “Remove me from guest list” are strongly conceptually associated with the Guest List, while “Send a free Evite eCard” and “Go to Carpool Page” are not (and are heralded elsewhere). None of these are “guest options” so much as additional or alternate functionality, and they should be treated in context with the content they seek to modify or operate on.

It will be difficult to put these functions in their proper places until the prioritization is fixed, but here are a few additional suggestions:

• “Send to Phone” and “Add to my Outlook Calendar” are most strongly related to the “When” portion of the invite. “Add to Calendar” is really only useful if I plan to attend or am a “maybe,” so making these options part of the reply form is another option.
• “Email me when Guests Reply” (what’s with The Bizarre capitalization?) appears as a link in “Guest Options” and as a check box on the reply form. The check box should be sufficient, although eVite has bloated this functionality by allowing you to further choose to watch only specific invitees.
• If we believe in direct manipulation, “Remove me from Guest List” probably should go with my entry on the guest list.
• “Go to Carpool Page” is a problem; it suggests that I’ll be taken away from the invite. Maybe I’ll lose my place? Already I am disinclined to click the link, although it may prove useful.

Strike four: print. The parts of the invite I am likely to want to print include the title, venue/date/time/blurb, host name and contact information, and (perhaps) the guest list. Using the “Print Page” just fires window.print(); , printing the entire page including the (useless on paper) tabs, “Guest Options” links, “send to phone” button, footer, ad banners, and reply form, with nary a print style sheet in sight. Easy to implement, sure, but NOT USEFUL. And a lightly-populated eVite prints on two pages with all of that needless content because the footer bloated with “partner sites.”

But wait, there is more.

1. The “Yes/No/Maybe” radio buttons in the reply form have unintended consequences. Selecting anything other than “Yes” disables the “I’m interested in carpooling” check box. But what if I am a “maybe” until I can get a ride? Trying to fake out the system by checking the box and THEN selecting “maybe” fires an annoying alert(); complaining that “You cannot participate in carpool if you select no or maybe.” Umm, thanks. Watch me! I’ll get a ride with someone, and we’ll point and laugh at the eVite carpool cops when they come to arrest me.
2. Out of curiosity I click on the “more info” link next to the “I’m interested in carpooling” checkbox. The page grows to include a little text telling me that I should continue clicking to learn more. isn’t that why I clicked “more info” in the first place? Weird.
3. Some of the ancillary functionality fires popups, and some of it takes me away from the invite. There seems to be no standard; “Invite More People” navigates away from the invite, and therefore away from the context I might need to choose people to invite (such as the Guest List, yeah?), while “Email me when Guests Reply” fires a popup that contains the guest list. I’ve given up trying to guess the reasoning behind these decisions.
4. “Add to my Outlook Calendar” fires the download of a VCS file. What if I use iCal? Google Calendar? Notes? Can I get an ICS, anyone?
5. It turns out that the “Go to Carpool Page” does take me away from the invite; it shows me a pretty map and has ABSOLUTELY NO CALL TO ACTION whatsoever until I notice that at the top there is a tiny message claiming that “You must reply ‘Yes’ to this invitation to join a carpool.” Thanks so much for your help.

Make no mistake, eVite is trying to do a lot on this page. But it does not appear that they have chosen carefully which of these things to emphasize and streamline for their users, nor have they chosen any particular facet of the experience to do particularly well. The overall flavor is that of an organization attempting to compete on the length of its feature list rather than the usefulness of any one core combination of those features.

I haven’t replied to the eVite yet, nor have I sent one of my own. If this episode is typical of the eVite experience, I’ll have more to write very soon.

No comments

Friday 9/28/2007
Business, Design

Jason Fried over at 37signals mentioned today that he gets a lot of questions about “growing the business”: why aren’t they, when will they, etc.

They don’t plan to. Not in the traditional sense, by hiring. What’s important here is that they have oriented their business, and especially their products, to succeed without requiring additional head count. This means:

• fostering self-service to minimize personnel required to do routine account service (billing, signup, cancellation, etc.),
• improving usability and intelligibility to minimize personnel required to perform technical support,
• measuring their ability to keep customer support workload down even as enrollment grows.

I happen to work for a major medical device manufacturer, and I don’t think I am revealing any secrets when I say that while we talk a good game about fostering self-service and making our products easier to use and just plain figure out, we’ve nearly doubled our sales force and our customer service head count has grown significantly. It is nice to “show commitment to customer service,” but this is an expensive way to do it. I suspect we and other manufacturers (and our customers) would be much better served by an orientation similar to that of the 37signals folks.

I suspect that the groups that conceive of, design, develop, and build our products do not work toward metrics that encourage the reduction of customer service load, except when it comes to specific problematic features of already-released products. As Joel Spolsky once put it, “you get what you measure.” We are getting a product every 18 months (metric: schedule) that does more than its predecessor (metric: can we sell it) and is more reliable (metric: returns per thousand units shipped), but isn’t necessarily easier to use, more appealing, more pleasurable to use, or requiring of less support.

Here’s where the story gets interesting. Were we to add the missing metrics and do nothing else, suddenly these products (which dominate their market) would be scoring very poorly internally. There would be great pressure to stop using the new, bad metrics, because they wouldn’t seem to have a relationship to revenue, which would probably remain high. But adding metrics such as total cost of support per thousand units shipped would solve the second problem : you can’t solve a problem (the first problem, the real problem) until you measure it, which is a form of admitting that it exists at all.

Were we to add the missing metrics and suffer a while with unhappy numbers, sooner or later people would start asking what could be done about them, and one or more of three basic responses would emerge:

1. Distort the system
2. Distort the numbers
3. Improve the system

Distortion of the system might occur were we to outsource a component of our support functions to lower its cost. Such a move would result in lower total support costs for any product shipped thereafter, but not because the product improved. Something to watch out for.

Doing away with the “faulty” metrics would be an extreme form of distorting the numbers. A more likely form would be to adjust what costs make it into total cost of support, or narrowing the timeframe over which that total is recorded and/or projected. Perhaps initial training costs wouldn’t be included, or only support costs in the second, third, and fourth years (once the less certain users shake out) might be tallied. In either case, we’d be back to denying the problem rather than measuring it.

Improve the system? Lets, please.

No comments

Saturday 7/21/2007
Business, Design

Getting to know your customers is both fashionable and a good idea. But if you work for a large corporation, you may find several obstacles to forming a direct relationship with customers. All is not lost; you can kick-start your customer research by looking within your company for evidence of user experience problems.

1. Technical Support : Customer support is an area of great expense for most companies. If you have a technical support or customer service staff, you have a rich source of customer complaints and difficulties. Most technical support groups keep track of how many calls they get about a particular issue so that they can decide what to focus on. Commonly, these groups are also aware of trends in customer concerns. Too often, this information is not adequately employed by the rest of the company to actually make improvements in products. Find out what the top issues are. They might be complaints, or they might be “educational calls,” questions users commonly have about how to use the product. Also ask how much such a call costs the company. If you can make a fix to the product (or its documentation) that reduces call volume, and you multiply that reduction by the cost per call, you’ll know how much savings that fix can the company. if that fix reduces the number of products returned, or reduces abandonment of your service, etc. then it has even greater power.
2. Training and Education : If your company provides training or education to its users, the trainers will know what parts of the product users have difficulty learning. Improving usability and intelligibility in these areas will improve customer satisfaction and make the trainer’s job easier. In addition, the trainers will be able to point out features that are difficult to explain. A feature that is hard to explain often hides a usability problem. Trainers will primarily be concerned with features and processes that the user employs during adoption, while they are setting up and getting to know a product. This is when most returns happen. Returns are costlier to the company than a failure to sell the product in the first place, so initiatives that lead to a reduction in returns have a direct impact on the bottom line.
3. Technical Writers : The folks who write your product’s documentation will also be able to point out features that are difficult to explain or procedures that seem needlessly complicated. Asking a technical writer “what about this product is hard to write about” is not likely to receive a good response (tech writers are a proud bunch), so an approach that focuses on their impressions of the product and the amount of time they spent investigating one or another feature is more likely to be successful.
4. Product Documentation : If this fails, read the documentation yourself. You may be able to detect passages that treat parts of the product too lightly, dive into excessive detail, or rely on convoluted explanations. Pay special attention to the “troubleshooting” section, if any. What would benefit from clarification in the interface, reduced user decision-making, improved information design, etc.? Are there troubleshooting operations that the system should be able to perform? Are there troubleshooting situations that arise from otherwise well-intentioned user action?
5. Field Sales Staff : Outside salespeople have a unique view of the customer. Their job is to uncover customer needs and match those needs to a product, ideally one that your company sells. They are extremely competitive and may know more about your products and the competition’s products than anyone else in the company. They are intimately familiar with customer needs, especially those that potential customers ask about. And they have a knack for collecting pre- and post-sales feedback on a product. Their assessment of customer need is largely based on what the customer says rather than what the customer does , so be careful. But getting to know the salespeople can also shorten your path to customers; the sales staff will be happy that you re taking an interest, they will probably think that customer will also be happy that you are taking an interest. There’s a strong chance that a salesperson will see getting you in front of a customer as a triple win: the salesperson can use you as an excuse to visit the customer and show the customer that the company is interested in them and their feedback; the customer gets an opportunity to explain their unique situation and feel that the company is hearing them and valuing their input; and you get direct insight into both a individual customer and the sales process.
6. In-House Sales Staff : Inside salespeople have another perspective on the customer; these folks are shepherding the most interested potential customers through the process of making a purchase. In addition to gathering all of the requisite customer and payment information, they must overcome last-minute nervousness and concerns raised by the buyer. The most common of these reveal product deficiencies, competitive weaknesses, or negative emotional components of the product experience.
7. Try It Yourself : Whether or not you have ready access to users you should become one, even temporarily. Give the product a thorough tire-kicking, making special note of things that seem odd or are not well-explained, operations that seem complicated, places where you don’t have all of the information you need to make a decision. Trying it yourself will give you direct insight into the situations your users face and help you smooth the rough edges of interactive and informational design.

No comments

Tuesday 4/3/2007
Design

No video? See it at BrightCove .

Key points from the talk:

• The design process, while iterative, is largely a destructive process, where many many ideas are generated and nearly all of them are eventually thrown out. Quality at the end depends greatly on having a large quantity of options to sift through at the beginning.
• A sketch is not a prototype. Sketches are for ideation, for getting the right design, for working on the large strokes in advance of selecting a direction. Prototypes are for getting the selected design right, for usability and refinement in advance of implementation. Much of the recent writing about design processes have focused on the refinement of a chosen design.
• A designer should come to early meetings with five or more sketchy but viable designs and no favorite. This makes it possible for critique to be about the design and not the designer; if the designer has made up her mind, then a battle of wills is likely.
• “If a sketch was made in a forest and nobody saw it,” it isn’t really a sketch. A sketch is a social artifact. Cover the walls!

One comment

Wednesday 5/31/2006
Design

Crossposted from the new Voices of Experience forum at Improving Customer Experience :

At work we’ve recently begun some serious (read: crash program-style fast and furious) work on an embedded software interface for a small handheld device. It isn’t a sexy device, few consumers will see or want it, but I suspect some of the lessons there map to web pages, packaged software, etc. (I’m omitting customer service stuff on purpose and focusing only on user interface concerns here.)

Some of the most important issues are low-hanging fruit, and some are real sticky problems involving a confluence of labeling, workflow, IA, and tricksy device limitations. They are important because they represent difficulties testers and/or users had with the top use cases.

It seems like I’m begging the question, but I’m not. A top use case, for us, is one that is crucial to a person’s adoption of the device, day-to-day use of the device, or is bound up with a safety or security concern. There could be many of these, but likely there are even more use cases that are not “top” in this way.

Adoption: concerned with the out-of-box experience. How easy is it to get started, enter initial settings, etc. The use cases in these areas are primarily “for the business,” but without smooth function in key adoption use cases, the user will abandon, make a return, incur additional support costs, be forced to turn to the manual, become frustrated, etc. Successful design of the components of these use cases will result in initial user feelings of ease and quality. In a typical eCommerce environment (boutique sites with not much repeat business) these might be related to browsing and finding products, adding them to a cart, checking out for the first time. These are often “gating” use cases, where failure would prevent further progress.

Day-to-day use: concerned with the most frequent and/or useful repeated operations that a user is likely to encounter. The use cases in this segment are definitely “for the user” and affect the user’s overall feelings of ease and sure-footedness using the device. In a heavy-duty eCommerce environment such as Amazon this might include things like reviews and ratings (reading), wishlists, serendipity links, saved shopping cart contents, payment management, order history, etc.

Safety/security: if a feature or operation is critical to the safety of the person using the device or the security of the data contained within, then it behooves us to make that function as well as we possibly can. eCommerce: account management, login, etc.

With an existing product or launched site or service you can learn where the problems are from a variety of sources: support calls, returns, education and training (trainers will talk your ear off about what parts of the thing are tricky to explain or require extra handholding), the sales staff (who may hear complaints in the field). This introduces office politics and costs at various functional areas into the mix. There may be a revenue, support, or rework cost that is so high, once it is trapped, that it would be folly not to handle it. Without cost information, silencing the most frequent complains is often a good place to start.

For a new product, ideally you have a solid sense of what the top use cases should be, if the product is at all well-defined. This is where user testing comes in. You’d be surprised how many top use cases are either A) more badly broken that we imagined, or B) seem potentially broken but actually present no problem to the user. You can only identify how well and truly broken (or OK) a use case is by testing the darn thing with actual people, one on one. It doesn’t take many and doesn’t have to be expensive, and using user testing as a design input in this way can help immeasurably in the identification and dispatch of the real important problems.

You’ll notice that for both existing and new products, we can measure the effect of our work on the problems. Costs and incidence go down for existing products, and testers are more successful navigating the product’s top use cases in a newly-designed product. Either one can be measured numerically, which your boss will like.

No comments

Sunday 1/8/2006
Design

I ought to clarify what is happening here.

First, this is a live redesign. This is not the sort of thing I would ordinarily do, since all of the rough edges, design holes, and conceptual flaws are open to the casual observer, a situation I loathe. Rather it is a device to goad myself into making the damn thing work already , with the added prodding of my friends (especially Nils , who has been the most vocal of those insisting I get my thoughts back onto the web.

Second, I have some mildly radical ideas about how to handle archives and whatnot, and I’ll be experimenting with them here. Y’see, I’ve never been satisfied with the way that most blogs handle old entries. Some blogs are searchable, some you can browse by date (a feature I’ve never found useful, since I am sure you wrote a little something about a particular topic but I am never sure just when that was), in almost all you can look at a listing of old work by category, but only rarely are those categories sufficiently meaningful to help winnow the content enough to make browsing successful.

Besides, categories are much like folders: a seemingly logical one-to-many classification system that is hard to maintain and hides relevant content in a single location. Sure, people are starting to use tags, but unless the tag set is well-maintained, you’ve got a content fragmentation problem that is the flip of the categorization problem. And don’t get me started about tag clouds! Anyone else find these a waste? (Show of hands.) But I digress.

In print, at least, I find it pretty easy to skim a list of well-written titles (such as the chapter and section titles in a thoughtfully-constructed table of contents) while looking for something relevant, so I’ll be experimenting with that idea here. On the homepage (“the latest”), below the most recent entry and some associated whatnot, I’ll drop a list of titles (“the digest”) in an attempt to foster this sort of skim-browsing. This will depend, of course, on well-written titles.

There’s also the wee problem with entry types. Not categories (bees, food, weapons), nor sections (news, features, business, local), but the kind of content represented within an entry. I find that I have a desire to write a long entry occasionally, but am much more likely to dash off a small handful of asides here and there, and need somehow to accommodate these two flavors of entry, with appropriate attention to the design and metadata requirements thereof. So I’ll be fooling about with some options there. (A classic example of asides: Jason Kottke’s Remaindered Links .) The first attempt: put the most recent handful of asides just below the latest long entry, with its own XML feed, and capture a larger set of them on a purpose-built archive page.

Third, this is an experiment in vertical rhythm. While I have successfully cajoled more than one colleague into attempting to establish a baseline grid one website or another, I’ve never given it a solid try myself. The vertical pacing that a baseline grid lends (and the typographic options that are suggested and/or denied by same) can do wonders for a layout much as a horizontal grid does, but they tend to be sparsely represented on the web due to how type must be specified in CSS. I’ll try some techniques here, and as I experiment and uncover the vagaries of type on the web, I’ll write more about this.

Anyhow, mind your head. Most everything is not in place here yet.

No comments

Tuesday 6/29/2004
Design

I post infrequently enough that you wouldn’t have noticed, but I’m on vacation. Maui, to be precise. It is lovely, and the Junetime habit of the islands (sun during the day, rain at night) makes for lovely slumbering.

It seems that I can’t take a vacation from usability critique, or more likely usability problems , try as I might.

• Shortly before leaving for Maui I purchased a pair of sandals at Nordstrom, the kind commonly known as flip-flops. After trying on several and noticing that most had poky seams right between the toes (a design mistake of staggering proportions), I settled on a very cushy, ventilated pair that felt more comfortable than most. But a few hours’ continuous wear revealed that they too had poky seams, near enough to the tender skin between the toes to be just as uncomfortable. And the first pair of el cheapo drugstore flip-flops I tried here on the island was twenty times more comfortable, and a fifth the price.
• I’ve barked my shin on the lower dash of our rental car six times already, and we’ve only been driving it a day and a half. It juts out at an aggressive angle, preventing me from putting my foot directly on the brake as I climb in. I suppose I’ll eventually learn to step into the car in a different way, but I don’t remember having this problem in any other car I’ve driven.

These are merely emblematic. It is lovely here, and charming, and comfortable. Quibbling about minor ills such as these seems petty, really. But it does remind me of a nearly forgotten old mantra of mine: Design Everything . One should strive to design everything that one has some measure of control over. Of course, everything is designed already anyhow, but adding your experience to the mix could well improve it, or yourself, or both.

Much here has the old, low-road charm of vernacular design, things built and genty refined and worn into the most efficient, useful, or usable forms possible. A hand tool is not really truly usable until it has been well-used and repeatedly sharpened, taking on the curvature of the user and the work being done. Buildings, especially dwellings, are the same way. Materials are expensive, so there is a lot of re-use, jury-rigging that becomes permanent, and evolving structures built on an original temporary or reappropriated core. It is not polished, modern, or minimal. But usable and useful? Yes.

No comments

Thursday 6/24/2004
Design

From the AIGA website:

The complete set of 50 passenger/pedestrian symbols developed by AIGA is now available on the web, free of charge. Signs are available in EPS and GIF formats.

AIGA forgot, however, that not all of us use Macs. The very nice set of 50 symbols is only available for download from AIGA as an SEA file, contains EPS files without .eps extensions, and filenames are replete with slashes and asterisks which make Windows machines unhappy. It would have been much more helpful if AIGA had named the files in a cross-platform manner and also provided a ZIP file of the same content (since relatively few PC users are even aware of Stuffit Expander).

A few moments with AppleScript and MacZip and here you go: AIGA Symbol Signs, now PC-friendly .

No comments

Friday 6/18/2004
Design, Implementation

A number of individuals have posted on their sites handy Pantone Matching System (PMS) to RGB color conversion charts. A freshly-minted example of such a chart has made the blog circuit recently (but I’ve lost the link already). Since there are so many PMS colors, even the standards-based online PMS charts can be hefty downloads.

Poking around the net, I found one such chart that seemed official, it being Pantone branded and all (sorry, lost it just as fast). It was a pretty simple matter to use a regular expression to strip the color names and their RGB approximations out of the HTML and slap ‘em into a JSON object, then write a little script to crawl that object and write some simple XHTML to display a panel of swatches.

You can grab it at http://jonplummer.com/misc/pms.html . I suspect I’ll be making this prettier (and searchable, etc.) later, but at the moment it is reasonably useful, and a svelte 24KB (as opposed to the 240KB or so of many other examples). I’d love to hear your ideas about how to make this set of swatches more useful.

3 comments

Friday 5/21/2004
Business, Design

Boxes and Arrows continues to publish insightful and relevant articles. And the fact that two of my recent favorites just happen to include the words “Design Success” in their titles isn’t a factor, no siree.

Most recently, Understanding Organizational Stakeholders for Design Success details a method for performing stakeholder analysis , an exceedingly useful technique that helps one see clearly the political forces surrounding a project, and guides thinking about managing the players involved. Quite nice work, and worth a read whether you’re into building websites or not.

Less well written but equally valuable is Building a Vision of Design Success , underscores the oft-forgotten point that even in a redesign project, the definition of success must be thoroughly nailed down; the fact of re-designing is not enough. Management consultants would instruct one to “determine key success factors,” but more than that is required; Christina Wodtke points out that

A shared vision is born of collaborative conversations, articulated in a form that is digestible and memorable, and then internalized and personalized by every member of the team. The power of the shared vision is that it is shared�it is held within every member of the team (or organization) and thus needs no leader to carry it forward; every action of the team helps make the vision real.

I have been involved in several redesign projects of various sizes, and I can say with confidence that in every case there has been a distinct lack of vision, much less shared vision. And it is this lack that I hope to prevent in the future.

No comments

Thursday 5/20/2004
Design

Apple has done a reasonably good job of making ZCN (Zero Configuration Networking) a reality; now what we need is “ZCE,” Zero Configuration Email. Or at least Minimal Configuration Email.

Isn’t email easy enough? Well, no. My wife has been pretty troubled by ever-increasing rates of spam on her trusty Yahoo webmail account, so it is no more. Instead, she’ll take advantage of an account provided by her web host. Here is where the trouble begins. It seem that her email address and email “mailbox” must have different names, and she’s got to juggle the various names and passwords and security minutiae to get even the friendliest of email clients running smoothly. Since she’s not a techie, the “annoying technical inconveniences” ceiling is rather low, and I’m afraid I just helped her whack right into it by suggesting she use more than one mailbox, one personal and one commercial. It would be ideal if she didn’t have to dirty her hands with this, while somehow protecting her privacy by not divulging passwords, etc. to a third party (such as myself).

I’m not sure how best we would securely transfer the necessary settings, however. Many email clients can import email accoutn settings from one another; maybe if there was a standard (or de-facto standard) format, a host could slap together a little packet of settings for download?

No comments

Sunday 4/25/2004
Business, Design

We’ve recently heard tell of ways that users “get around” what they find inconvenient about our therapy management application. I find this sort of revelation surpassingly interesting because it reveals not only deficiencies in the application, but new ways that people want to use it.

It is almost as if they are writing the requirements for us. They’ve identified a need, identified a workaround, and put that into practice, thereby defining the minimum required level of functionality.

Excellent stuff. While I shouldn’t go into detail about our particular situation here, I plan to write a bit about this in the coming days.

No comments

Friday 4/16/2004
Design

Jeff

interesting: http://daringfireball.net/2004/04/spray_on_usability

Jon

I read that; it sums up a few of my feelings on the matter pretty well. 1) what problem are we trying to solve 2) for whom, and 3) who will be doing the work? How can we help person 3 do task 1 in a way that will satisfy both person 3 and 2?

Jeff

i think from my perspective, it brings to light our (programmers with programmer mentality) inexperience with user interfaces

Jeff

we (developer-oriented thinkers) tend to believe that we can do it “better than average” when in fact most of us REALLY suck at it, we just skate by on copying what has been done by people who really are “better than average”

Jeff

also reinforces the idea that it really is hard fricken work to design stuff well :)

Jon

I’ve never found an interface that I liked that I could have built thinking of it in a programmatic way, or applying a methodology; it’s iterative, recursive, a design problem in the truest sense. The thing usually missing is pre-testing, prototype testing. There’s never time for that, it seems; everyone wants to build first and ask questions (or fail to) later

Jeff

it is also somewhat difficult for us, who were not raised on computers, but learned computers after learning many other gadget type things

Jon

Really? I would think it would be easier

Jeff

well, we are trying to be “intuitive”… but how is it kids can figure things out so easily… i imagine when some of these kids who were raised on computers get to our age, they may have some better ideas, because their thinking wasnt molded by the same technological “advances” as ours

Jeff

but then again, the converse may also be true, where that predisposition to current UI in computers would mold them into the same “bad” habits

Jon

What with all of the simpler, single-purpose “interfaces” we’ve grown up with and all of the “real-world interface metaphors” to draw upon, you’d think “intuituve” would be easier, but the real problem is that intuitive is the wrong word

Jeff

yes, it is

Jeff

which i finally understand :)

Jon

Plasticity helps kids adapt more readily; experience helps us make decisions, if we can just get away from the prejudice that comes with (and the ego)

No comments

Tuesday 3/30/2004
Design

Recently I began an interface review for a well-known medical device manufacturer. These folks are pretty well plugged in to who their customer is and what is important to them; they sell their medical devices directly to users, who wear them constantly and are vocal in their feedback and eager to help improve the products.

I figured that it would seem inappropriate, then, to begin an interface review in a traditional User-Centered manner, questioning the great body of express and implied market research that the company has done. Rather, it would be nice to apply what I already know from User-Centered design to a more task-oriented approach. And while I am aware of many resources specifically dealing with Task-Centered Design, I wanted my analysis to have my “flavor,” to be suggestive of what I find important when doing task analyses and the like. So I began to winnow down my thoughts into loose task-centered design principles, which are still rough.

Expect revisions.

All of these stem from a central idea which I find simple and powerful: Transfer as much workload as possible from the user to the developer . Every moment of navigation, investigation, confusion, even simple use of your device/tool/application/web page that you save an end user, multiplied by the number of users, cannot help but eclipse the work required to get the interface right, unless you actually fail to sell the thing in the first place, which is a different problem.

So! Eight principles, a first crack:

Anticipate user tasks

Give priority to the most important and common user tasks. When in doubt, fall back on the questions, “What does the user want to do? Need to do? What do we want the user to do?”

Expose system state

Bring relevant indicators of system state out from hiding places. Reduce the amount of trial a user must endure to learn about how the system is configured. Bring a meaningful small datum to the surface.

Provide clear affordances

The proper action of the user (and, ideally, the proper action of the system) should each be suggested by the control; each menu item should suggest its consequences.

Anticipate problems and lead the user to the solution

Avoid errors by guiding the user, signaling correct input, removing invalid choices, etc. When errors occur, explain the problem and guide the user in dealing with it using positive language. (Error messages should have a positive component as well as the usual negative “a bad thing happened.”)

Reduce the time/operations to complete tasks (especially gating tasks)

Make common and/or important tasks quick and easy to perform, especially if the task lies between the user and a task at the heart of their ultimate goal.

Reduce ambiguity/enforce useful consistency

Consistency enhances recognition, which is more reliable than recall. Consistency can also help the user feel at ease in unfamiliar sections of the interface. BUT! Consistency is a tactic, not a goal.

Provide consistent/useful/meaningful defaults

There are situations in which a control’s default setting should be its most recent setting, and there are situations where it is more useful to steer the user down a particular path.

Judiciously increase “power”

Add details to the interface that can speed input and navigation for frequent users without disorienting novice users.

These principles, in the clear light of day, may not all be principles, may contain redundancies, etc. And, naturally, since I copied these directly from my presentation notes, they are slanted quite heavily toward the client in question and their specific needs. I will continue to work on these; more later.

No comments