Using Persona Advocates to develop user-centric intranets and portals

Howard McQueen  howard@mcq.com
McQueen Consulting

Revised Oct 29, 2008 | Version 1.5                                        PDF Version - 160K

Introduction
Intranets and portals are all—or mostly—about serving and enabling users.  What information do they need and what tasks must they accomplish? How will they look for information?  How does it need to be organized and presented for them to understand and use it?  Do users have expertise in different subject areas or varying levels of technical vocabularies?  Do they need instant information gratification or will they patiently research
until they explore all possibilities?  Do users know what information they are seeking or do they
need to be able to browse for something that will catch their eyes and provide the “Aha!” experiences. 
Grasping complex information needs and uses can indeed be daunting.  One powerful design tool,
personas, can help make sense of these needs and provide a framework for building Intranets that
will satisfy a variety of needs.  Effectively developed and used, personas enable Intranet teams 
to hone in on user needs and build interfaces and user experiences that end-user audiences can and will use. 

What is the Return on Investment (ROI) for focusing on the user / user experience?
The methodology we outline below has helped us achieve success in creating portal-oriented personas and portal pilots that deliver results within acceptable schedule and resource constraints. This methodology embeds business owners/users in the process of iteratively defining and shaping their intranet or portal, before formal software development begins.  Portal initiatives are complex and expensive and by default, excessively focused on technology.  By enabling a corresponding focus on end-users, user-driven information architecture, user interaction design and business owner governance, portal initiatives address and mitigate risk and need not suffer from historically extremely high failure rates.

About Personas
Personas are widely recognized as a way of developing highly user-centered Intranets. Persona development is an early activity within a larger user-centered design (UCD) program that focuses on collecting and analyzing qualitative and quantitative user research and evidence (analysis of usage, review of user search terms, user site feedback, analysis of end-user surveys, testimonials, user workflow and user feedback) to design, validate and refine solutions.

There are a number of defining characteristics [1] of personas:

  • Personas are hypothetical archetypes, or "stand-ins" for actual users that drive the decision making for interface design and functionality.
  • Personas are not real people, but they represent real people throughout the design and refinement processes.
  • Personas are not "made up"; they are ideally discovered as a by-product of the investigative process.
  • Although personas are imaginary, they are defined with rigor and precision. They unite teams around one shared vision of whom to design for and what they want.
  • Names, personal details, attitudes, behaviors and workspace stresses are developed for personas to make them more realistic.
  • Personas are defined by their goals (when visiting the intranet or portal).
  • Interfaces are built to satisfy personas' information needs and goal-seeking and task-completion behaviors.

[1] Source: Alan Cooper, The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity, Indianapolis: Sams, 1999, pp. 123-24. (Wording condensed and modified.)

Persona development can be an enjoyable and rewarding group process that focuses and prioritizes audience segments.  A longer-term benefit is that personas feed into the iterative usability testing and user feedback that will be carried out throughout the development and progressive enhancement of the information solution.

Developing Intranet personas

McQueen Consulting

One of the benefits of working in the intranet development arena is that the process of creating personas can engage stakeholders, create goodwill, and develop buy-in.  During an intranet or portal development initiative, the employees participating in the process will expect a significant improvement in the usability of the Intranet, and managing often competing expectations can be difficult.  It is important to recognize that persona development is an on-going process and that it is often better to rapidly construct and market a few initial personas than spend months laboring over an initial set.

The first step in developing personas is to select a group of 12-20 staff (the organization that  piloted this workshop had 10,000 employees/contractors).  I've used this process with as few as 5 participants in small organizations (<100 employees)).  You want participants who have a real feel for the information needs of their colleagues and peers.  Candidates to invite include a variety of internal customer-touch personnel, i.e. research librarians, training staff, corporate communications, as well as staff performing the core business functions of the organization. They should be invited to attend a facilitated three-hour persona development workshop (see the example agenda below) that builds out 3-5 core persona sketches. 

Three-hour stakeholder persona workshop agenda

0 -10 Welcome (sponsor) and participant introductions
10 - 20 Initial group work on their perception of the intranet/portal
20 - 35 What are personas? Examples and benefits (facilitator)
35 - 50 Individuals create their own top five persona (facilitated exercise)
50 - 70 Group session to prioritize persona into 3-5 core audiences (facilitated)
70 - 85 Break
85 - 105 Group session to create 3-5 persona sketches for prioritized personas
105 - 150 Feedback and consensus
150 - 170 Nominate/appoint persona advocates and assign responsibilities
170 - 180 Next steps and sponsor closing 

These stakeholder-generated persona sketches are all you need to prioritize and answer the “who must the Intranet serve” question.   At the conclusion of the workshop, these personas begin their life cycle as stakeholder sketches.  These sketches will go through a maturation process to ensure that they become robust personas, supported by extensive and ongoing user research and feedback (I'll be writing a separate article on grassroot user research specifically for intranets. See my new workshop: Enterprise Personas & User Research Techniques).  There is wisdom as well as an ethical obligation to disclose the amount of research rigor that goes into developing a persona.  Without this transparency, how can we expect decision-makers to feel comfortable trusting these tools?

Personas and requirements in portal development
Traditionally, persona are explicitly published and shared with the Intranet team to ensure that Intranet direction and development is targeted at audience segments. 

When developing an intranet or portal and, specifically, when designing complex everyday workspaces for core business audience segments, the stakeholder-generated persona sketch is not detailed enough. This is because the level of personalization that a portal is expected to offer needs more detail as to how the portal supports specific business processes. In principle, these could be identified through a series of in-depth interviews conducted with a representative group of the various user audiences to delve deeper into their daily workflows and tasks.  Business analysts generally undertake this activity with the output being a system requirements document.

Developing system requirements is essential.  We have found that a user-driven focus on in-depth user requirements complements system requirements and offers a development process that embeds the business owner and key users in iteratively shaping and refining the overall solution.  

Persona advocacy
Persona advocacy is the ongoing focus on audience requirements.  This methodology has helped us achieve success in creating portal-oriented personas and pilots that deliver results within acceptable schedule and resource constraints.  Persona advocacy is about continuously and rigorously advocating on behalf of the persona.  The persona advocate can be a member of the web team assigned that responsibility.   A member of the web team can be a persona advocate, as can any energetic and knowledgable member of the organization.  This works well for a general services administrative persona or a new-hire persona, as everyone has an opportunity to wear those hats. 

For a specialized core business persona with complex business information needs, the Persona Advocate needs to be someone with business process and subject matter expertise.  The Persona Advocate should be someone recognized by the organization with leadership and consensus-building skills as well as vision about what the portal or Intranet site can be and do for the organization. 

At one government agency, towards the end of a persona workshop, we decided to test another approach by opening the floor for nominations for “Persona Advocates”.  A senior scientist stepped forward to accept the position of persona advocate for the scientific and regulatory reviewer persona.  He was captivated by how rapidly the persona workshop built consensus around internal customer segments.  As persona advocate, his first activity was to share his enthusiasm and vision for what he regarded as the Universal Scientific and Regulatory Reviewer portal.  His vision was a core set of content sources and organizing taxonomies that would universally appeal to his 3,000 peers across the ten business units of the agency. 

His portal vision was quickly formalized as a pilot falling under the agency’s enterprise portal initiative.  A Persona Advocacy team was chartered to support the pilot. Members and responsibilities of of that pilot team included:

  • A Persona Advocate who provides the vision and acts as cheerleader, facilitator (within the core audience segment), and recruiter of persona representatives.
  • A Project Manager who provides logistical support and coordination.
  • A Project Facilitator who assists in planning, developing, and presenting visual aids and concepts and recommending next steps.
  • A Subject Analyst who supports the Persona Advocate and has webmaster expertise within the selected business processes.  This member is responsible for identifying and publishing html prototypes and articulating guidelines developed by the Persona Advocate and the committee.
  • Content Contributor(s) who support the Persona Advocate by performing content audits and identifying core content across all the business units.  They also develop explicit guidelines and scope notes that are the basis for content management guidelines to support the pilot (cataloging, indexing, classifying, and editorially enhancing content).
  • A Business Process Advisor who is a senior scientist or working colleague and provides advice and guidance during the development of the business taxonomies and content management guidelines.

The above represents the core team.  As the team develops draft prototypes, the Persona Advocate will reach out across the organization to his peers to create a working group of persona representatives.  This group will react to the early prototypes and refine these.  This group serves to provide high-level user feedback and buy-in to ensure that the pilot broadly meets the needs of the larger user persona audience.  

The Universal Reviewer pilot program, over the course of four months, achieved 90% participation across ten diverse business units.  The Persona Advocate was extremely successful in achieving buy in by employing a balance of vision and refreshing consensus-building through open discussion and feedback.

Monthly two-hour reviewer representative meetings focused on discussions designed to vet the top and second level reviewer categories and the content they should contain.  The Persona Advocate worked to facilitate building consensus for a common, “plain language”, vocabulary (set of taxonomies). The Persona Advocate provided leadership by taking his business unit’s content resources and creating a comprehensive HTML working prototype.

The persona representatives provided critical feedback for redesigning early prototype interfaces so they became uncluttered and simple to comprehend.  As we worked through a scenario (what happens as the user transitions from the home to a secondary page), we identified a set of personalization expectations.  Reviewers were keen for the solution to auto-identify the reviewer’s business unit (without the reviewer having to sign-on to the system) and set a default context for displaying filtered (highly relevant) resource lists.

Lessons learned
We have now used the Persona Advocacy approach on several projects, and the lessons we have learned include:

  1. At the first meeting with the persona representatives, share the vision of “what is possible” using visual mock-ups.  This mockup requires a little more “front-loading” (ie. prep time).  It is much easier to engage a group by asking them to critique something tangible than to ask them to create in a vacuum.  And, don't be at all surprised or put off if the audience aggressively critiques this - take it as a positive sign that they care enough to take an interest in shaping the outcome.  We solution designers can sometimes get caught up in our personal bias of offering "feature rich" experiences, when extremely busy process owners often desire uncluttered and simple.
     
  2. Monthly collaborative meetings are required to sustain momentum and keep everyone communicating.  Each meeting should introduce good practice examples that help to build momentum.  For example: the Persona Advocate and subject-matter editor selected one business unit and built HTML pages to showcase the potential for the Universal Reviewer page.

  3. Ensure that the feedback and assignments you request from the persona representatives is a fairly lightweight exercise and is extremely easy to submit.

  4. Make sure that results are promptly summarized and distributed at the next meeting.  We created an easy-to-use input template and asked reviewers to identify one most prominent resource for each category.

  5. Review mock-up user-interfaces and iteratively refine these based upon feedback.

  6. User interface and interaction design requirements helped clarify the specific need for a link management application, one that contributors would use to catalog reviewer resource URLs.  Metadata entered into this database application would drive the dynamic, personalized and highly relevant content experience.  Be prepared to rapidly build these contributor and end-user applications, or ensure that your content management platform can support these requirements.

  7. Start working early on effective governance models to identify resources and practical and understandable information and content management guidelines so the shift from pilot to production is not delayed.

Summary
On the basis of the projects we have worked on, we believe that Intranet and portal initiatives would benefit from adapting the Persona Advocacy methodology and ensuring that it complements more traditional use-case and system requirements methodologies  carried out by business analysts.

The complexity of portal applications, in particular, means that the accepted route to persona development may not be as effective as it could be. Using Persona Advocates ensures that not only are useful personas created quickly but these are rigorously extended so there is alignment and buy-in by the business units.

Pilot programs focused on key user groups and improving core business processes must deeply involve the participation and feedback of the ultimate business users.  Selecting the right Persona Advocate and supporting their vision with a user-centered project plan and design principles may be just the right formula for the portal’s success.  Ensuring that the first persona advocacy program is successful paves the way to use this as a repeatable process for additional core personas!

The project management approach should concurrently develop vocabularies, refine resource cataloging practices and evolve mock-up end-user interfaces.   User-centered design principles should be adapted to each situation and are instrumental in delivering informed specifications for technology and application development.

Interested in more information about Personas and designing for specific audiences?

I will be doing a lot of thinking about this topic in the near future, so drop me an email [howard@mcq.com]  if you'd like to receive additional information and articles relating to personas, user research and driving application development and business strategy with user-centered research methodologies.  I am also offering the half-day workshop, Enterprise Intranet Personas: Using User Research techniques and personas to drive intranets and portals programs in Copenhagen in March, 2009 and in Washington, DC in June, 2009.  See the right column CONNECT WITH US on the McQ Home page.  This is also available to be brought in house into your organization.

Further reading

There is a good introduction to personas at http://www.usability.gov/analyze/personas.html 

Step Two Designs, a leading intranet consulting company based in Sydney, Australia, has published a briefing paper on how to create personas. http://www.steptwo.com.au/papers/kmc_personas/index.html

Two excellent books on persona development:

The User is Always Right – A Practical Guide to Creating and Using Personas for the Web, by Steve Mulder with Ziv Yaar, published by New Riders Publishing in 2007.

The Persona Lifecycle, by John Pruitt and Tamara Adlin, published by Morgan Kaufmann in 2006.

Microsoft has made extensive use of personas.  See the following:
http://research.microsoft.com/users/jgrudin/publications/personas/Pruitt-Grudin.pdf
http://agile.csc.ncsu.edu/SEMaterials/Personas.pdf


ABOUT THE AUTHOR
Howard McQueen is the CEO and Senior Consultant for McQueen Consulting.  He has more than 28 years consulting in the field of information management and in assisting organizations with information and technology solutions.  Throughout his career, he has advocated for emphasizing end-user requirements and has continuously sought to improve the overall user experience.  He established McQueen Consulting in 1995.

Howard develops Internet and Intranet strategy and web implementation planning, and provides a variety of supporting advisory and facilitation services. He has also developed metadata strategies and metadata implementation plans that have enabled organizations to make progress with personalization and customization.
Howard has worked for clients in North America and Europe, including Newsweek, the International Monetary Fund, the World Bank, the U.S. Food and Drug Administration, and Boehringer Ingelheim (Pharmaceuticals).
Howard was Chairman of the Intranets Conference from 2000-2003  and in 1998 co-founded the Intranet Professional newsletter.

Howard is also a founding member of CMPros, as well as a member of the Information Architecture Institute.
In his spare time he designs landscapes, photographs orchids, water lilies and nature, practices yoga and travels extensively.   He currently resides in Asheville, NC, a mountain town widely recognized as one of the top five best places to live in the USA.

Howard holds a B.S. in Industrial Management from the Georgia Institute of Technology.  He can be reached via email: howard@mcq.com and via telephone: USA 912.596.3713.