Archive - Edition 3: Portals

back To Overview of Edition

Leading Article

What is a Portal?

What's in a Portal: MiniApps, Generic MiniApps

User-Centered Portal Design

Graphic Design and Branding

"Real" Portal Projects

 

Do Traditional Design Processes Apply to Portal Design?

By Günter Schmidt, emaro AG, Lecturer of Berufsakademie Karlsruhe – 05/21/2001

Disclaimer: Please note that this edition was written in 2001. Therefore, statements in the articles, particularly those regarding SAP's products, product strategy, branding strategy, and organizational structure, may no longer be valid.

Traditional design processes - for example, the design process as described in the papers found in the SAP Design Guild - focus on a certain product or the support of a certain task. Therefore, designs based on such processes support only small slices of a normal workday. Traditionally, you design a single application, such as a word processor, a bill presentment tool, or an information retrieval tool, but all these applications are only partial elements of a user's work. As the examples show, the information and the applications are separated from each other. Thus, if you start a certain application to get a task done you do not necessarily have all the information at your disposal that you need to decide on the issues addressed in the application. Instead, you are equipped with a whole bunch of applications and all kinds of information sources to tackle the task. Even worse, often the information and the applications act independently and "don't know of each other." For example, they cannot share data, do not have a common context, or cannot act on each other.

A portal (see the article Portals - The All-In-One Web Supersites: Features, Functions, Advantages, Definitions in this edition for a definition of portals) can add huge value for the user by offering one unified view on all the needed tools and work-related information sources. On the other hand, if you would offer a different portal for each task or information source, the user would not profit much from calling a portal. And in the end, this missing benefit will drive the user away from using it.

Thinking about people-centric portals and about the main benefits of a portal brings up the question, whether traditional design processes still work for portals. I don't have a clear answer for this question now, as all of us still lack experience with portal design. In this article, I present my own first experiences and the procedures we used in the portal design projects we recently conducted, spiced up with some useful hints. Hopefully, this will stimulate a follow-up discussion of this topic. Read also the articles on user-centered portal design and on portals in general in this edition of the SAP Design Guild for further points of view.

 

The User

The User is a Complete Being

For portal design you need to place the human being into the center of your efforts. And as I mentioned above, you need to consider the whole set of issues and tasks of a human being. Therefore, you need to regard people as who they are and what they do.

For the design process, this means that you never say "this is not part of our application." Everything the users have to do or access should be part of the portal.

Watch the User

With respect to the information needs, there is no difference to the traditional design process. The portal design will benefit from every information you gather about the prospective user or user group. Consequently, you still need to investigate, watch, listen, ask questions, and make sure that you understand the requirements and how the users rate and prioritize their own work. These data are the fundament on which a design should be based if you take the motto "people-centric" software seriously. In addition, these data may have an impact on more than just the piece of software you are to design. They may suggest a reorganization of the whole work process or processes. With respect to portal design, this aspect is even more important because portals attempt to be "the" electronic workspace for people and to support the whole set of tasks a user has to perform.

Site visit

Figure 1: A site visit means being there, where the actual work is done

 

How you Gather the Information: Personas, Affinity, Work Models

As mentioned above, the design will benefit from the information you collect. However, transforming the information contained in the interviews into nice-looking PowerPoint slides is done for nothing, since teams forget slides faster than you can create them. This is especially true, if the information is text-based only. So, we had to search for different ways of communicating our investigation results. Typically, we use the work models from Holtzblatt's Contextual Design method and the personas from Cooper's Goal Directed Design method in our work. These methods (a) lead to a deeper engagement of the team with the issues, and (b) make the information more concrete. This results in a common understanding and better mental availability of the issues.

Depending on how much time the project has available, we create all those models, if possible. Remember, the more information you have, the better will your design be.

In my opinion, the best combination of models for portal design is:

Given that you gathered all that information you will have the best foundation for designing often-used portals. As affinity models and personas may not be known to everyone, I give a short explanation of these methods below.

Affinity Models

Affinity diagram      Team working on an affinity diagram

Figure 2 and 3: Example of an affinity diagram (left); team working on an affinity diagram (right)

Affinity models or diagrams are a means to consolidate and structure the collected observations of site visits. These diagrams are wall papers composed of hierarchically organized affinity notes taken from the protocols of site visits as shown in Figure 2. They reveal - after a laborious restructuring process (see Figure 3) - in one place all the issues, worries and key elements of work practice relevant to the team's focus. In the end, a consolidated affinity diagram can be read like a "story".

Personas

Personas

Figure 4: Personas (from Cooper Design)

     

A persona is an archetypal user of a product, based on the design team's investigation work, such as site visits. The team creates a cast of personas for each project. Each persona gets a biography, job description, photograph, and, most important, a list of goals. These goals are what drives the persona to succeed; if the goals are not met, the persona will not be happy and may refuse to use the product. Each persona with unique needs is designated as a primary persona, and typically gets her own interface, which will be designed to meet her unique goals.

As mentioned above we found the combination of the persona and the affinity model to be the best combination which can be done very fast and still give you the most important information. Because of the nature of these models you can see the human being (persona) and all related issues, needed information, worries and hints (affinity).

 

Crazy Brainstorming or Vision

Depending on which design approach you look at, the next activity is named differently. The main idea of that step is to push innovative design ideas based on the collected data about your user and figure out, how those ideas could improve or support the user's activities.

In the first place we don't set any boundaries for the ideas to be able to push innovation. Often we try to stimulate ideas by using questions like: "What would it do if it would be human?" or "Pretend it's magic, what would it do?"

After this "Crazy" step we start to set the boundaries of technology and what we can implement. Usually we can use quite a few ideas from our Crazy ideas to improve the portal and bring added value to it.

Creating a vision

Figure 5: Creating a vision (click image for larger view)

     

Crazy Brainstorming, Vision

A vision is typically created after the site visit data have been consolidated. They mark the begin of the actual design phase and try to capture the redesigned work practice in a story of how customers will do their work in the new world we invent. A vision includes the system, its delivery, and support structures to make the new work practice successful. The team develops the details of the vision in storyboards, "freeze-frame" sketches capturing scenarios of how people will work with the new system.

 

Scenarios or Storyboards

Scenarios are useful design tools that describe typical, actual work situations. Scenarios consists of steps that can be written down as text statements or sketched as storyboard frames. A scenario determines the flow that you have to support. Later, if you can support additional slightly different scenarios, you can use it to check your design. In addition, scenarios can be utilized in user tests with paper prototypes, or the actual application or portal (the scenario can be used to derive specific tasks for the test persons).

We create those scenarios for our persona and use our vision as the basis for it. When we create the scenarios we often have to come back to our vision and improve or change it slightly (e.g. to make it technical feasible).

Interaction structure showing the connections between different MiniApps for a scenario

Figure 6: Interaction structure showing the connections between different MiniApps for a scenario (click image for larger view). This structure has been the basis for a paper prototype.

For the design of a portal you might want to use the scenarios slightly differently:

Determine the Triggers

Here the questions are "Where does the work (the scenario) start?", "How can we present/support the start in the portal? " First you have to figure out how you tell the user that he or she has to perform a certain task. Perhaps, there is a decision involved before you start a scenario. So, you need to make sure that you support the decision with the related information. Thus, only presenting the link to the start of a procedure won't help if the user doesn't know that he or she has to start it in the first place.

Determine the Depth of your Portal

In the case that you regard your portal as an improved launch pad only, you cover only the first two steps of a scenario, namely, (1) decide to do it, (2) start. But since you don't have any influence on what the procedures behind the start link do, you will find that the users don't really appreciate such an approach. They want more than just another launch pad.

The real value of a portal for a user is that you work in one place, and only if you have very specialized tasks you walk out of it. This implies that you have to offer most of your information, functions, applications, and services inside the portal. In this case you not only need to cover the first steps of the scenario - you have to support the whole scenario.

The best way to determine the depth of a portal would be to create a user environment design (UED), which explicates the structure, as you would do it for an application. Doing so, you get focus areas, which still belong to the portal, and other focus areas, which are obviously outside the portal.

Reality teaches us that there are often political reasons behind the decision how far the portal's responsibility goes. So, you have to make the best out of that decision.

In our example project, the Budget Manager Portal, we reviewed the various scenarios, and on the fly decided cooperatively, where a needed functionality or information should appear in the portal. You might say that we created a user environment design using a more informal approach. For details, see the article The Budget Manager Portal Revisited - Putting User-Centered Methods to Action in this edition. Here the user environment design was derived from the core process for the budget manager, namely the budgeting process.

 

Information and Application

To add value to a portal, you need to integrate information and applications. Depending on the users, the integration could go in two directions:

  1. Integrate functions into information
    Documents, articles, presentations, spreadsheets include certain functions and whole applications to support the information and make it easily possible to work and act on information.
    Example: In the portal's report for the manager she can see the information about the department's performance. Right beside the performance measures she has some functions or whole applications at her disposal to take actions and improve the situation.
  2. Integrate information into applications
    Well that's the obvious direction to bring more information into the applications. But as we all know this also has some potential of being too talkative - too much is annoying. So, you have to understand which information is needed and which is annoying.
    Example: In the calendar for your appointment next week the portal tells you that the PowerPoint slides have not yet been finished.

Both directions are used in the design of a portal. Some areas might be filled with more information and less functions, other areas will have more functions and less information. Still you have to make sure that the amount of each fits the users work.

 

Conclusion

Given the differences between traditional software products and a portal, you have to think carefully about the design process for portals. Here, you not only have to support a single task, but you need to offer an integrated view on everything the person needs for his or her work.

From my point of view, the tools we typically use during the analyze and design phases of the development process still provide valuable information for designers. In addition, these tools push the design into the right direction. In my opinion, the design tools are still applicable for portals, but their usage changes slightly towards a different focus. One could argue that the design process stays the same because in every design approach you are use the design tools according to the focus of the project. Thus, you might conclude that there is not a fundamental difference between the design process for traditional applications and for portals.

In the course of several projects we realized the great benefits that you can gain from combining different design approaches. Using the right mixture, you gain the advantages of each approach. Especially, the work models of Karen Holtzblatt & Hugh Beyer used in conjunction with the personas of Allan Cooper are an excellent combination: The work models provide detailed information about your target user group, and the personas fill the abstract models with life and make them more concrete.

 

References (SAP Design Guild)

Contextual Design at SAP, Karen Holtzblatt, President and Hugh R. Beyer, InContext Enterprises

Cooper Interaction Design Enjoys SAP By Steve Calde, Senior Designer and Alan Cooper, President, Cooper Interaction Design

Process papers in the Resources section of the SAP Design Guild:

See also the articles in this edition of the SAP Design Guild.

 

top top