Posts filed under 'Blog'
As the name implies, User Centered Design (UCD) is an approach to software design that focuses on the needs of the end user. A user profile is developed that describes the target audience for the application. Next, typical usage scenarios are identified that represent the kinds of tasks users will perform. Design begins with low-fidelity mockups and storyboards, and progresses to interactive prototypes. User feedback is gathered at every stage of the process, and the design is iterated on until it meets the requirements of the end user.
User feedback is gathered via design walkthroughs, customer visits, and usability testing. Because design changes are applied to a prototype, iteration occurs very rapidly. The result is a prototype that serves as a interactive specification for the product.
User Centered Design enables the translation of market requirements into a tangible representation of the user interface early in the development process, before coding of the product begins. This website contains many examples of the application of UCD.
The Design Process
User Interface Design is a process of discovery. Not all ideas pan out. Sometimes a direction will appear promising early on, only to fall apart later when other factors are introduced. This is why it is best to start with “low-fidelity” tools such as site maps, flow diagrams and wireframes. Because low-fidelity designs are quick and inexpensive to generate, there is not a huge investment in them. It is easy to explore different ideas and iterate on them until you feel confident moving to the next level.
Our first example below shows an early attempt to map the organization of the user interface for a web authoring tool. Product Management had created a 150-page requirements document that included the features they felt would be necessary for the product to be successful.
It is not easy to digest a 150-page requirements document. In fact, the document was written by multiple people and contained numerous duplicate and sometimes contradictory requirements. The diagram below shows the distillation of the requirements into a high-level visualization of the organization of the user interface. It was iterated on many times and became a catalyst for clarifying product requirements, as well as the high-level user interface design.
Many questions can be answered using low-fidelity designs like this. For example; What features of the product need to be available in the primary workspace? How many different views are needed? What information should go into property sheets, wizards, palettes, etc?
Low-fidelity designs enable end-user feedback even at this early stage. Most software applications are targeted at tasks that users already perform by other means. For example, a new web-based application might be designed to replace a process that is currently being done using Telephone, Fax, or EDI. In such a case, there is already a process end users are accustomed to. To be successful, the new solution must work better than the existing process. Using domain-expert interviews, and diagrams like this, the existing process can be understood and documented. This information is fed into the design process. The high-level design for the new application can be shown to the same domain experts, and feedback gathered.
Next is an example from a different project that shows one of the alternatives considered for the basic organization and end-user flow of the product. Because the essence of the design was summarized on one page, it was very easy to understand and compare the alternatives.
Next, is an example of a flowchart that mapped out the detailed workflow for a web-based transaction application. This design was iterated on several times before all the major paths in the workflow were captured. Having the end-user workflow visible like this was a tremendous help getting everyone on the team focused. It helped to solidify requirements for, not only the user interface, but also the underlying data model.
November 2nd, 2006
From 2000-2004, I worked at Ariba Corp – one of the early pioneers of B2B software. I worked on a variety of projects, but for most of the time there I was lead designer of Ariba Enterprise Sourcing (Versions 3, 4, and 5) – A product for conducting Sourcing Events (e.g. RFIs, RFQs, Negotiations, etc.) over the Internet.
Below is a screen capture from the prototype for Ariba Enterprise Sourcing. It shows the dashboard for an online Request For Quote (RFQ). An RFQ is essentially a reverse auction where the buyer tries to get the best price and terms from potential suppliers.
From the dashboard, the initiator of the auction can monitor the event, and see the progression of savings over time. All major areas of the product were prototyped. JavaScript was used to simulate the interactive behavior of the product. The prototype was iterated on many times before arriving at a final design. Once the design was agreed on, the prototype code was used as a base for implementation of the real product.
The prototype for Ariba Sourcing served many purposes. It was used in early customer walkthroughs, and in usability testing. Development used it as a specification for the user interface. Quality Engineering used it to understand the correct behavior of the product and to create test cases. The prototype was used to create marketing material and was shown in sales engagements. It was also used by Publications, Training, and Customer Support to create support material for the product.
The next example shows the supplier user interface. This is where suppliers answer questions and “bid” the price they will charge for the goods or services asked for in the RFQ. An RFQ may be very short or very long (dozens of questions and perhaps hundreds of line items). The user interface had to accommodate both extremes and everything in between. The supplier also had to be able to monitor the progress of the auction and revise their bid when necessary.
The next example from Ariba Sourcing is a cost model. Here the buyer can compare different alternatives and determine which one is he most advantageous.
Every medium has its own strengths and weaknesses. An artist working in oils can do things that one sketching in pencil cannot, and visa versa. If an artist tried to use pencil-sketching techniques while working in oil, chances are the results wouldn’t turn out very well. Just like an artist, the designer must understand the medium – i.e. the client technology that will be used in the product. The capabilities of Visual Basic are very different from those of HTML, which, in turn, are very different than those of Flash. When a designer understands the client technology, they can exploit it. This is why it is important that prototypes be constructed using the same client technology as the product.
Below is a simple example of using recent advancements in web technology to simplify the user experience. There are times during a sourcing event when the supplier needs to send a message to the buyer. In a traditional Web 1.0 product the user would click “Msg Buyer” and be taken to a different page where they would compose the message. Here a DHTML window is opened that overlays the window, making the whole experience much less disruptive to the user.
Ariba Enterprise Sourcing 3.0 is what is popularly referred to as a Web 2.0 product. The user selects actions using DHTML popup menus. New information is presented by dynamically updating regions of the page whenever possible (as opposed to navigating the user to a new page). Information presented in tables is dynamically loaded as the user scrolls using AJAX techniques (there is no pagination).
February 15th, 2004
In 1996 Jim Clark of Netscape fame founded Healtheon. Healtheon’s purpose was to bring the internet to healthcare and is so doing make it more efficient and useful. I joined Healtheon in 1997. After working on several products I became lead designer of Healtheon Practice, Healtheon’s new web portal for physicians. Before we began design on Healtheon Practice, we did numerous doctor office site visits. One of the key things we learned was the that most physician practices have an office manager who manages the business side of the practice – leaving the medical end to the physician. Physician practices are like small businesses where the physician is the owner. For things such as Refererrals, Authorizations, Claims and Lab Reports, the office manager was much more knowledgeable than the physician. We also did numerous site visits to insurance claims processing centers and laboratories.
Below is a screen capture of the prototype for Healtheon Practice 1.0. Healtheon Practice provide physicians with news amd reference information as well as the most common physician practice transactions – elibibility, referrals, claims and clinical reports. Notice the tabbed navigation bar on the left. This provided convenient organization and access to all of the services offered in the portal. All major functions were simulated in a prototype. The prototype was iterated on many times before arriving at a final design.
User Interface Integration Guide
It quickly became obvious that new services would continually be added to Healtheon Practice. Some of these would be developed internally; others would be partnered. A User Interface Integration Guide was created that provided information on how to develop a service that would be consistent with Healtheon Practice. The guide and the prototype worked together. The guide described integration – the prototype showed examples of integration, and provided a platform for designing new services. The Integration Guide was distributed widely – both within the company and to partners.
Healtheon Practice 1.0 was very successful. In the months following its release, Healtheon embarked on a series of mergers and acquisitions that dramatically increased the richness of the information and services that could be offered to physicians. Also during this period the decision was made to change the brand of the physician portal – from Healtheon Practice to WebMD Practice. These factors necessitated a redesign of the portal. A new version of the UI prototype was created that reflected the new look and new branding. The previously existing services were updated and an intensive effort was launched to design and prototype the new services that would be added. Because the core of the prototype already existed, this was accomplished very quickly.
Below is a screen capture of WebMD Practice (version 2.0 of the physician portal).
The tabbed navigation bar from version 1.0 was replaced with a new design that featured expandable categories. Each category was a header (Today’s Medical News, CME, Medical Community, etc.). When the user clicked on a category it expanded, displaying the services underneath. When the user clicked on a new category it expanded, and the previous category collapsed.
Expand/collapse was implemented using JavaScript and document writes (i.e. the code was all on the client). Because expand/collapse did not require a page reload (and thus a round trip to the server) it was virtually instantaneous, even on a machine with a slow modem connection. This was crucial, because it enabled and encouraged users to explore the portal. New users could click through all of the categories, and quickly see all of the available services. Nothing was hidden or buried; everything was always quickly accessible using the Navigation Bar.
Branding
WebMD Practice was architected so that it could be easily rebranded. This allowed WebMD to offer different products built on the same platform. It also allowed partnerss to rebrand the portal with their logos and their colors. By modifying a stylesheet and a finite set of 8 images, a completely different look could be given to the portal. The set of customizable assets was documented and made available to customers and partners who wished to give the platform a different visual look.
Below is a screen capture of WebRN, WebMD’s portal for Nurses. Both WebMD Practice and WebRN used the same platform and the same set of common services.
WebMD Practice 2.0 provided a wide range of services, including: Medical News, Continuing Medical Education, Secure (encrypted) email, Eligibility, Referrals, and Claims. One popular feature allowed physicians to create a web site for their practice. A wizard was used to prompt the user for information to be contained in the site. This included an optional feature that allowed patients to schedule appointments over the internet.
The screen below shows an example of a physician page generated by the wizard.
Users were able to choose from a set of 9 visual styles for their website, and they could preview how their site would look. Styles were switched simply by swapping in a different stylesheet and a different set of image assets. The HTML was exactly the same regardless of style.
Below are some additional examples from WebMD Practice. The first is an example of a Referral. This screen would be used by a physician’s front office staff to refer a patient to another physician (usually a specialist).
The prototype demonstrated the dynamic behavior of the user interface. For example, it included a service for checking patient insurance eligibility. The prototype did not actually check patient eligibility of course. Rather, when the user of the prototype entered search criteria and clicked “Search for Patient”, the prototype simulated searching a database. A “Search In Progress” message was displayed using JavaScript timer events. After a realistic period of time had elapsed (simulating the time it would take to search a real database), an example search results screen was displayed.
The ultimate testament to the success of the prototype was that it and the product were virtually indistinguishable. Even after the real product was available, the prototype was often used for demonstrations. Below is a final example which shows a message being read in Secure Mail.
September 14th, 2002
Next Posts
