SAP DESIGN GUILD

The Web Master Portal – Roles and Scenarios

By Sylvia Lehnen, Sylvia Barnard, Michael Hatscher, SAP AG – May 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.

This article lets you take part in the very first steps of a user-centered design process for a portal – the design considerations that went into the forthcoming Web Master Portal. The roles and scenarios presented here are the result of site visits carried out in the USA and Germany.

We first provide an overview of the roles we found to be relevant in the portal area. Then we describe the Web Master role, the focus of our work, in detail. To fill this role with life, we include a persona description. We then complement the role description with the descriptions of high-level scenarios, which capture the main tasks of a Web Master. The results presented here are the starting point for the concrete design of the Web Master Portal.

 

Roll-in of User Data

Of course, you can design a piece of software according to what you think users would like to do, who you consider your software's users will be, and what you take for their usual tasks and workflows. Yet – as intent SAP Design Guild readers will know – this is not the approach of choice. Too much would be left to assumptions and speculation. Therefore, we conducted site visits to gather information on real target users, their objectives, and their work environments. Sylvia Lehnen, Sylvia Friedrich, Kathleen McSweeney and others visited people in the Web Master field at companies like Adobe, Heatcraft, and MLP in the US and Germany. What they brought back in were interview transcripts; these were used as the starting point for first identifying roles, then building personas, and subsequently constructing scenarios. Finally, the interface design will be done according to the scenarios. In the following chapter we'd like to introduce the user roles we have identified.

 

Overview of Portal Roles

A portal can be used by a variety of people for very different reasons: people may use a portal as their electronic workplace, people may provide content for a portal, and finally there are people who manage and administer a portal. We identified the following user roles for a portal:

Portal users	All portal users can do certain things, such as viewing general portal content, contributing general content, searching, and working in teams. In addition to the generic capabilities and content available to all users, users can view and contribute content according to their role.
Professional content providers	Although every user is a potential content provider, professional content providers need both more freedom and more functionality than is typically provided by predefined forms. In addition, the workflow associated with their documents is typically more complex.
Portal professionals	The following three roles primarily involved in defining and designing, creating, and maintaining the portal.
Content Manager	The "Content Manager" role is responsible for defining an overall knowledge management corporate strategy, including the portal strategy. The decisions made at this level are generally implemented by and maintained by the "Web Master" and the "Portal Administrator" - see below.
Web Master	Implements the content decisions and maintains the content; also creates the forms and templates.
Portal Administrator	Implements the technology and infrastructure decisions on a user access and technical level.

In the following, we focus on the Web Master role, which is the role the Web Master Portal is explicitly designed for. However, keep in mind that there is considerable overlap between the Web Master and Portal Administrator roles: many web masters handle some administration tasks as well.

 

The Web Master Role

Now let's take a closer look at the Web Master role. The primary job of this role is to implement those corporate content decisions that include the company's web and/or portal content. The term "Web Master" is a commonly used title for those responsible for the actual building of external Websites and Intranets. Once these have been built and tested, this person makes sure content remains current and accessible, refines structure and content as necessary, and evaluates both direct user feedback and the information from usage statistics to make sure the portal meets the needs of various groups.

Example: At one customer's site, a survey of customers showed that 80% of the site visitors wanted to download the latest software release. However, this page was one of the least attractive pages, it was on the third level, and it was confusing to use.

In most organizations, each area would probably have its own Web Master who would need to cooperate closely with Web Masters of other areas and with the Content Manager defining the content's structure.

Sidestep: The Portal Administrator Role

The people who fill the Portal Administrator role are responsible for setting up the technical and administrative portal infrastructure. Unlike the Web Master role, this role is not focused on content, but rather on the underlying settings that determine security and user access, network configuration, and so on. This role is also responsible for tracking, reporting on usage statistics, and troubleshooting and fixing problems related to servers, networks, or user security issues.

Relation between Web Master and Portal Administrator Role

To a large extent, the people in the "Web Master" and "Portal Administrator" roles have a different background, expertise, and focus. However, there are areas of shared interest. For example, both roles are interested in user traffic statistics: the Web Master because he may need additional resources for a particularly popular area, the Portal Administrator because he needs another server to increase performance.

 

Functionality

Now let's define the required functionality needed by a Web Master. The functionality listed below reflects what customers in site visits and domain interviews considered desirable, not what is currently available or even planned. In some cases, third-party applications could deliver this functionality. Note also that all the people interviewed thought in terms of a site-page paradigm, both in terms of planning, building, and maintaining a portal. Keeping this in mind, we can easily enhance ease of learning and thus usability: the more we can design our functionality to work within this familiar mental model, the more users will see it as easy to use.

Overall tasks of the Web Master:

• Create portal structure, fill with content, create navigation
• Maintain portal content timeliness and accuracy
• Troubleshoot portal content
• Evaluate and refine portal content

To give you an example, we'll provide the information we found for the first task, "Create Portal Content and Navigation." The other tasks' descriptions are equally detailed (but we'll spare you those).

Create Portal Content and Navigation

Create site structure	Create content structures based on corporate decisions (made by the Content Manager). Most likely, the Web Master will work with the functional expert of an area to put together the structure and iViews for a particular role. Ideal functionality would be to create the structure visually, with drag-and-drop Navigation relationships are automatically established. If the hierarchy is changed, any links are automatically adjusted (see NetObjects Fusion, Adobe Golive and other demos). Customers want flexibility in defining the layout and navigation structures rather than being presented a rigid layout.
Import content	Set up the classification functionality to automatically import content into the appropriate areas. Set up the workflow functionality to automatically post forms-based content into defined structures. Manually import graphics, text, or multimedia elements into page areas or predefined iViews. Automatically import content elements based on predefined taxonomies. Access to a graphics search engine for finding visual content. Question: is the display of content only possible through iViews, or does the possibility for "normal" page layout exist?
Incorporate iViews	Choose and incorporate iViews from a catalog; arrange on page. The ability to size iViews by grabbing corner and dragging would be ideal.
Add rating mechanism	Add rating mechanism to documents.
Create forms	Create the templates that will be made available to different roles to provide content. Should have ability to add graphics elements. Define where in the structure the document is published.
Create workflow	Ability to attach workflow to forms, such as: the people who need to work with or approve the document.
Create feedback	Design feedback form. Work with classification mechanism to send feedback to the appropriate people.
Implement drag/relate	Set up the drag-and-relate internal and external relationships defined in corporate strategy.
Preview site	Ability to preview content and test all links before going live: staging area/server.
Publish site	Mechanism to go live. For some types of content, site submission to search engines. Ability to periodically check ranking in search engine(s).
Archive content	Ability to archive the Website's content.

 

The Web Master Persona

Personas are an important element in the Cooper design methodology. You could say if a role is an archetype derived from what's typical of people doing a certain job, the persona is a concrete manifestation of a role. Design should be lead by the considerations of how to satisfy this persona (i.e. how to provide a solution that will be useful for all the people that can be covered by the archetype). Others (e.g. Karen Holtzblatt) have adopted this approach because a persona is a very useful means of communication, within the development team itself, as well as between the team and customers or prospective users. Therefore, we designed a persona from our role description – Andrew, a 28 year-old guy driving a 20-year-old VW Beetle. As you will see below, personas fill (the rather abstract) roles with life and provide a very realistic touch. Note also that a persona description not only includes the role description, which typically comprises the persona's tasks, but also the persona's needs and goals. These may be very different from the requirements dictated by the pure job fulfillment (which could be found in the job description). Also each persona has a "background story" which transforms it - nearly - into a real person with hobbies, attitudes, and a history.

After having finished his studies of Architecture, Andrew found a job at a big firm producing software for computer supported learning, doing the telephone hotline, dealing with customer's requests and complaints. This way he got a deep insight in what the customers and their employees demanded of the products, and he gained some understanding of what makes a good product and a useful documentation. Nevertheless, he actually wanted to do something more challenging.

At university, he had gathered some Internet-related knowledge when doing a small project: he had documented some results of a study on a Website, training himself HTML, a bit of Java, and doing graphics. Although he's not a computer guy, he had found himself very interested in this new area. Most of all he liked how easily he could create a great-looking Website by just applying some of his artistic talents.

One day he overheard his boss and the chief of marketing discussing the firm's Website strategy. They were both unsatisfied with the workflow for changes on the portal; information sharing was cumbersome and having an external provider applying the changes proved rather cost-intensive. Despite himself, Andrew spoke up and told them about his knowledge of Web technologies. They agreed upon his doing some minor changes for a start, to see if everything went smooth, and within no time they found themselves being very satisfied. That's how Andrew got his new job - and he's done the firm's Website for ten months now.

Andrew's Role

Andrew

• Is responsible for all issues dealing with the design, layout, production, and the maintenance of the firm's portal
• Is responsible for all the changes that have to be made on the site
• Has come to be some kind of gatekeeper, taking a look at all content intended for appearing on the Website, sometimes redoing minor things
• Has placed a link on the Website asking for comments: he gets all kinds of customer questions about technical stuff, most related to the Website. What he can't answer himself, he forwards to the in-house IT service staff
• Includes polls or conducts surveys, trying to make the portal more attractive: he wants to invite people to return to the Website quite often
• Does usage tracking
• Develops a document access ranking
• · Is the one in charge of web related security measures; he has to apply for certificates for SSL and enable them on the web server for the company's web shop
• Does the uploading of newly created content
• Tests the pages for errors (such as broken links or orthographic mistakes)
• Checks the pages in different browsers (Netscape, Internet Explorer, Opera…) and on different platforms (Windows, Mac OS, Linux)
• Does the link management
• Builds forms and templates according to the Content Manager's decisions for content provided by the employees

Info Needs

• Info sharing with the Content Manager and the Portal Administrator
• Technical information, such as authorization data for uploading content, records of broken links or errors reported to him
• Info on changes that have to be done on the portal
• Content from others – such as graphics artists –, be it internal or external providers, must reach him
• Latest news about cool technical developments, always looking for possibilities to improve the existing portal
• There are some manuals and books placed conveniently on his desk as well as a number of links to often visited tech Websites in his browser

Goals

Andrew

• Would like to be a really cool Website guru
• Wants the portal to be great, well-liked, delivering valuable content to its visitors
• Doesn't want to spend too much time on it and would like not to always have to just do the changes on the Website: he needs to have some spare time for his music and his Beetle
• Dreams of having some more time to try some new technologies that maybe can be used on the portal later
• Doesn't like to be blocked by maintenance and support needs, having to test the new pages a lot after changing and uploading them. Thus Andrew's goal is to provide a usable Website that doesn't lead to many technical customer questions and complaints

 

Scenarios

Now we describe the scenarios for the Web Master role. The scenarios capture the main tasks a Web Master has to perform in his daily work. Note that the following scenarios are high-level scenarios and don't go into the details of "how" to do something. However, when we had specific interface suggestions from customers, we've included them.

Overview of Scenarios

We identified the following scenarios for the Web master role:

• Create structure from scratch
• Convert existing intranet
• Set up classification mechanism and retrieval interface
• Create forms and workflow
• Assure content quality
• Evaluate site usage

To give you an understanding of what the scenario approach means (and not to bore you), we'll just provide the first scenario, "Create Structure from Scratch".

Scenario: Create Structure from Scratch

If a portal is created new, the content structure has to be created from scratch. This may involve a lot of work but has the advantage that the newly built structure can be adapted optimally to the content to be included and the users' needs. Here is a list of activities involved in creating a new portal:

• Create info pages and links between info pages
• Create IViews
• Enable access to reports
• Create transactions
• Establish drag-and-relate relationships
• Preview and test the portal

Creating the scenarios is an important step, but we're not finished yet...

 

Moving On...

We let you take part in the very first steps in a user-centered design process for a portal. The roles and scenarios presented here are the result of site visits carried out in the US and Germany.

The next steps will be to create paper prototypes of portal pages and the portal as a whole and then to validate them with users utilizing the scenarios described above. Depending on the test results, further user data roll-in and design validation may be required. Notwithstanding, all these feedback loops involve users, either as input source during site visits, or as "check mechanism" during test of the prototype or the real product, the Web Master Portal.

 

Conclusions

The Web master is a very specific portal user and you may wonder, whether such a portal is really needed. We can firmly conclude from our site visits that such a portal is asked for. And we also collected valuable data for establishing the role, a persona, and scenarios that allow for design decisions backed up by reality and not by pure guessing.

 

top