 |
|
 |
|
Telling Your Story - How to Develop Engaging Corporate Presentations, Product Demonstrations and Support Tools
By Joy Busse, CEO & President - Busse Design USA
December 2002
Hold on to your hats -- the world is changing in front of our eyes -- again. Applications online, or better known as Application Service Providers (ASPs), are the hottest products to be featured on the Web today. No more solutions in a box, no more outdated software, no more install, upgrade or version hassles-now you simply rent the application online and the provider takes care of the rest. It's like renting a house versus owning one-all the headaches of ownership and maintenance go away. Because there is no software to own, there is a significant reduction in software management costs and responsibilities on the user's side. The numbers are astounding. The Gartner Group projects the category to be almost $23 billion by 2003.
I recently participated in a usability expert chapter meeting in which an online product design agency presented the "extraordinary" process they used to develop a perfectly usable product for their clients. The only problem: was, the "developed" pages and documents which the client received at the end of the UI development phase, didn't really present the entire product. Further, it did not consider the many functionality challenges and potential usability problems of the actual product. The design agency delivered-- proudly-- a couple of HTML templates and a document or a few flow charts describing in hand-written format how some specific parts of the product had to work in order to be functionally viable. When we asked the presenter why the agency did not create fully functional, HTML prototypes of the application for their clients, we were told that they are the experts and that the "prototypes" they drew on the whiteboard showcased "perfectly" what the product is meant to do for everybody involved in a given project.
So, after an eight- to- ten- week development effort and $250,000 less of their venture money, the client was sent away to figure out the rest by themselves. The client's engineering team was handed a few "designed" screens and encouraged to build out the application with "some input" from their marketing team.
Unfortunately, creating a well designed and usable product depends on more than just the opinion of one or even a few experts., And while speedy development (UI development should not exceed eight to ten weeks) and heuristic evaluation is certainly something I personally advocate, it is important to look at every workflow and feature aspect to ensure optimal functionality.
Understanding who those users are and what they need to accomplish should be the first step during every development effort. Of course, I am not talking about how old they are and whether or not they live in Florida or Ohio. Instead, I am concerned with how many different types of users will be using the application, as well as what functionality and features the development team should consider to ensure the users needs are met.
In my experience, there will be a minimum of two or three different user types for each online application. These types can be subdivided into at least another two user types. Take, for instance, a procurement application for the hospitality industry.
When creating an online product like this, one must look at user types such as the "top- level" user, who might be the head of purchasing for a hotel, several "mid- level" users such as the head of housekeeping, and the "low- level" user such as a house-keeper. While these terms reflect their influence level in the hotel and within the application, they also can reflect the level of expertise regarding computers, the Internet, and workflow processes at large, depending on the type of application. For a systems management interface, it might be the exact opposite.
Once the development team understands what the different user types are, they can create "User Task Analyses" during which assumptions and scenarios about why, when and how those users will interact with the product are created. Then work-flow scenarios can be established that might initially be reflected in flowcharts or "whiteboard" sketches. However, these workflow scenarios need to be proven accurate by placing them into the actual work environment - the Web page.
This is where the rapid HTML prototyping process comes occurs. By quickly creating simple HTML pages that resemble the final product in module placement, content, and functionality with no "visual" design (colors, graphics, fontsfetc), the development team can recreate the real-life scenarios from the flowcharts and modify page content, functionality and possibly structure, according to who will be using the product.
The end result is a prototype that leaves no one guessing about what happens to the user when they click here or there. Surprisingly enough, creating HTML workflow prototypes does not have to increase the UI development time. The process can happen concurrently with the visual design exploration and HTML template build-out phases.
The advantages to developing a product by including rapid HTML prototypes are many:
- Developers can find and correct potential usability downfalls before the product ever meets the customer.
- The entire product development team (engineering, design, marketing) can see and understand the impact of different features and know exactly what the end result will or must be.
- The prototypes can include the long- term product goals while allowing everybody to understand the impact of individual features on the overall functionality.
- Prototypes can function as a very accurate and detailed PRD allowing engineering to give a more accurate estimate on back-end development time.
- The designed interface can be easily applied to the raw HTML prototypes to present the product features and functionalities to investors, board members, or users.
- Informal as well as formal usability tests can be held before the product ever gets built.
- Overall development cost and build-out time are reduced.
Creating rapid HTML prototypes for an application is not rocket science. Any so-called "usability experts" who tell you that they don't need prototypes because they know best, need to realize that rapid HTML prototyping will help clarify usability strong points for the entire development team.
With only the "expert" opinion, chances are, even though one expert might know much about how certain aspect of the application are supposed to work, there might be some "minor" things that he or she neglects to communicate to the rest of the team. This phenomenon can create the opportunity for usability problems in the product that somehow always magically turn out to be the components that have the biggest negative impact on ROI.
Take it from the usability expert. Even though your expert might have all the answers, it is important that everyone else involved have them as well. As a team, using the simplest tools the Web has given us, we can create online products better, faster and cheaper.
|
|
|
|
|
