Personas: Practical Application for the U-M Library Website Redesign Project

The first post in this 2-part series, Personas – A Classic User Experience Design Technique, described what personas are and, generally, how to create them. I closed with some cautions about ways personas might come out less than helpful – creating flat, overloaded, or fake (unresearched) personas. 

In this second post, I’ll talk about the personas Ben Howell, Denise Leyton, and I have been developing for the Library Website Redesign Project and how we hope to use them to inform design decisions.

Designing the Personas

After considering our main audiences and how their needs aligned, our team arrived at five core personas: Undergraduates, Grad Students, Instructors, Researchers, and Visitors. Those five groups may sound obvious, but in my first attempt to segment types of users, I came up with 12 different groups including transfer student, STEM researcher, and donor. The team decided that creating distinct personas for that many types would be both hard to complete and not easy for the rest of the project team to take in. This led to a reframing conversation where we narrowed the set.

From the beginning the team talked a lot about capturing the breadth of our user population, and we worried about flattening unique characteristics to make an “average user.” An idealized or averaged user wouldn’t tell a rich story or give deeper insight to inform our current steps to redesign the Library's website redesign project. Because of our diverse user base, we decided to enhance our five core personas with details where individual needs might be different.

For example, some factors that could change might include:

  • A person with a physical disability or other health concerns might be uncomfortable having a long conversation at a service desk - or may have trouble entering the building or using the website.

  • A person’s major or field of work might influence the library location they visit and services they require.

  • A person’s life experience might influence their familiarity with academic conventions.

To further emphasize individual differences, we deviated from standard persona development practice by using sets of photos to represent each type of user (so a range of faces, rather than a single image or specific demographic information that would include name, age, and gender).

Following traditional persona models, we created goals, needs in relation to our service, user limitations, and situational stressors (or frustrations). These details help flesh out user behavior and suggest where our services can help or hinder users in pursuit of their goals. For example, goals are overarching for each group (like academic success, entertainment, sense of belonging), while needs list services most likely for each group and at the same time leave room for more specific needs. Limitations include things like time or money, as well as other constraints like habits or expectations. Situational stressors focus on challenges and frustrations potentially experienced by a particular persona's role.

Using the Personas

As described in my first blog post, use of personas can help build empathy and understanding for our target users, and can help us avoid designing for ourselves. With our user groups better defined, the Library staff members involved in redesigning our website have a shared vision of who we're designing for, and how to tailor features for each user group.

The next steps for our persona creation team is to invite Library staff into conversations about the five core personas, in an attempt to enhance the models or to address unique audience needs that we may not have addressed. For example, we may hear from our STEM colleagues about unique needs of clinicians or laboratory-based researchers that should be included in our work.

Questions about our development process or the five core personas can be directed to me (Robyn Ness), Ben Howell, or Denise Leyton