This is part two of a case study taking high level business goals and using User Centered Design (UCD) processes to help define appropriate information requirements.

Here’s the case again:

User research at our client, an IT Solutions Consultancy, has identified a common business scenario, that of a consultant visiting an office in another city.  Most consultants do this infrequently, so we have been asked to add a micro-site to the corporate intranet to make sure they do it correctly and in compliance with corporate processes.

Our process is:

• identifying the user activities
• identifying what types of information might support those activities
• determining whether there are sources for that information
• packaging the information.

In part one of the case study, we modelled the user activity at a high level, and identified potential information resources.  This part goes into more detail, and significantly refines our original model.

Determining Sources for the Information
Unlike the first step, where we were just identifying the information components themselves, here we are putting each one under the spotlight, to see where we could get that information, and first thoughts about its usefulness and characteristics.   Our notes might look something like this:

External weather sites
There are plenty of sites; we could arbitrarily recommend one, but could assume the consultant has a favourite weather channel.

External events sites
There are plenty of sites, but they cater to different interests; it’s probably not a good idea to recommend one, but let the consultant do their own independent research.

Policies and procedures, recommended carriers, loyalty points
The corporate intranet has some web pages and a couple of PDF documents describing this; we can aggregate these in our micro-site.

Information about reservation process
The corporate intranet has some web pages describing this; we can aggregate these in our micro-site.

Tools to make the flight reservation
There is a link to the travel agent site; we can include this in our micro-site.

Tools to make the hotel reservation
This is also handled by the travel agent site; included in our micro-site.

Address, contacts, map
All office locations are listed on a single intranet page, with text for addresses and contact; perhaps it might be better to have each office on its own page, especially if there is more information we want to capture about each office.

For contacts, is there any value in making the contacts actionable, e.g. clicking to email them? This would have implications for content creation; the page author would have to know how to add an email link.

For contacts, would it be useful to help the consultant save contact information with an Add To Contacts function?  There might be Outlook and smartphone variants.  Also, the page author would have to know how to implement this functionality.

There are no maps; perhaps we could use the postal code to drive a Google map, or similar.  The developer wonders whether we could get our client to list its offices with Google Places or similar.

Process for getting access card
The process is that the receptionist fishes in her drawer for a card, and makes a note of it.  If we wanted to be explicit, we could say “Visitors should check with reception on arrival to receive an access card”.

WiFi connection
There is nothing on the intranet; the receptionist has a document in her drawer with the connection information.

Printer configuration
All printers are labelled with a network address and name; we don’t need to add anything to the micro-site.

How to use the meeting room Smart Board and projection system.
There is a Quick Reference guide next to the control panel.  This may be good enough.

Restaurants
There are plenty of external sites, but they cater to different tastes, and are often out of date as the turnover in downtown restaurants is extreme.  It’s probably not a good idea to recommend a site. One thought is to have staff at each location make a list of their own recommendations. We could categorize this as fast/slow, suitability for working lunch, suitable for business relaxation.

FAQ about expenses; How To Submit Expenses;
These currently exist on the intranet; and we can link to them.

Expense submission tool
Page on intranet; we can link to this.

Packaging The Information
The previous activity delved more deeply on information possibilities.  But do these really benefit the user, and would we include them in our micro-site?. We will use the technique of scenarios to do help evaluate this.  A scenario is a narrative describing how the user will meet a certain goal.

Scenario: Roger Books His Flight
Roger has been told he has a meeting in Portland next week.  He hasn’t travelled for the company before, but his manager told him to access the Business Travel page on the intranet.  At his desk, Roger searches for Business Travel, and the page comes up at the top of the search results.  He sees that it has a well organized set of annotated links to related information, in web pages and PDFs.  He learns that bookings are made through a corporate travel agent, contact information provided.  Roger wonders if  he can use his loyalty program, and finds in the FAQ that he can.  He is reminded to mention this to the booking agent, who sometimes forgets to ask.

Information Implications
We assume a Business Travel page with annotated links, one of which is FAQs, another being contact information for the corporate travel agent. We confirm that the current FAQ does contain information about loyalty programs.

To be honest, this hasn’t really added much to the discussion.  More positively, we say that the scenario perspective corroborates our thoughts about the information structure.  This is not always the case, as the remaining examples show.

Scenario: Roger Gets From The Airport By Taxi
In Portland, Roger pulls out a printout of the office location, hails a cab and tells the driver the address. He arrives at the office after an uneventful trip.

Information Implications
We need the address of the office on the page describing the office locations. We do not need the map.

Scenario: Roger Rents A Car
In Portland, Roger gets a shuttle to the car rental agency.  Back at the office, he had copied the office address on to his phone.  He looks on his phone for the address, and enters it into the in-vehicle GPS.  He follows the directions to the office, but drives past it three times looking for a suitable place to park.  After a bit of a hassle, he arrives at the office.

Information Implications
We need the address of the office on the page describing the office locations. We do not need the map.  We would like a smooth way of copying and pasting web content from a browser to a smart phone, and this may have web-dev implications on how we lay out address information in HTML.  It might be useful to provide parking information, or even the recommended method of transportation to get to the office from the airport.

This example is more interesting. Neither scenario requires a map, and we found some information we hadn’t considered before.  By the way, our developer was looking forward to playing with Google Places. We tell him that the map idea might be useful on the public facing site (** developer gets excited again **), but that is not in scope for our project (** developer gets deflated again **).

If we follow the scenario approach, and if we consider reusability of information, we might come up with some other observations in this case study:

• the receptionist has a photocopy of the wireless network configuration in her desk drawer; this is very ad-hoc and one more thing to train a replacement on; is there any value in creating a Receptionist micro site for things like this?
• the list of restaurants might be useful more generally, applying not just to visitors to the office but to any staff entertaining guests; we might not have a business justification for making a system to capture this but a list in a Word document might be helpful;  perhaps managing this could be part of the receptionist’s job, and the document be part of the Receptionist micro-site.

This case study has illustrated the power of  combining user modelling as well as information considerations, and changing our focus in a controlled fashion.  Different engagements will use different combinations of user centered design and information design, but will benefit from both perspectives.

The Information Artichoke Home Page   |  Modern IA Course Table of Contents