|Usability for component-based portals|
Usability is key when building a portal, because all of the components have to work together. And the key to good usability for component-based portals is a solid methodology grounded by the proper tools. This article covers methodology, the different aspects of a portal, tools, and a case study.
It seems that every other day another company is offering software to help build a portal, integrate a portal with back-end databases, link a portal to back-office supply chain infrastructure, and so on. They're known as enterprise portals, knowledge portals, and sometimes just plain portals.
What is a portal? What makes them so important? And what can usability professionals do to keep them from being a nightmare for users?
What is a portal, anyway?
Portals are typically made up of components, each of which is highly specialized. One component may list latest breaking news; another one might be a search widget; still another component may list data from a partner's database. In many cases, these components fit into a unified visual design and interaction flow, making the user experience seamless.
When they're done right, a portal can act as a front door to an organization and all it has to offer. Users can access all kinds of information, interact in community areas, and accomplish tasks using custom applications. When information and services change, all users get access to the latest and greatest material-which simplifies content management and application deployment. The common user interface, when implemented correctly, provides consistency.
The My Yahoo page, shown below, is a leading consumer portal. Yahoo allows users to customize layout and appearance (including background color, link colors, and more) as well as the kind of news and applications modules present on the page. News sources include local news, specialized information (such as fitness features), and national news (such as the New York Times). Applications range from weather forecasts to lottery results and access to e-mail. The news and applications modules, plus the wide array of personalization options, are a perfect match for the needs and requirements of the consumer audience.
There's practically no better way to offer so much value in so small a space. All the work put in to designing and building the portal pays off handsomely when new content or applications are rolled out to users, which can sometimes be as easy as dropping new templates or back-end logic onto the server.
Done wrong, a portal can be nothing more than a hodge-podge of little boxes with data and links in them. Each screen could have different interaction models. Each interaction could have different outcomes in different contexts. And the entire thing could be a nightmare to navigate. Search functionality, critical when a portal's information architecture is impenetrable, may not provide visibility into all information and services represented.
In other words, a portal, if done wrong, could be more trouble than it's worth, and certainly a waste of time and money to build.
That's why usability is key when building a portal, because all of the components have to work together. And the key to good usability for component-based portals is a solid methodology grounded by the proper tools.
Methodology is the basis for action
Step 1: Discovery
Understanding your audience is always a critical step in any communication effort. Who makes up your audience, and what kinds of tasks are they involved in? The answers to these two questions form the backbone of your understanding of the audience.
Finding out who makes up your audience can be straightforward or not, depending on how much due diligence the organization that's launching the portal has done. The organization's marketing and sales groups should understand both the demographics and psychographics of the audience.
You can use demographics, psychographics, focus groups, surveys, and other methods to figure out who your audience is and what information they want. The goal is to understand your audience such that you can reduce them to actors in user scenarios. It's O.K. if you have more than one or even dozens of user scenarios involving different segments of your audience. Ostensibly, each of the different users you identify will have different information needs and have different tasks to complete on your portal.
Next, try to figure out the goal of the portal. All portals have an overarching goal, which is to offer centralized access to widespread information sources and services. However, all portals also have unique goals. For example, a corporation may want to cut the cost of managing HR information in half. Putting all HR information in one centralized area and allowing employees to manage their own 401(k) programs via the intranet would certainly help to achieve this goal.
As with audience analysis, the goal is to create a list of specific, measurable goals for the portal. The more specific and measurable, the easier it is to test for usability.
Next, try to understand the breadth of the portal. How many databases and information sources are going to be represented on the portal? How many departments and/or companies will be involved in creating, editing, filtering, publishing, and managing this information? Who has final say-so over various elements like design, editorial content, and access to data? Obviously, these questions run the gamut of technical and organizational issues, but they all impact usability at some point.
For example, if the content featured in critical components doesn't match the needs of the audience, then understanding how that content is created will help when the time comes to give the creators of the content feedback.
Step 2: Analysis and artifact creation
The goal of this step is to create certain artifacts that can be reviewed and approved. For example:
The artifacts are the only tangible evidence of usability work, so make them clean, crisp, and professional.
Step 3: Assist the developers
This doesn't give anyone license to be an annoyance -- remember, most developers haven't been trained in usability techniques. They know how to build software, and this usually means building it efficiently but not necessarily with the end user's needs in mind. The role of the usability expert is to offer guidance, provide pointers, and refer them back to the artifacts that pinpoint users, their needs, and the services offered by the portal.
In many cases, developers will need clarification of what they've read in the artifacts. Developers always appreciate others who communicate with them on their level (that is, in precise language free of ambiguity), and this is a good chance to advance the user's cause while being a true asset to the development team.
Step 4: Testing
Usability testing can imply a lot of things, but for the purposes of this article, precise methods don't matter. What does matter is what you test: specifically, that your users can access needed information and perform necessary tasks on the portal.
The results of testing and recommendations stemming from the testing should be rolled into the portal and make it better.
Step 5: Deployment and further measurement
Working with the different parts of the puzzle
However, regardless of a portal's size and complexity, each consists of the following layers:
Each of these layers has its own set of problems from a usability standpoint.
Issues of importance for the GUI framework are:
In other words, the GUI must support everyone's goals -- the users' as well as the portal's owners.
Business logic lies at the heart of interaction, and if interaction is faulty, then the user experience will likewise be faulty.
Issues of importance for business logic are:
A good design for backend systems takes care of the most pressing usability issue (namely, delivery speed) but there are other issues, too, involving:
Linkage between data can mean the difference between a usable and unusable site. For example, each content item may be linked to a category hierarchy. When a user reads an article about how to create a search engine in Java, the article might be categorized under Programming Languages>Java and Widgets>Search Engines in the hierarchy. The portal's business logic may list other articles in the Java and Search Engine categories to allow the user to read similar articles.
Another issue at hand is the types of data being stored in a database. Most databases handle ASCII data (including HTML documents) with great ease, but other types of data become problematic. For example, XML documents, although stored in ASCII format, will need to be processed by the business logic for display in a Web browser. And although databases can store and retrieve video and audio files, it may be best to only store a pointer to these resources --again, for speed.
Metadata, by and large, is what makes or breaks any effort at publishing huge amounts of disparate content on a portal. For example, if a database contains tables that store articles and white papers, then effective metadata would include author name, author e-mail, and keywords. Each of these metadata can then be accessed by business logic that could, for example, display all articles by a certain author or that contain certain keywords.
Tools for the job
From a usability standpoint, there are two major user groups that are uncovered in discovery:
Obviously, these are fairly broad strokes, and a more thorough assessment would drill down into specific cases for each grouping, such as:
Of course, all needs should be prioritized on a list, and some may not make the first cut of the release, but at least they've been recorded and considered.
The company's goal for the portal is to foster an open environment for sharing information -- to grow the economy for their products and services. They don't just want a place to pump information out to people, they want a space in which all constituents can interact.
The breadth of the portal is small at first, bringing in data sources from only three departments (all internal to the company). Because each user will have to log in to the portal, the company plans to make this a personalized portal, where users can mix and match the components that are important to them.
The first step is to put all of this together, and to create artifacts that record discovery and analysis outcomes. Each user gets his or her own user scenario, complete with tasks and demographic/psychographic information. How the site flows, how the components interact, what they look like, should all be recorded in a site map or blueprint. Even if this document has already been created by another group, make sure to procure it and include it with the other artifacts.
After development begins, the different components will start materializing. So, too, will the backend systems and business logic that ties everything together. At some point, the portal will enter QA, and that's a good opportunity to perform some usability testing.
Find users (or suitable user proxies) to test whether the portal serves the needs of the different user groups. Can the partner get access to pre-release information on products? Can the rural customer easily figure out which solar panel to buy?
Is the GUI easy to use, or does it confuse users? Are the components built such that they mesh with each other, or does each stick out like a sore thumb? Does the business logic operate in ways that support tasks? Does the search functionality work across all data, or does it stick to predetermined silos of data?
The answers to these (and other) questions determine the usability, and ultimately, the success of XYZ Corporation's portal.