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

 

The Budget Manager Portal Revisited – Putting User-Centered Methods to Action

by Carsten Lessmann, Usability Engineering Center, SAP AG – 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.

"An article on the Budget Manager Portal – hasn't that already been presented in the previous edition of the SAP Design Guild?" you might ask. You are right, and we are happy that we have so attentive readers. However, the previous article presented a feasibility study from the Greenfield initiative – the portal was more a prototype than a real project. Now half a year has passed, and we are pleased to present an experience report from real practice – not just a fictitious or theoretical description. In this article, I show that user-centered methods are not as time-consuming as is often stated; they can easily be integrated into a normal SDLC (software development life-cycle) approach. Another important result from our work is that other groups' material in the portal world can be efficiently reused in one's own portal, thus creating synergy effects. The reused material can be role-specific content, such as the so-called "worksets" (see below for a definition). But it can also be more generic content, as is discussed in the article Generic Portal Pages – What Do Most Portals Need? in this edition.

Workset – Definition

A workset is a set of tasks that have to be performed by a person who occupies a specific role, for example, the budget manager role. A role typically has several worksets.

 

Lessons Learnt from the Greenfield I Budget Manager Project

Before I evaluate and discuss the ideas developed in the Greenfield I project, let me first recapitulate the role of the budget manager:

An evaluation of the Greenfield I project showed that the ideas developed in this projects – which were implemented in the Greenfield I portal prototype – headed into the right direction. However, customer feedback showed that there were still important components missing. The process employed by the project team had proven successful. Therefore, the team wanted to further pursue this approach, but now go into more detail.

 

Site Visits – How they Affected the Design of the Budget Manager Portal

One of the lessons learnt was that we still didn't have enough information about the budget managers role. Therefore, we prepared additional site visits in Germany and the US. Before we went to the customers, we conducted a site visit "crash course" for the team in order to set the focus for the site visits – without a focus you do not know, which aspects are relevant for the observations during the site visits. The focus was set on observing how budget managers actually work, what kind of electronic tools they need for optimal performance, and what kind of additional aids they need. Such aids are, for example, printed laws and regulations, guidelines created by the respective institution itself, and calculators providing a calculation protocol.

Site Visit Results

The site visits were performed by the members of the development group themselves. The results were discussed in a brainstorming session after all site visits had been conducted. We found that the central budget process consists of a five-step process:

  • Step 1: Central inquiry and investigation of necessary statistical and other related data to compile the so-called "Eckwertepapier" (paper with benchmark figures).
  • Step 2: The generation of the document itself based on the results of step 1; together with the preparation of the new document an old version has to be placed at disposal.
  • Step 3: Based on the centrally generated document involved, decentral departments have to start their own budget planning, the so-called bottom-up planning.
  • Step 4: The final planning version has to be closed with the so-called "Chefgespräche" (superior talks) to ascertain the deviations from last year's planning document. It is within the responsibility of the budget manager to provide all necessary documents and data for this duty.
  • Step 5: Finally, the corresponding public panels have to be agreed on the "Eckwertepapier", and the parliament has to pass the new budget as law.

    

A "scribbled version" of the five-step process

Figure 1: A "scribbled version" of the five-step process (click image for larger view)

 

Sketch of a budgeting process scenario

Figure 2: Sketch of a budgeting process scenario (click image for larger view)

Based on the central budget process we derived several scenarios the budget manager has to work on. Each step of the budget process itself stands for a scenario, that is, we derived scenarios called "step1", "step2" and so on.

Scenario "step1"

Let me shortly describe scenario "step1", that is, the first step in the budgeting process:

Based on the detailed steps to finish the preparation for the 'Eckwertepapier' (paper with benchmark figures), we generated the following overview of this scenario. It includes not only the budget planning preparation issues, but also the budget execution, communication and management aspects:

Overview of the steps for finishing the paper

Figure 3: Overview of the steps for finishing the preparation for the 'Eckwertepapier' (paper with benchmark figures) (click image for larger view)

From this overview, we worked out a more detailed workset for the budget preparation itself. It is still sketch-based and looks as follows:

Sketch of the workset for the budget preparation (paper prototype)

Figure 4: Sketch of the workset for the budget preparation (click image for larger view)

Vision

From this central budgeting process, we also generated a vision for the future, named "Verwaltung 2010" (administration 2010). It consisted of automated and semi-automated business processes, which integrated the communication flow for the preparation of decisions into a workflow process. However, this vision was discussed controversially within the team. So we performed a reality check and to find out, why this vision was problematic. On the one hand, we found that the vision was technically not feasible. We became also unsure about whether the processes described in the vision were really needed and wanted by the potential users. Many political and social aspects are involved in preparing a decision; these would be excluded by an automated process, which is not desirable.

 

Casting the Scenarios into a Design

Portal pages are primarily built from MiniApps. So, based on the scenarios described above we asked, which MiniApps were needed for the portal pages serving the budget manager in the respective scenarios.

We collected the MiniApps that we considered to be useful and combined them in coherent worksets. A workset is a set of tasks that have to be performed by a person who occupies a specific role – in our case, it was the budget manager role. A role typically has several worksets, and the budget manager is no exception to this rule. Because of this, we found a number of cross-reference relations between different worksets. This led to the idea of reusing worksets from other portals, here reusing the HR (human resources) and FIN (financial) parts from the generic Manager Portal also developed by SAP.

Prototypes: Focused Design for Scenario "step1" Based on a MiniApp

As a first step towards the actual page/portal design, we focused on two or three Mini-Apps and the connection to other MiniApps. For these prototypical designs we used simulations of the MiniApps (actually there were two versions, a full blown version and a cut down Excel approach). To complement the MiniApps we also integrated external news and information providers into the prototypical pages (these were customer requirements). For the budget consumption scenarios we made heavy use of state indicators: these were used as triggers for additional actions, such as the budget adjustment.

Based on the site visits conducted in Germany and the US, we worked out what kind of support the budget manager expects from a portal solution. We used these insights to provide real added-value with the solution and the corresponding MiniApps (now called iViews). The calculator MiniApp in the budget planning is a good example for this approach. During the Site Visits almost every user had a standard physical calculator on his desk to do some elementary calculations, e.g. for estimations and simulations. One obvious solution might be to integrate the normal Microsoft calculator (or a similar self-developed clone) into the portal (see Figure 5). But this would not provide optimal support for the budget manager because the calculation stripe is missing. This stripe is exactly what the users need to reproduce their work and what usually is missing in the standard calculator.

Therefore, we designed a sketch for an advanced calculator with the added feature of a calculation strip: Now budget managers can use this electronic calculator as a useful equivalent to their physical calculator (see Figure 6).

Microsoft calculator

Figure 5: Microsoft calculator

        Design sketch of a calculator for

Figure 6: Design sketch of a calculator for the budget manager

 

Small (emulated) PDA with a printing calculator application

Figure 7: This small (emulated) PDA has it already - a simulated printing calculator

Complete Paper Prototype

The next step was to build up a complete portal solution for budget manager. This was done using a paper prototype. We chose the paper prototype approach because it is well suited to iterative design: you can easily change a paper prototype, whereas it is much harder to change already implemented applications. Moreover, the users can even codesign pages after a user test.

Second Round of Site Visits

The paper prototype played an essential role in the next round of getting user feedback. We conducted additional site visits in Germany and the US and found – much to our surprise – that several elements we missing. We had simply overlooked them in the first round of our site visits, such as inquiries "Daily business for Budget Manager."

The results from the second round of site visits led to the refinement of the existing worksets and to the addition of the "inquiries" workset:

The inquiry process is used to answer request either from internal panels, such as other departments, or from external parties, such as traditional citizens. This process had to be integrated into the existing workset portfolio.

For simplicity, we decided to add a new workset because of the independence from the budget process itself. We refined the complete Portal solution for the budget manager by applying a kind of iterative design because we just repeated the steps for inquiry issues as we did for the whole budget process.

         

Workset for the inquiry process

Figure 8: Workset for the inquiry process

 

Time Estimates for the User-Centered Approach

One of the recurring arguments against taking a user-centered approach is that it takes too much time. To our opinion, this is not necessarily true if the process is well planned and conducted. As an example, we needed only one week for analyzing the results of our first round of site visits. It took us just one (!!) day to create the first aversion of the paper prototype – think how long it would have taken to create an HTML prototype or even a running application (and how long to modify these). We needed additional two weeks for refining the prototype and another week for synchronizing the design with other worksets of the Manager Portal.

Timeline

 

Conclusions

Contrary to the widespread opinion that user-centered design takes too much time and cannot be carried out under tight time constraints, we found that it can be done if the project is conducted properly – not to speak of all the benefits for the users that result from such an approach. As our second round of site visits showed, important factors are easily overlooked. Only a close contact with the prospective users can avoid the otherwise resulting design flaws.

 

top top