Part Two — User Personas

EBSCO’s product teams (including product managers, designers, developers and content authors) benefit from leveraging user personas to inform use cases and provide additional guidance in their respective tasks.

Product Managers

Product managers use personas to define features and identify problems to solve. Instead of writing prescriptive requirements, product managers use personas to write a problem statement which identifies the needs and expectations of a user. Designers and developers then use their expertise to provide the appropriate solutions for the problem.

For example, instead of writing something like this:  

“Display custom links to other library resources provided by the librarian in Admin below abstract of each result list item.” 

Product managers may write a narrative from the perspective of a user persona to provide the context of the need and further define the problem to be solved.

For example: “Jeanette, a visually impaired research student, uses a screen reader with various library resources to locate the appropriate content for her research project.  

When a content item is not immediately available, Jeanette often wants to know if the content is available through another library resource. She has limited time to do her research and is frustrated when such options are not presented and must try and find the same content in another resource. Jeanette also wants to be self-sufficient and would rather not have to request help from the librarian to find this information.” 


Designers use personas to inform them of challenges or barriers that users may experience, further define requirements, validate design decisions and help maintain their focus on solving the problems identified by the product manager.  

For example, if a designer is presented with the following use case from a product manager: 

“Claire, the student researcher, uses various discovery tools to locate articles of interest and if an article is not immediately available, she often wants to see other options for getting the article through a library loan or to explore other alternate resources. Claire is frustrated when such options are not presented with the article she is interested in.” 

From reading Claire’s persona, the designer understands they must find a way to provide contextual links to additional resources when available. Including Jeanette, the visually impaired research student, in our design thinking, we know Jeanette shares the same goal as Claire but experiences additional challenges when using a screen reader.  

When we include Luiz, our student researcher who has dyslexia, we understand Luiz can become overwhelmed when there is too much information or when he is presented with a cluttered user experience (UI). 

Identifying and using different user personas helps a designer ensure their designs meet the needs of more users, address known barriers and do not introduce new barriers for the rest of our users. 


Developers are experts at understanding how code powers user experience, and how it works. However, as humans we tend to have a bias toward our own experience.  

With a requirement such as this: 

“On clicking the calendar icon, display calendar showing dates for the month, current date and arrows to move to next and previous month. Clicking a date populates the date input.” 

A developer might see this requirement and find a great open source component that does the work with minimal custom coding. One problem — the requirement doesn’t work with a keyboard, meaning screen reader and sighted keyboard users won’t be able to use it.  

Compare this situation to a persona narrative with additional context: 

“Carl has hand tremors and relies on a keyboard to conduct his research, since he can’t effectively use a mouse. Carl wants to limit his search by date and needs to be able to access all functions of the date picker with his keyboard.” 

“Using her screen reader, Jeanette needs to be able to understand which dates are available to select, and what the currently selected beginning and end dates are.” 

Knowing this additional context helps the developer keep in mind that there is more to building a calendar widget than a visual working with the mouse. With this in mind, the developer can either build custom functionality or find another open source component that meets these needs.  

Content Authors 

Content authors edit or create articles, e-books, etc. Since EBSCO is primarily an aggregator, most of our content comes from third parties. However, we do have publishing teams who must take accessibility into account when creating content.  

The persona context below is critical to understanding accessibility implications for content creation: 

“Luiz has dyslexia and finds it difficult to read large blocks of text, or text with many words per line. He prefers to have graphics to support textual content and reinforce the ideas of the content.” 

“Jeanette uses her screen reader to read content and finds reading large uninterrupted blocks of content challenging to use. She needs to be able to move within content using headings or other navigational methods.  

Jeanette also can’t see graphics and needs to have a textual description of them in order to understand the content they convey. Purely decorative graphics are of little use to her, and she wants her screen reader to ignore them.” 

Keeping these factors in mind, content authors can ensure their documents are organized in a way that supports these users — breaks up content with headings, keeps the line length shorter, and uses graphics with text alternatives to support the text.  

Personas are a valuable tool to help communicate the context of user needs, especially in the realm of accessibility. Subscribe to EBSCOpost to learn more about EBSCO’s accessibility processes and practices.