By Taylor Moorman,
Research & Instruction Librarian, Montana State University Library
and
Scott W.H. Young,
User Experience & Assessment Librarian, Montana State University Library

Abstract

A job story tells the tale of a user, a task to be completed, and the service used to accomplish that task. The job story can be a helpful design tool for understanding users and improving a service. This method draws from the traditions of agile design, user experience, and service design, and it is now beginning to enter the practice of library and information science. In this article, we introduce the job story for library practitioners. We begin by locating the job story within its wider context of service design tools. We then describe our own experience in creating a job story about a service in our library, including our motivations, process, and results. We conclude with steps for creating your own job story.

Introduction

A job story is a service design and assessment tool that investigates an existing service through interviews and pattern analysis of stakeholder experiences. The job story itself is a brief statement from the perspective of accomplishing a specific task that emphasizes a problem situation, desired outcome, and expected results. The story is expressed through a structured template, such as:

When <problem situation>, I want <desired goal>, so that <expected benefit>.

Appearing as an assessment tool in engineering and software fields, job stories have only just started to emerge in LIS literature. In this article, we present a case study of the job story as an adaptable tool that can be applied in a library setting. This tool can be utilized to reveal insights for service improvement and to build empathy and interpersonal connection by highlighting stakeholders’ collective experiences. In the sections below, we describe our process in creating a job story. We begin by situating the tool within the landscape of design methods. We next provide a detailed case study, including our local setting, motivations, process, and results. We then discuss future directions for the job story, and we conclude with a set of steps for creating your own job story.

Situating Job Stories Within the Landscape of Service Design Tools

As libraries adapt to the fluid needs of our users through our spaces and services, the quest for solutions based on data-driven stories, along with the opportunity to react nimbly to problems as they arise, can steer library researchers into the realm of agile development. As librarian Daniel Forsman (2014) explains, agile development emerged in technology-driven fields as a process which allows organizations to pivot and iterate to focus on the most essential components of a service design or technology development process at any given time and adapt to new demands. This process plays well at the crossroads of many UX pathways, as researchers investigate the stories of the people they interact with and serve to do things in a more helpful way. As UX tools often lean on previous or parallel tools to best fit the question at hand, researchers can utilize the interplay among many UX methods to craft a tailored approach that best fits the problem or question in a particular moment of time. To help achieve user-centered library practices, LIS practitioners have incorporated a range of UX methods, including user stories (Young, Chao, and Chandler, 2020).

The following discussion highlights the relationship among a few UX techniques, leading to the development of the jobs-to-be-done or job story method.

User Interviews and storyboarding

To encapsulate a tale of a user’s experience, storyboarding is a useful technique to capture a common story for a group of users (Wheeler, 2019). To produce an effective storyboard, a user interview is the key component. The interview aims to uncover an unmet need and to work with stakeholders to better understand unique social, emotional, and functional needs around a problem, and finally merging collective patterns to create a prototype story of a general experience, before moving to a prototyping stage. Like the user interview, a job story is based on gathering common threads from individual experiences.

Personas

Moving prototyping from general experience to general user, personas create a profile of an imaginary user, connecting researchers to humanity on the other side of a product or service. The pitfall of personas is that while the tool does draw a team closer to understanding why a person may act the way they do, assumptions about why someone may do something leaves researchers struggling to connect motivations to practices (Klement, 2013). This tool can also leave too much of a user’s actual motivation in the minds of the researchers themselves.  Awareness of this potential issue can lead to productive conversations about our assumptions, as the persona makes these explicit (Anderson, 2019). However, the persona can feel fixed, and to react quickly to evolving problems and demands, another tool can be useful—the user story.

User stories

User stories emerged out of technology fields, where software and system engineers utilized the tool to capture how and why customers engaged with a system. A basic format for a user story captures the actions and outcomes of a particular user:

As a <type of user>, I want <an action>, so that <an outcome>.

In the context of Library and Information Science, user stories have been introduced as a way to focus attention on the person or people at the center of a problem, asking what they want to do and why (Ford, 2019). This tool helps interested parties push past the problem of only defining solutions by the “what” and “how,” turning to the importance of the “why” in user motivation and action (Lucassen et al., 2018).

The benefits of user stories are that the succinct and descriptive result—the story itself—strips a problem down to its essentials, focusing on those who need to benefit in a situation and why (Ford, 2019). This concise and potent tool allows for a team to come together around a shared understanding of the problem from a user’s perspective.

Job story

The user stories format, however, can leave a developing team locked into assumed actions and outcomes for hypothetical users. Desiring a deeper dive into user motivation, Klement (2013) introduced a new way to explore a problem within development: the job story. A job story can be expressed through a structured template, such as the following:

When <situation>, I want (to) <motivation>, so that (I can) <expected outcome>.

The job story template strips away persona-based assumptions, focusing on context and causality in examining reactions to problems or situations. The tools are certainly not mutually exclusive, as teams can use different stories side by side, such as creating a job story to explore nuances of a problem, then utilize user stories to explore possible solutions to the job story (Klement, 2013). Job stories create a space for researchers to be “completely solution-agnostic” from the outset, to focus on a person’s motivations and actions based on extensive research, analysis, and synthesis (Anderson, 2019).

The job story builds upon the jobs-to-be-done (JTBD) philosophy within management science (Lucassen et al., 2018).  JTBD is a UX strategy that forces a user-focused approach, often drawing on talking to stakeholders to determine what unmet needs are at hand and how a user chooses to engage with that problem (Spool, 2019). Well-designed and applied research is key (Spool, 2019), and JTBD is another strategy for turning the inward focus of a team out to the actual needs of the human beings engaging with a service or product.

One major mental shift is to allow users to directly share their most relevant problems as opposed to over-structuring questions in an interview, which can lead the users to respond in a guided way, leaving unmet needs uncovered (Whitaker, 2018). The common ground of understanding is a recurring theme as practitioners evolve UX tools to best uncover and discuss user context to improve services and experiences. Importantly, the story structure can accommodate different stakeholders and different jobs, or services. For example, the stakeholder at the center of the story can be an end-user of the services. The story can also be crafted around the experience of the service provider, or an internal staff member, who operates or provides the service. This flexibility renders the job story as a structured yet adaptable tool for generating insights about a service from different perspectives.

Ultimately, the job story emerges as a service design tool well suited for seeking solutions to known issues, as well as building empathy through a shared service experience.

Job Story Case Study

In this section, we describe the process for creating and applying a job story in a library setting. We begin by providing an overview of our local setting, and we then discuss our step-by-step approach for a job story. We conclude by reflecting on outcomes and impacts.

Local setting

Montana State University (MSU) is a public, land-grant university located in Bozeman, Montana. MSU is one of only two universities nationwide currently classified by the Carnegie Classification as “Very High Research” with an enrollment profile of “Very High Undergraduate” (Indiana University Center for Postsecondary Research, 2021). MSU is Montana’s largest university with an enrollment of 16,249 as of Fall 2020 (MSU News Service, 2020). The MSU Library is centrally located on campus and is used frequently by students as a study space and social space. The main Service Desk of the library combines circulation and reference and is staffed primarily by student employees. Library staff function as supervisors for the students. Library staff and faculty are also available to respond to elevated requests in a tiered service model. The Service Desk is a busy service point, with over 20,200 interactions in 2019. As such a high-profile service touchpoint in the library, the Service Desk was a suitable subject for a service design project.

Job Stories Exploration and Creation

Our project was motivated by a desire to better understand the service design tool known as job stories and to better understand the operations of the Service Desk in the library.

The first author of this article was a support specialist and student employee supervisor at the Service Desk at the time of this project. From this position, there was an opportunity for direct application of any relevant findings in the daily workflow of the author. Having an internal perspective from a member of the Service Desk staff was also beneficial since the project proceeded with an embedded stakeholder who could communicate the job story process and findings to others in the Service Desk, as well as refer to the tool for collaborative Service Desk decision-making. This internal view in one of the researchers can lend itself to the sustainability of the job story, as that individual can function as a trusted communicator of the results and tool.

The second author of this article was not otherwise connected to the Service Desk in their duties. From this position, there was an opportunity to introduce an alternate perspective from someone who was not already familiar with the Service Desk. The view of the second author provided a more detached or open-ended dynamic to the analysis, since there was less knowledge with the current service and any related limitations, constraints, or challenges. Bringing together an “insider” view with an “outsider” view generated a consultant-style collaboration that was useful for generating research insights connected to real-world application.

Project Process

Our process for creating a job story followed a five-step plan:

1. Determine the service to be assessed.
2. Conduct observations and interviews with key stakeholders.
3. Analyze observational notes and interview transcripts for major themes, paying attention to how participants describe any problems, goals, and benefits of the service.
4. Complete the job stories template.
5. Share and discuss job stories with key stakeholders, including service providers, supervisors, and administrators.

In the subsections below, we provide brief overviews of these five steps.

Determine the service to be assessed

Our exploratory project focused on staff workflows at the library Service Desk, with an emphasis on communication flows. The Service Desk has a bustling group of staff and student employees who work to meet patron needs and is the main physical service point of the library. This shifting and busy environment was rich with opportunities for observing and identifying possible avenues to explore through the job story.  For the purposes of this job story, we oriented our analysis on the internal process of delivering the service. The “job” of the job story is the delivery of service at the Service Desk. As a result, the key stakeholders for this project are library staff and student employees.

This is an important element to emphasize here—job stories most often focus on end-users. But the tool can accommodate different perspectives from relevant stakeholders. And so, as we embarked on creating our own job story, we made the decision to situate staff members in place of the end-user. By centering staff in this way, we aimed to elevate staff voices and learn more about their experience in operating the Service Desk. Our thinking was that if we can improve the staff experience, that in turn will improve the end-user experience.

Conduct observations and interviews

To begin informing our understanding of the service, we spent one hour observing the workflows of the Service Desk. We took notes throughout the hour, focusing on the operations of the service. Following the observation, we talked through our notes and identified the following patterns of behavior.

• Patrons approaching the Service Desk looking for assistance with a variety of tasks
• Desk staffed by a mix of student employees and classified staff members
  • The physical layout of the Service Desk encourages patrons to interact with one of two computer stations, predominantly staffed by student employees
  • The “Perch” is a location, offset from the main Service Desk and behind plexiglass, where a scheduled rotation of staff supervisors can monitor service point activity conducted by student employees.
• Patrons approaching the printers and needing assistance to ask questions about printing
• Library faculty approaching the Perch to talk to the classified staff supervisor

These behaviors were used to formulate a series of six questions designed to explore Service Desk situations/problems, current actions, and desired outcomes.

Four staff supervisors and three student employees were interviewed. These anonymous interviews consisted of six planned questions, along with a spontaneously added query at the end of the first interview that was repeated for all interviews. The interview questions were as follows:

1. How do the staff members at the Service Desk interact with each other?
2. What common concerns from patrons do you observe at the Service Desk?
3. How are the common tasks/requests for the Service Desk handled?
4. What are the common workflow barriers or difficulties in responding to Service Desk tasks?
5. How do staff interact with library students between scheduled desk shifts?
6. What is the role and rotation of Perch staff? What are their tasks?
7. What metaphor would you use to describe the Service Desk model?

Identifying themes

To analyze the research data produced through the interviews, we followed the methodology of grounded theory. This approach aims to produce a theory of a process based on evidence drawn directly from that process (Glaser & Strauss, 2006; Creswell, 2009). Grounded theory often results in a practical model of the process in question. In our case, the process in question centered on our library’s Service Desk, and our goal was to produce a job story that can capture the experience of working at the Service Desk. Grounded theory is therefore an apt methodology to apply in our case, as the insights generated through its analysis can produce a practical model—the job story—of the Service Desk. By following a grounded theory approach, the themes that underlie our job story emerged inductively from the data produced by our interviews.

In terms of practical steps, an analysis of the responses to the interview questions required both researchers to review the interviews separately; following Creswell (2013), the two authors independently coded themes. This intercoder reliability helped us generate more consistent themes from the data and validate our results. Themes were derived from patterns, recurring ideas, and repeated phrases or sentiments. Coded themes were organized according to the template of the job story: problems at the Service Desk, the desired goals of the staff, and the staff motivations to reach those goals. After the opportunity to individually review the interview data, we came together to agree upon the themes of the qualitative data, utilizing the predetermined job stories template: When <problem situation>, I want <desired goal>, so that <expected benefit>.

The coding process revealed themes in the data that corresponded with the three main parts of our job story structure—problem, goal, motivation. Our interview script prompted responses along these lines, and our interview participants spoke to each of these three areas. The process of coding the qualitative interview data allowed us to find thematic coherence across our interviews. The methodology of grounded theory operates with this purpose in mind, to develop a working theory of a research subject. In our case, the research subject was the Service Desk staff experience, and the job story expresses the theory of the Service Desk staff experience, as grounded in the data.

Within the seven interviews we reviewed, we quickly came to the realization that there were parallel stories to tell about service delivery at this popular library touchpoint. Based on this discovery, we decided to pivot from our original plan of one core job story and create two types of job story for the Service Desk—an emotional story and an operational story.

Our results can be summarized as follows. Emotionally, library Service Desk staff are motivated to deliver excellent service and to feel that their contributions are understood and supported by other department members. Operationally, staff at the Service Desk expressed a desire for consistency among the various student employees and staff supervisors when staff rotations and handoffs occur. Notably, the interviews revealed a sharp awareness from library student employees and staff employees alike about the importance of clear communication and the need for effective interactions to keep services running smoothly. From these main themes—clear communication, excellent service delivery, and emotional support—we developed multiple job stories so that we could capture the complexity of providing service at the Service Desk.

The job story

Our process resulted in four interrelated job stories that capture the perspectives of both student employees and staff supervisors, with each stakeholder group’s story expressed with an emotional aspect and operational aspect (Table 1).

	Student Employee	Staff Supervisor
Emotional Aspect	When I am overwhelmed, I want to be supported by our process, so that I can feel that I am providing excellent service.	When I need to make a decision at the Service Desk, I want to have flexibility, so that I feel empowered to help my students and make a difference that improves the experience of employees and users.
Operational Aspect	When the Service Desk rotates staff, I want to maintain a consistent connection with the supervisor, so that I can provide excellent service.	When I need to make a decision at the Service Desk, I want to have my department’s support in making that decision, so that I know that my decision supports consistently excellent service delivery.

Sharing job stories with stakeholders

In terms of impact, this set of job stories adds a new dimension to our understanding of the Service Desk operation and generates empathy and insights for designing and delivering the service. In everyday practice, our job stories have been shared with library administration, used to onboard new employees, and have been a point of reference in discussions related to staff service provision.

Project Impact

The completion of an in-house final report and presentation on the job stories process coincided with the early months of the coronavirus pandemic in Spring 2020. Due to this, we scattered our presentations over the spring and summer of 2020, presenting to the department head and Service Desk staff, as well as a newly hired program manager for the Service Desk in September 2020. Returning to in-person work in June 2020 required many changes in staffing and communication at the Service Desk, including fewer people in the area.

Several operational changes have taken place that implicitly built upon the information contained in the job stories report under the direction of the new program manager. After presenting the report to the program manager in fall 2020, we revisited the topic in April 2020 in order to assess the impact of the job story knowledge. She reported that the information was helpful to understand the dynamics in a new service environment, and her observations over her first eight months of her job confirmed the job stories we created. This feedback connects the job story outcomes to a potential continued use as an onboarding tool for new employees, providing a picture of the complexities of Service Desk operations. Changes at the Service Desk include a notebook at the Perch to easily capture and share events that happen during a supervisor’s shift with the incoming supervisor. This decision was reinforced by the information in the job story and was also a suggestion that the researchers came up with internally when thinking of practical methods of improving communication.

In the follow-up meeting to discuss the impact of job stories with the Service Desk program manager, she also emphatically stated that she would like to see this process repeated with Service Desk students and staff after the changes wrought by the pandemic, as she thought it was a valuable tool but could quickly become disconnected in an environment with high levels of turnover and therefore constantly new employees in both student and staff ranks  and to look at how things have evolved since the first set of interviews. This desire for an iterative process to check in with the undercurrents of services within the department fits the nimble nature and intent of job stories.

Lessons Learned

Interestingly, we began this exploratory project in order to learn more about user stories but realized that due to the central location of a Service Desk, it would be more valuable to focus on the concrete services that we noted during our observation hour.  After adapting the template to accommodate this and reviewing the literature, we realized we had created what would technically be classified as a job story template.

Even after reframing our template to focus on the service or job, therefore creating a job story, we found enough differences in the interview patterns between student workers and classified staff to distinguish the two roles (student and staff) in our final product. This liminality between UX tools allowed us to utilize both the value of user stories and job stories.  The ability to move fluidly among UX tools, crafting the most effective story for the situation, in order to provide the most meaningful insights to stakeholders is certainly an area that deserves further consideration and thought in the realm of creative application of UX in libraries.

Job stories are typically designed to focus on the operational aspect of a problem or issue in order to develop solutions. When analyzing the patterns in the interview answers, it quickly became apparent that there was a deeply felt and experienced emotional aspect of operations that needed to be shared as part of the service story.  While the emotional component of a job story, especially as an integral component of the operational story, was not found in the existing literature, the value and possibility of moving deeper into the motivations and experiences of stakeholders within a job story template is an area to develop further.

When sharing out the results of our job story project, one important and unanticipated result is that our stakeholders (library staff, leaders, administrators) found the job story to be quickly understandable. As researchers who have also shared results on user persona and other person-focused UX projects, we discovered that the job story’s focus on the service provided an approachable entry to service design because the service is more known and knowable. This experience validated the literature discussing the barriers that persona and person-based assumptions could create in researchers. In continuing to explore job stories and other UX tools, the communication of outcomes within our organizations is a key aspect of successful implementation. The approachable entry into service design discussions that can be found in job stories is certainly worth another look.

Limitations

When utilizing the job story, we found it important to avoid over-structuring questions. As an agile tool, the job story was most effective when questions developed naturally from observations of the Service Desk.  Even then, we noticed in our interviews that our pre-selected questions left out general open-ended observations from our interviewees. To address this limitation, we added a spontaneous question asking for a metaphor to describe the Service Desk as well as an explanation of that metaphor to allow people to share their natural observations beyond our designated questions.

In terms of limitations to the tool itself, we recognize that the job story is just one of many potential service design and assessment tools that a practitioner may apply. We often call to mind the metaphor of tools in a toolbox. As user-centered service designers, we benefit from having a range of tools to apply for different situations and in different complementary configurations. The job story alone, for example, does demonstrate a limitation: in being so structured and focused around the three areas of the story—problem, goal, motivations—the job story can collapse insights into preexisting categories. Practitioners can use the job story in conjunction with other human-centered UX tools to form more complete pictures of both the people and services at the center of the story. Further tools that are particularly suitable as complements to the job story include: user personas, service safari, diary study, journey map, service blueprint (Service Design Tools, 2022).

And as people and services turn over, the job story should be kept fresh through iteration. This process can be time consuming as the story would need updating over time to remain representative of the service experience.

Steps for Creating Your Own Job Story

The points below provide a summary overview of the steps that can be followed to create a job story:

1. Identify a team. Start by connecting with a pair or a group of user-centered, service-oriented co-workers.
2. Determine the service that you wish to research. In our case, we chose the library Service Desk. But the job story can be applied towards a range of services that are used to complete a job, such as printing, checking out a laptop, or accessing a digital collection.  It’s okay to start small if that’s where your comfort zone is—simply demonstrating to yourself and others how the process can work can be beneficial.
3. Follow the job stories template: When <situation>, I want (to) <motivation>, so that (I can) <expected outcome>.
4. Conduct observations and interviews with key service providers and/or users.
5. Analyze the observational notes and interview transcripts for major themes and patterns, paying attention to how participants describe any problems, goals, and benefits of the service.
6. Complete the template. The results of your analysis can be used to complete the three components of the job stories template.
7. Share and discuss your job story. Once completed, share your job story with key stakeholders, including users, service providers, and supervisors and administrators. Ideally, the job story will be actively applied to the design and delivery of the service.

Conclusion and Future Directions

The job story is a tool worth adding to a service design toolkit. By focusing on empathy-building and collaborative service improvement, this user-centered assessment tool lends itself to stakeholder feedback, allowing assessment practitioners to identify patterns that lead to new insights for identifying and addressing problems in library services. If you’re starting out with UX and service design tools, a job story is a good place to begin practicing, since it combines user-focused empathy with improvements to service operations. If you’re already working in a mature design and assessment organization, job stories can work alongside other tools such as user personas, service blueprints, and journey maps.

For our library, we demonstrated the job story as a proof-of-concept. After working through the tool, we shared our process and results throughout the organization. Not only have we added this tool to our own Service Design toolkit, but other library staff have seen the tool in action and can understand its application and effectiveness. In our case, we applied the job story to an internal process, with the library staff positioned as the user. In our example, the Service Desk story could be further supplemented with an additional job story that centers the library user and their experience at the desk. With these two job stories—one internally-oriented and another externally-oriented—a full picture of the Service Desk could come into view. Additionally, anonymized data from the interviews could be revisited and reanalyzed by the Service Desk employees, with the goal of re-interpreting the information to create further job stories. In this way, the flexibility of the job story tool comes to focus. The underlying research data can be iteratively re-interpreted as new staff are assigned to the Service Desk operation.

The job story is adaptable, and we imagine the tool expanding beyond the Service Desk and expanding beyond ourselves as story authors. As we’ve demonstrated the process for researching and authoring a job story, the expansion of the tool can be amplified by others throughout the library who can create job stories in their areas of expertise. For example, a job story could be created for one-on-one research consultations, where the student is the user and research is the job to be done. Librarians with reference and instruction duties would benefit from the insights produced through a job story. Such a story could help clarify or reveal new nuance in the instructional service experience for librarians while also demonstrating the service for administrators in a new way. Job stories can also be created for more mundane but critical library services such as printing. When a user needs to complete a print job, what is their operational and emotional experience? Everyday touchpoints such as printing can often go under-evaluated in our service ecosystem, even as they significantly impact the user experience. As we theorize library services, we follow the approach of Marquez and Downey (2016, 14–17), who mark out an inclusion vision of service in which all aspects of a library potentially operate in service to a user goal. Even the common object of a table, for instance, provides a surface upon which a user completes a job and thus reaches their goal. From this perspective, a job story can be creatively applied across the full range library services.

Ultimately, a job story is a tool for service design and assessment that 1) assesses existing issues with a focus on service improvement, and 2) helps build empathy and community connection by capturing the experience of delivering and using a service (Lucassen et al., 2018). In sharing with stakeholders, some of whom may be unfamiliar with service design practices, the focus on an existing and high-profile service gives an approachable entry to service design because the service is more known and knowable. We found that through applying the principles of careful observation, listening, and qualitative analysis of user interviews, that we were able to create a meaningful and unique job story for our library that captured the operational and emotional impact of our highest-touch service point.

References

Anderson, N. (2019). Jobs to be done personas. Medium. https://uxdesign.cc/jobs-to-be-done-personas-5faa0ea3d438

Creswell, J. W. (2009). Research design: Qualitative, quantitative, and mixed methods approaches, 3rd ed. Sage Publications, Inc.

Creswell, J. W., & John W. (2013). Qualitative inquiry and research design: Choosing among five approaches (3rd ed). SAGE Publications.

Ford, K. M. (2019). Who will use this and why? User stories and use cases. Information Technology and Libraries, 38(1), 5–7. https://doi.org/10.6017/ital.v38i1.10979

Forsman, D. (2014). Introducing agile principles and management to a library organization. http://publications.lib.chalmers.se/records/fulltext/200737/local_200737.pdf

Glaser, B. G., & Strauss, A. L. (2006). The discovery of grounded theory: Strategies for qualitative research. AldineTransaction.

Indiana University Center for Postsecondary Research (2021). The Carnegie Classification of Institutions of Higher Education, 2021 edition, Bloomington, IN.

Klement, A. (2013). Replacing the user story with the job story. JBTD. https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27

Klement, A. (2013b). Designing features using job stories. Intercom. https://www.intercom.com/blog/using-job-stories-design-features-ui-ux/

Lucassen, G., van de Keuken, M., Dalpiaz, F., Brinkkemper, S., Sloof, G. W., & Schlingmann, J. (2018). Jobs-to-be-done oriented requirements engineering: A method for defining job stories. In E. Kamsties, J. Horkoff, & F. Dalpiaz (Eds.), Requirements Engineering: Foundation for Software Quality (pp. 227–243). Springer International Publishing. https://doi.org/10.1007/978-3-319-77243-1_14

Marquez, J. J., & Downey, A. (2016). Library service design: A LITA guide to holistic assessment, insight, and improvement. Rowman & Littlefield.

MSU News Service. (2020, September 15). MSU reports strong enrollment and records in graduation rates and student retention. Montana State University. https://www.montana.edu/news/20418/msu-reports-strong-enrollment-and-records-in-graduation-rates-and-student-retention

Service Design Tools. (2022). Tools | Service Design Tools. Retrieved February 22, 2022, from https://servicedesigntools.org/tools.html

Spool, J. (2019). Jobs to be done: An occasionally useful UX gimmick. Medium. https://medium.com/@jmspool/jobs-to-be-done-an-occasionally-useful-ux-gimmick-21db21de2d19

Wheeler, M. (2019). Scrap the user persona. Replace it with the storyboard. Invision. https://www.invisionapp.com/inside-design/user-journey-storyboards/

Whitaker, H.J. (2018). Jobs to be done: An innovative needs assessment method for supporting extension product and program design. Journal of Extension, 56(5). https://tigerprints.clemson.edu/joe/vol56/iss5/5

Young, S. W. H., Chao, Z., & Chandler, A. (2020). User Experience Methods and Maturity in Academic Libraries. Information Technology and Libraries, 39(1). https://doi.org/10.6017/ital.v39i1.11787.