Identifying the User Benefit

[ LiB ]  

Identifying the User Benefit

Your application must justify itself by providing a specific benefit. This is often called the value proposition that is, exactly what value it proposes to provide. It's fine to make a Macromedia Flash movie that "looks cool"it just wouldn't be an "application." Justifying an app using the return on investment (ROI) approach is often easiest , but not all viable applications have a direct or measurable economic value. For example, some of the best email applications are free. Anyway, all this talk about value does tend to overlook what should be your primary focus: the user benefit.

Identifying what the user who experiences your application will gain is really key. Naturally, although you still need to justify your investment in building an application, if you forget to start with the user, your application will surely suffer. This section considers some of the ways to evaluate your application idea while keeping focused on the user.


An easy way to formalize how your application will benefit the user is just to list the objectives you intend to solve. Here are just a few ideas of worthy objectives:

  • The app will give users a faster way to select a restaurant for dinner.

  • The app will enable our salespeople to create a customized catalog for their customers instead of making one catalog for everyone.

  • The app will sell used furniture to the highest bidder in a realistic and engaging auction atmosphere that becomes more popular than our brickand-mortar auctions.

Naturally, when you get to the nitty-gritty specifications of your application, you must include more detail. These are more general.

An interesting way to phrase these objectives is in such a way that they answer a follow-up question: compared to what? That is, "A quicker way to select a restaurant...compared to what? Quicker than picking via the Yellow Pages? The web? Faster than playing rock-scissor-paper? The first objective could be expanded to "a more efficient way to select a restaurant than reading menus posted on their front windows ." This example also changes the meaning of the objective. As you put your objectives to the test, you'll find that you not only clarify them, but also change them sometimes, too.

In the case of objectives, you don't want ambiguous goals or empty promises. For example, this objective is too vague: My app will make it fun to go to the dentist. It doesn't say how . Here's one that exhibits a classic fallacy called a bogus claim : My app will help travelers identify the best restaurant in town. First, there's no way to measure what's "best," and, second, it's vague. Although these bad examples are fun to consider, just remember to avoid tricks and fallacies. By following the advice in this section, you can eliminate uncertainty and phrase objectives in such a way that they help you consider alternatives to your app (discussed later in this section).

Measuring Success

The more time you spend identifying objectives, the more time you will save when it comes to deciding how to measure success. After all, you measure success by seeing how close you got to your objectives. If your objective is to reduce printing costs, for example, you measure success by taking the difference between the original costs and post-application costs. Usually it isn't quite as easy as "take original costs minus new costs," so that's why you clarify.

Even though you won't actually measure success until after you deliver, it's important to have a plan in place before you start. For one thing, it serves as a guide as you build. You can periodically return to what you consider a success and see whether you think you're going in the right direction. It's not as though you can plan a project and then just do ityou'll need to make adjustments as you go (at least that's my experience). A set of objectives and measuring tools serve as a compass keeping you pointed in the right direction. Having said this, you don't want to blindly follow your objectives despite information revealed as you're building. However, you can get pretty bogged down by trying to solve every problem you encounter. Even if such problems are worthy of resolution, sometimes it's best to put them aside. During a tight production, for instance, it may make perfect sense to say, "We're not going to address that issue. Although it might be nice, it's not a stated goal for our app." This isn't a cop-out; instead, it is a realistic way to ensure projects get finished.

Another reason you need a plan in effect before you start is that you want a baseline measurement to which you can compare. If you're trying to see costs go down, you had better have a record of the current costs. You might say "no duh"but remember this point if you need to convince others that it's important to identify your plan ahead of time.

Success doesn't have to be totally monetary . For example, a goal might be to reduce calls to your company's support staff. You could measure success by counting calls or even timing the duration of each call. Here I'm just trying to give you ideas on ways to measure success. The thing is, it really just depends on your application. And, ultimately, there are some things you just can't measure, such as how "good" you application is. If your goal is to make a better user experience, it can be difficult to measure (but just as important as anything). Keeping a practical eye on measuring success, however, is always a good idea.

Considering Alternatives

As great as your idea may be, alternatives always exist. Alternatives include competitive applications, variations of the solution you have in mind, and even nothing. (I love the "status quo" alternative because I'm already done!) Seriously, you want to make sure your solution offers something the alternatives don't. Notice I didn't say "you want your app to be the best alternative." Although being the best is nice, there's also a place for the fastest , the cheapest, or even the most popular. You just want to make sure your app has a marked benefit in some area.

A good place to start considering alternatives is to look at the status quo. No doubt your user is already doing something related to what your app will do. I think it's quite likely your solution will be different. Keep in mind that even if you know your app will be better, users will have to switch from whatever they're doing. Often applications are intended to be used on a regular basis. It becomes doubly hard to get potential users to switch from whatever they're doing because they have to invest some learning. Also, you might be asking them to change a routine, and habits are hard to break. By the way, don't think your app is immune from this requirement if "the boss" is just going to order employees to use the new app. That really isn't enough if you want it to be successfulthey have to want to use it.

It sounds bad, but you can often draw people to your app by identifying something they dislike in the existing solution. This is not unlike how negative campaigning works (for better or worse ) in politics. Here it's not so personal when you say "don't you hate the way you have to do all this stuff in the existing app?" They say necessity is the mother of invention; well, so is dissatisfaction.

Some applications have more than just the status quo to worry about. Public applications have to compete on the open market. In fact, this is the main reason why custom applications are easier to justify. If you have visions of becoming rich delivering the next killer app, you must carefully consider the alternatives. Keep in mind, however, that you can succeed in many different ways, including popularity or availability. The history of technology is littered with countless "better" ideas that failed because of poor distribution. I'm not suggesting that your app can be lacking in a major way if you just compensate by being popular. More to the point: Your app can succeed for a variety of reasons. It's best to identify what makes yours different from the competition.

Considering we're talking about rich Internet applications (RIAs), you can best discover your competitors on the web. Without this sounding too much like a pep talk, I do want to encourage you to still consider your project even if you find something that appears to offer the same thing your app does. If I didn't follow that advice when writing this book, for example, I would have stopped long ago when I heard of others on the same topic. The thing is, I don't necessarily think that this book is better than any of the competition. I do know it's different, however, because it offers my perspective. In the case of your app, study the competition. Don't fool yourself into thinking that anything they do, you can do better. But clearly identify what makes your app different. If you really do find a duplicate to your idea, then, yes, move on to something else (or even consider teaming up with them). Luckily, we're not yet at the stage where software is a commoditythere's plenty of room for everyone's personal variations.

Finally, one advantage we have when comparing to alternatives is that most existing applications don't use Flash. That makes our apps easy to differentiate. However, it also brings out the question as to whether there are more appropriate alternative technologies. (This chapter covers other available tools and technologies, in case you think Flash may not be the best solution for your application.) Also, most likely, your competition isn't Flash. Not that you can't find poorly implemented Flash examples, but there are even more using standard technologies ( mainly HTML). Hopefully, your app will offer more than just a spiced-up version of something else. That said, the following section covers how to rationalize the spice you do decide to add.

Rationalizing "Rich Media"

Within the term rich Internet applications , rich refers to rich media such as graphics, sounds, animation, and video. The cost of such media runs deep. Although intuitively this means RIAs take longer to download, you can actually make the opposite argument. A well-built Flash interface can both cover up such downloads (making them unnoticeable) and reduce refreshes (and download less media than a conventional application that keeps reloading content into the browserfor example, when updating the price of a product you're configuring). Although such arguments are indeed valid, there does come a point where rich media does mean longer downloads (and higher costs from your Internet service provider host).

If the question were only a matter of file size, this discussion could just move on to how to compress and stream media. In fact, other costs apply. For one, the production cost for rich media is almost always greater than traditional alternatives. Actually, because there's not really an "alternative" to video, the alternative costs nothing. In any event, illustrations, graphics, photographs, video, audiothey all cost money to produce. And if you're thinking of using clip art, just remember there's not only a cost of licensing the material, but you have to search for the appropriate clip. (Of course, you might find a free clip, but it might not perfectly match your message or it might look clich when people recognize an overused image.) I don't mean to sound like Scrooge, however; I do recognize the value of rich media. Make sure your cost analysis includes both the price and the value. Luckily the most valuable asset in most RIAs is datapresumably data you either own or intend to offer in a new or unique form.

Finally, the last cost I want to mention is how the app affects the user experience. For example, does the world really need a text editor that makes a different sound effect for every key press? Gratuitous special effects can be cute the first time, but they become really tiresome over time. For every video, sound, and even every pixel in the interface, you really ought to ask whether it's really necessary and whether it adds or distracts from your message. I'm not joking about every pixel. The information design guru Edward Tufte developed the term chart junk to refer to superfluous graphics added to graphs. This term is even more appropriate for computer screens because screens have so little room for data. (For example, a 1024x768 screen has less resolution than a wallet- sized photo.) The point is, because we live in a finite world, justify every item you add to it.

I wish I had more specific rules for you to follow when you identify the user benefit. Just keep in mind that it's good to question the validity of every item in your appperhaps more so during the initial stages because you have more opportunity to fix it. It's not like you're being cheap. If it helps, think of yourself as an advocate for the user.

[ LiB ]  

Macromedia Flash MX 2004 for Rich Internet Applications
Macromedia Flash MX 2004 for Rich Internet Applications
ISBN: 0735713669
EAN: 2147483647
Year: 2002
Pages: 120 © 2008-2017.
If you may any questions please contact us: