I like designing web sites, because they’re more visible and by that standard, more glamorous. However, I like designing business process applications better, because applications are more function focused. The success of an application is dependent on how well I’ve thought out the workflow and functionality. It is not clouded by marketing.

Here’s a road map on how to design strategically for a business process application:

1. Design strategically for maximum productivity. When you’re designing a web site, you want to maximize clicks and time spent on a page. When you’re designing a business process app, you want the user to complete each task as quickly as possible. The less time spent on a task, the higher the productivity.
2. Prioritize features for roles by frequency of use.
3. Design for maximum scalability and flexibility as businesses can shift direction to respond to market conditions.
4. Differentiate between usability problems and workflow problems. Sometimes what is perceived as a usability issue is really a company’s production and/or red tape problem.
5. Identify and provide solutions for current online and offline workarounds.
6. Don’t just document and design for the current workflow. Look for ways to streamline the company’s current online and offline workflows.
7. Identify other systems (i.e. ERPs or legacy systems) that your application will have to hook into.
8. Flowchart primary and exception use cases to catch functionality loopholes.
9. Templatize functionality/behaviors as much as possible to optimize learnability, user adoption, and minimize development time.
10. Gather users’ input often throughout the process by conducting quick-and-dirty prototyping.
11. Work closely with the training department to address usability and user adoption issues. When a company has been using a legacy system a long time, it is a cultural shift to move to a new system.

What I want to know is why after all this time, corporate training have not caught up with the rest of the world. When it comes to training, companies are still following the same model since 100 B.C. (Before Computer). So I’m exaggerating, but companies are still spending a ton of money on printing manuals, still conducting face-to-face training, and their web based training still remembles the CBTs of yester-years when the pixel is as big as your thumb.

By the time the training collaterals are updated, they’re already obsolete, since the software has undergone yet another upgrade. The problem is further aggravated as companies expand abroad and workflows are altered. We’ve always known that a company’s intellectual property is a moving target. It’s never finite. This problem has always been there ever since 100 B.C. However, it has just become more apparent and less managable as the world becomes smaller; and dialog, now a tangible source of knowledge.

Corporate training could learn a thing or two by just looking at wikihow, howstuffworks, ehow, and viddler. This model would allow companies to have a knowledge bank that is always current, sharable, editable, and transparent. I mean the comment feature on video streams from Viddler is just so perfect for training, it’s screaming to be ripped off.

Seems like a no brainer, right?

But I’ve encountered this same problem over and over again everytime I work for a large company with a proprietary software and a complex workflow. I just hope corporate training will catch up to Web 2.0 by the time we’re at Web 3.0.

Once upon a time, I worked for an internet postage company. Seems like ions ago, but it’s core product was a Windows application that allowed the user to print postage (think of it, the equivalent of actual money!) from your computer. Due to the USPS’ requirements, the security for the client was off the charts — even higher than 128-bit encryption.

We actually tried to do the impossible, which was print from a web-based client, and we got it to work. It’s wasn’t production level code, but with a few tweeks here or there, we could have hit that mark. There was no indication if we were going to be allowed to release that client, but the usability wasn’t too bad, especially for skunkworks project.

Soon after that experiment, the company purchased another company that developed a shipping client for shipping centers. It was pretty advanced for it’s time: it did all the AJAX stuff beform Jesse James Garrett got rich off of coining the term AJAX. Other than a few glitches, it seemed to work pretty well.

Except it didn’t.

When you visited the clients that used the application, they hated it, and here’s why:

• It was slow
• Performed poorly over DSL
• Was a bloated mess and a fragile application.
• The web client worked only on Internet Explorer 5.0, and as soon as 5.5 was installed, the application broke.

So what are the lessons? I always thought the internet postage client should have been a web application, and conversely the shipping application should have been native to Windows, because almost every one of these locations had a Windows system. As much as I keep repeating that the web is a fad, I think it depends on the following on what you select to be the platform to develop on:

Who’s the audience?

The needs of a bunch of workers telemarketing day in and day out are much different than a sales guy that’s going to make 10 sales calls a day. The telemarketers are going to want hot keys, they definitely don’t want to use a mouse, the latency means less phone calls, which means less money in their pocket. That’s usability that costs the company in revenue, so they’re going to want a rich or native application. The sales guy making those 10 calls doesn’t mind taking a minute or two longer to futz over a dial up connection or a slow DSL connection, so a web application is just fine. It’s the difference between a casual vs. an expert user.

What’s their platform?

Take a good look at the audience’s technology before you select the platform. Is the audience has a bunch of different platforms and technologies they are working with, that’s an easy answer — go with a web application. If they are on fast connections, look at Flash. If they are on a single platform (Windows, for instance), a native application isn’t a bad idea.

How fast is their connection?

Native applications, once installed, don’t have to be downloaded again. Rich media applications have to be downloaded through a web browser, usually in one chunk. Web applications have latency depending on the connection. Which would you rather be using while working in Alaska, depending on how much data you have to push around?

How often does this need to be updated?

There are advantages, of course, to a web-based application, because you don’t have to worry about backwards compatibility, a code base that’s branched all to hell, and 18 different flavors of windows. If you are going to update the application every day, a native or even a rich media application might not be the way to go. However, if there are long cycles between updates, and there’s a way to push the updates cleanly, then a native application is okay.

All of the above should be considered even before selecting a development platform, because each affects usuability. It’s about the appropriate technology for the appropriate audience, something developers forget.

I’ve been trying to install Yahoo! Music Unlimited on a friend’s computer for quite a while now, and finally, we just gave up. We found out that Yahoo! was discontinuing service soon to Canadians (the friend is Canadian), and figured it was time to move to Rhapsody, even though Rhapsody’s a few more dollars more. The point is, it was a rather frustrating experience, and part of the reason why Yahoo! is doing poorly — most of their services are rather frustrating.

There are no screen shots because I couldn’t install the software. Additionaly, there was no clear indication that the service was going to be discontinued for her.

Here’s what I would have done to make the service easier:

Tested the software on many platforms with many states of other application installs. One of the mistakes that many Windows developers make is they never test if for a typical install — which is when users install tons of applications, many of them of suspect quality, before installing your application. The developers always insist on a clean install of Windows, and how many of us have a clean install?

Put a “download software here” link somewhere on the site. If you go to Yahoo Music Unlimited now, there’s no explanation of what software you need to make it work — they just have a bunch of links to try this software now, which is entertaining, because they are about to kill the offering completely. The answer is that you have to download the Yahoo Music Jukebox, which I assume is a fine piece of software, except…

If the software doesn’t install, there should be an easy way to contact customer support for help. There was no install log, no click here if the software isn’t installing. Finding any answers at all on the Yahoo! website is a frustrating experience, and it took me upwards of two days to figure out that I should be contacting customer support. Additionally, there are seemingly three or four separate customer support contact screens, further confusing the issue.

Browser experiences are hard enough, but especially with applications, usability of said application is very important, especially when it’s an install of a paid service. Open source or shareware software, I could see less support — however, this is Yahoo, and the assumption is they are making some money off of this.

How to be A Good Product Manager (which is a phenomenal blog, by the way, and wish I had written most of the content) has this excellent post about requirements, and it applies requirements gathering. One of the traps that we fall into as consultants is that with certain clients, we go into the mode of just gathering requirements and not advising what the requirements should be (read: let’s design the Pontiac Aztec, quite possibly the ugliest car on the road).

Just gathering requirements is a bad idea. Advising on requirements is a better idea, because that’s how you add value.

Sure it’s like herding cats, but the reason many consultants are valuable is there’s some wonderful insight that they may have, however small it may seem, that adds phenominal value for the client. That’s why they are paying consultants what they do.

How so? We start the conversation about what the direction should be, even if it’s the wrong direction at the start. One of the essential points that the article makes is that in many cases, the customer has no idea what they want (a car), and what they may get may be anything from a Hummer or a Prius.

Our job is to ask questions that will lead to developing a better product, and not necessarily questions that lead to what we think the product should be. Many scenarios, it’s impossible to satisfy all parties, because they may ask for a car that is great for the environment (the Prius) and can run over people (the Hummer), because the requirements are conflicting. Our job is to find the best solution, not the solution that meets the needs of everyone.

Or what do they say — trying to make everyone happy will make no one happy?

I don’t like very many usability or software blogs (mainly because most of the writers aren’t, and when they do explain things, it never seems to be in English), but I really like Joel on Software. He breaks software development and usability issues into nice, easy tidbits anyone can understand.

Many of the topics he covers I have no real interest in (SQL Server Mirroring? What the hell?), but the topics he does cover, like how improving software doesn’t mean a complete rewrite of such software, and usability for developers that don’t really care, are well written, thought out, and easy to read.

Some other software gurus (hey Dave Winer, you listening?) should take notice.