I worked for an organization that runs //entirely// by committee, if you can believe it.  Committees had sub-committees and sub-committees had work groups.  Agendas and minutes were the output of their meetings and represented the work of governance.  The ability to retrieve them, as well as generate and distribute news of them, made this document-sharing environment important to this esteemed and productive company. 

I was asked by the product manager to deconstruct the existing intranet application, recommend a rework of the "flow" and submit proposal for next steps.  Within 2 weeks, management committees approved our recommendation for a full contextual design project.

Starting out, I took apart the site (conceptually), labeled all the functionality and organized how it /actually/ flowed as compared to how its training materials imply.  Called a Reverse UED, this "problem-exposing" methodology showed what evolved from a programmer's exponential bits of code.  My advice to the product manager was in two phases.  I described what redistribution of functionality would accomodate the core task scenarios.  She realized that it would become a different app entirely, and elected to take the second advice: be clear on how the users would /need this app to work/ and design from there. 

Rachelle Hoffman (Product Manager), Liz Daube (Creative Designer) and I (Interaction Designer) took the product from a vision of "meetings-and-minutes" mgmt (image 1) to become an app of "people - places - agendas - drafts - attendance - minutes - drafts - schedules" designed from how the worker bees actually would want to use it (image 2).

image 1

image 2

The Contextual Design process consists of data collection, contextual analysis and design.  We analyzed the taskflow quickly because we recognized all the functionality.  We moved through the mountain" (linked to image on Contextual Design page) - bypassing the peak of visioning - by defining the functionality that we would tie together in prototyped interfaces.   We observed 6 kinds of users doing some tasks toward the goal of sharing drafts, posting approved versions, alerting others for both artifacts of each meeting -- attended by specific people, who have different roles and rights to view, edit and approve within the application on the intranet.  The images below show the stages in which we defined functional clusters and prototyped the interfaces.

In 3 months, we'd gone from realizing that the functionality was broken to having a full mock-up of all the pages.  Liz - the creative designer - polished the final prototyped pages in Photoshop.  Management thought it was elegant and complete.  

Unfortunately, the committees couldn't decide whether to start production on the new app, so they're still patching the old one.  We're ready when they are.

Alison Andrews |  alison@functionlust.com