Is Walk up and Use a Myth?

By Jake • November 17th, 2009 • View Comments

Simplicity

Simplicity by Eric Burke

Eric Burke published this cartoon back in early 2008, and it’s stuck with me for a long time as something that is simultaneously hilarious, sad and maddening.

I started my career in development building those eye-chart apps with fields and labels all over the place, complete with the obligatory button bar. Enterprise apps are complicated.

Whether or not they need to be is fodder for discussion.

When we started this team a few years ago and began building web apps like Connect and Mix, we tried to make them as easy to “walk up and use” as possible. For the uninitiated, “walk up and use” is a design principle that assumes something is so intuitive it does not require training for first-time users.

But even after several years of tweaking the interface, I still get requests for training and documentation.

This could mean one of two things. Either the app isn’t as intuitive as I think it is and needs to be redesigned, or people are generally hesitant to walk up and use any new application without some training.

I suppose it could also be a combination of those two.

Web apps are generally accepted to be simpler and therefore easier to use than enterprise apps, but even so, I’ve heard people complain that applications like Facebook and Twitter are hard to learn. At first blush, this sounds nutty, but I suppose there are areas of each that could use some redesign, e.g. Facebook’s privacy controls and Twitter’s @ replies.

Obviously, some apps are developed for the literal scenario of “walk up and use”, namely self-service, kiosk-type apps like Redbox DVD rental or airline self-checkin. Again, as with web apps, I’ve been in situations where people have asked for help with these apps.

So, if even the simplest apps have users asking for help, maybe “walk up and use” is a myth.

If you assume it’s a myth and regardless of what you build, you’ll need to train people, why worry about design at all? If the app is functional, who cares what it looks like?

That’s a rhetorical question because it does matter. I’m just throwing it out there.

One interesting factor to consider is the intersection of play and work, Paul’s favorite area for noodling. If your app is engaging and fun, users are more likely to go farther to learn how to use it, instead of falling back on training immediately.

Back to Burke’s cartoon, I think it was more a funny observation than a broad brushstroke conviction of enterprise application development. Like I said, it’s funny to me, as well as sadly spot on and a bit maddening because it feels like an impossible trend to reverse.

The comments are interesting and worth a read if only to observe the reactions he elicited.

Generally speaking, most apps are used by very few users, call it a long tail of usage, which hinders the advancement of their design. Almost 100 million people in the US alone use Facebook each month. How many people use your company’s Accounts Payable application?

If design is driven by use, apps behind the firewall will never attain parity with consumer-facing apps.

So, I don’t think “walk up and use” is a myth, although no example fits 100% of the time. I still think it’s a desirable attribute for all apps and possibly attainable, through unorthodox methods like game mechanics.

What do you think? Find the comments.


Possibly Related Posts

  • We are currently developing an enterprise app that is essentially a port of a legacy client-server app used internally but adding a customer-facing portal to it, too. On one hand trying to keep things as familiar as possible to internal users but on the other as intuitive as possible to customers has proved to be quite an interesting undertaking. Add to that the usual time and cost constraints and you end up taking a rather pragmatic approach to development.

    Many enterprise app projects are also rushed through without anyone truly skilled in UI design, so it's no wonder if the time sheet and expense report apps end up like the one in the cartoon.
  • Amen. I like the phrase "interesting undertaking", if only b/c I know it's a massive understatement. I'll bet the vast majority of homegrown enterprise apps (those built for use by a company inside its own firewall, not those sold to companies by big software companies) have no design considerations *at all*.

    Face it, when IT (or any internal group) builds an app for use within the firewall, time/resources are always a problem, and no one views design as a must-have.

    I don't think Burke misses that point, rather his observation is just a witty way to point out the disparity.
  • The way I see it is the next evolutionary stage for Enterprise Apps is Walk Up and Use. I don't mean just the interface but both IT perspective (cloud apps) and design perspective (simple apps). If the big corps (including Oracle) are late to this, startups will take advantage and do this. Like mint.com did to Quicken (i know its consumer product again) but lately I have been seeing lot of BI startups, like Indicee, which are doing exactly that.
  • There are problems when you have longtime users who pay for your software, as I mentioned in my reply to John. Redesign means retraining, which is an additional cost that can put-off your customers. Add backward compatibility, and you're on a treadmill providing incremental enhancements.

    Startups have the ability to start from scratch, which allows them design freedom. Since Mint was recently acquired by Intuit, maybe the answer here is to acquire startups that are doing it right, aka threatening your core business :)
  • Another possibility is to threaten your own core business - i.e. set up the new app yourself and somehow entice your customers to transition from the legacy app to the new app. There's obviously a danger in this, since if a legacy app user is looking at your app, they're obviously more open to looking at competitor apps.

    Unfortunately I don't really know anything about Oracle's vertical apps, so I have no idea how their planned transition from the acquired apps to the new fusion line will work out. It will be interesting to see what happens.
  • Well, as I've said before, I don't think users want innovation, especially enterprise users; products like Mint and Intuit are consumer products that have low barriers to exit, making it easier to try new products. Enterprises don't have that luxury.
  • Gary
    A "C:\>" DOS prompt has the simplicity of a google search box. A simple command like "FORMAT A:\" would result in a complex operation.
    Just because an interface has lot of 'boxes' doesn't make it hard to use.
    It may be scary or off-putting which is when those multi-screen wizards became all the rage, but all they did was scatter the boxes across different screens.
    A data entry screen will, by necessity, have a lot of fields. A dashboard interface will probably have half a dozen indicators.
    That said, the UI of many applications could be improved simply by separating out the common and uncommon operations. And it would be nice if apps would start to take a single address field and parse it out themselves rather than require us to separately enter city/state/postcode/country....
  • I agree that forms filled with fields aren't difficult to use, but to the eyes of an average user, forms are busy and require thought whereas consumer apps are much less cluttered.

    I've always preferred a single form over a wizard, if only because I can see all my input on a single page.

    Separate fields for an address is a usage problem, i.e. people are accustomed to it so designers flow that way by default. Learned behavior is tough to overcome, and that one comes from the days of paper forms. Good luck.
  • "Walk up and use" is certainly a goal, but it is admittedly hard to realize, in part because of the different experiences of users. I'm sure that you encounter this in your development work. In my company's particular case, our application is used by people with different goals, ranging from qualified latent print examiners who focus on fingerprints all the time, to embassy personnel and cops for which the fingerprint work is just a small part of their duties.

    In addition, since we've been providing this application for decades, a certain set of expectations has developed. While someone in a vacuum might design the application one way, once you step out of the vacuum you realize that our users (most of whom are repeat customers) like the application just fine the way it was in the previous release, and in the release before that. As a result, the application has legacy screens that do things a certain way because that's how we've always done it.

    With such variables, it's difficult to design a "walk up and use" application that will satisfy everyone. Perhaps the "skins" concept may be appropriate here. Our application really doesn't use it, and I haven't seen it in the public-facing Oracle online applications, but maybe we simply need to acknowledge that one size does not fit all, and that different users have different interface needs. The problem with a "skins" approach is that it adds to the complexity of the application.
  • I suppose I should have pointed out that "walk up and use" is more a goal for the designers of at-will apps vs. must-use apps. At-will apps must be easy because they aren't required; must-use apps don't have to design for engagement as purposefully.

    Excellent point about expectations, which weighs in much more heavily when your users pay for your software and want to pay (in money, time, lost productivity, etc.) as little as possible for retraining.

    Skinning is great, but usually, it's limited to CSS elements. If skins actually modified the interface, they'd be much more useful. This is the beauty of open APIs; they allow for redesigning of apps without impacting the core data and services.
  • Sorry for the late reply, but I just saw your comment this evening. Good point re making a distinction between at-will apps vs. must-use apps. People may grumble about poor design in a must-use app, but they'd grumble more if they were unemployed. And when a purchaser (e.g. a government agency) has to choose between several must-use apps, UI design is not at the top of the purchaser's evaluation criteria.
  • If you limit UI design to visual elements, then yes, it's not a huge concern, but I consider usability part of UI design. So, good usability (i.e. as close to walk-up-and-use as possible) should be an evaluation criterion, since training costs are part of the purchase price.
blog comments powered by Disqus