Pre-conference Workshop: PORTAL PLANNING: DESIGNING & IMPLEMENTING

Speakers:
Peter Jones, Managing Principal, Redesign Research
Nick Kizirnis, Intranet Manager, Lexis Nexis

Monday, November 14, 2005

Key resources:
- Building Intranet Portals: A Report from the Trenches (2002-2005) by Goodwin & Nielsen of the Nielsen Norman Group (NNG)
- Jakob Nielsen’s Alertbox from http://www.useit.com/ – weekly/monthly email newsletter
- Nielsen Norman Group is the largest consultancy group in this area; good to learn from
- Information Architecture: Blueprints for the Web by Christina Wodtke [thanks to Steve Matthews for the corrected info! - Nov. 16/05]

- Jesse James Garrett- speaking at the conference

Do legacy applications predetermine your portal? E.g. Microsoft, Hummingbird

“Doing search well can take forever; can be a whole career’s worth of work.”

Lessons from Nielsen:
- people issues are the biggest cost in portal implementation
- governance issues can make or break the process
- focus on the decision-making process more than the application itself
- involving users from an early stage eases acceptance problems
- set up cross-function steering group to communicate back to the portal management team
o Customer Advisory Group (CAB) – high level
o User Council
o Have 2 – 3 feedback groups, not just at the executive level

Content planning

What is the content?
Subjects
Structure e.g. keywords, metadata
Who owns the content?
Establish accountability
Where is the content?
Locations
Centralize or de-centralize
Tell us all about the content
Content inventory/audit – Jeff Veen from Adaptive Path http://www.adaptivepath.com/ has good information on conducting a content audit
How much ROT do you have – Redundant, Out-dated, Trivial content
Identify the content and get rid of the ROT – this is a big, ugly process that takes time
Make sure your content is good

Technical Planning
- be partners with IT, not adversaries
o working together provides checks and balances if everyone is “in the know”
- if you are in IT, read the manual
- “it’s slow”
o systems testing is very important
o it can be very difficult to determine the issues that are causing the system to be slow.

Lesson from Nielsen
- portals do not solve intranet usability issues. They can, however, create them. i.e. do not switch to a portal to improve usability
- may need to make a trade-off between speed and flexibility
o determine your priorities
- talk to user base as to how the information can be used once the portal is in place – they may find new uses
- need central guidelines to ensure content is usable
o Rules can make lives easier
o Get commitments from internal content providers – consider service-level agreements (but these are difficult to get signed)

Requirements

- a dynamic, continuous process

Where you discover them:
- Organizational – overall business and organization needs
- Teams – you need tools, content and resources for specific product teams and working groups – need to find those teams and determine how to help them
- look at enterprise portal stakeholders
o management departments
o groups within the departments
o users

Portal often initially structured like you organization structure; they do not recommend the portal be structured this way.

See handout chart “Portal Decision Framework”

Gather requirements:

Practices – to think like a customer, or learn from the customer – try one for each customer:

- Customer round tables – used more in customer-user research perspective; looking at end-user when something has implemented esp. within a specific organization
- Focus groups – go out into the field; keep short; based on focused series of questions; defined group of participants
- User surveys - Gives usable data, findings to use as leverage for proactive responses
- Personas & task scenerios - representations and profiles of key users; different employees and their roles
- Contextual interviews / observations – e.g. have user group work with paper prototype, move it around (flexible); have stakeholders and designers observe – used a “wish list” the people previously set, had them sort cards created from the wish list according to priority (took about an hour)
- Usability testing – test current requirements and helps identify new testing

“Agile process” – they advocate quick and easy methods e.g. sampling from small groups, gathering user requirements and user testing. (Highsmith, Cockburn)

Task & Content Requirements
- create a strong model simplifying core tasks of what users do; best to have 5 – 7 requirements (human memory limit) “a strong task model”
- streamline it in the requirements phase, and then build it out
- need prototyping phases and usability evaluation
- structure content by function not department
- what are the tasks all employees want to accomplish?
- Review with stakeholders
- Function model is persistent – even if there are internal reorganizations/ new assignment of responsibilities, don’t need to change around the organization


Agile process

- see esp. Agile Manifest http://www.agilemanifesto.com/

Analyzing requirements?
- you will not have a lot of time to analyze results
- instead, creative decision-making
- setting priorities within & among customers, features, user task
- act more as a partner when you work through this process rather than just pumping out results

Rapid, Adaptive Development
- agile process (Highsmith, Cockburn)
- requirements largely speculative
- use prototypes, collaborative design
- rapid revision, quick feedback tests

Minimize organizational friction; build projects in such a way that time is limited (a “time box”) and drives change – used extensively at LexisNexis now – a lot of info in Nick Kizirnis’ book

Timeboxing
- establish delivery cycles and timeboxes in each
- deliver once a month
- Developers meet once a day face to face
- Customers once a week face to face

Requirements change
- Since users/clients/stakeholders will change their minds anyway, welcome change – tell them they can change their minds during the process
- If you are collaborating, no real surprises should occur
- Leverage your priorities to manage scope
- Continuous development – portal is a lower risk environment


User Experience and Information Architecture

Information Architecture methods

- when people are putting together requirements, wish list, have them put labels on things. Helps to group data together quickly; could be an early basis for a taxonomy

See also: Information Architecture Institute – may have Jeff Vean’s spreadsheet

Site Design Lessons from Nielsen

Taxonomies can be difficult for end users, and can be counterproductive. Keep the top level of a taxonomy 12 to 20 items. Any more than 3 levels of depth, people may get lost. People who don’t know the domain/subject area will want to search. After the search, use the taxonomy to categorize the results; i.e. better to use the taxonomy behind the scenes. Relevancy ranking by search tools out of the box is very poor. Creating good relevancy ranking is a lot of work. Content creators are not good at tagging data.

Not all portals have a single home page – unified by common navigation, not home page – good approach for integrating divergent content

Good portal design is efficient, not fancy – busy users prefer to get their jobs done quickly; keep it minimal but develop a strong internal brand

Portal design reflects corporate culture

Thomas Vanderwaal – coined phrase “folksonomy” – users create their own tagging from bottom up; however, speakers recommend some overall general tagging to give it some structure

Don’t force portal IA to reflect departmental structures; however, how to determine functions?

Internationalization must work globally, not just locally – a major challenge and time consuming

Information standards are more challenging than design and layout standards – because portals templates set your designs in stone; but content fluctuates wildly

Process: have a specialist editor in each content area submit information to the portal
Enterprise search – metadata pulled from the content from all the applications – takes at least a full-time editor to manage it. A lot of work.

Summary from the group exercise:

- a lot of clients don’t know what they want – a big challenge
- what customers say they want are the features e.g. single sign-on, searching,