I framed my design practice around my experience as a Retention Manager for my previous employer (OPM provider). As a Retention Manager, my work impacted multiple stakeholders, but my relationship with each required me to wear different hats. In addition to coordinating and completing a host of administrative tasks, I was also responsible for several key deliverables. To provide data reports and student forecasts to managers and faculty, I was a data analyst. To maintain the student database and degree plans so the support team had accurate information for their students, I was a database administrator. To resolve issues with course access and plan student communications, I was a problem solver, mediator, technical support, and communications support. Finally, to create and implement solutions to bridge the gaps in our processes, I was a project coordinator and designer.
In my visual below, I started with stakeholders (blue) and the related deliverables because I was inspired by Howard (2011) who pointed out that part of situating the design is identifying the relevant stakeholders including myself as the designer. The stakeholders that I interacted with directly were my managers, faculty, and specific team members from the cross-functional teams. Although I did not work with students directly as a Retention Manager, the processes and products that I was involved in directly impacted their course registrations, degree plans, and overall learning experience in the program. For this reason, they were a key stakeholder because they were the targeted audience for our initiatives and provided feedback on their experiences. Similar to Howard (2011), I was in a position where I had inherited the portfolio from a different Retention Manager. Although they did an effective job with their role, I saw opportunities for improvement and gaps in the student experience that could be addressed. As such, I am also a key stakeholder and the change in the Retention Manager led to the decision to design and redesign our processes.
Secondly, I listed the tools (green) that I used to perform my tasks and complete projects. Aside from being restricted to using only the software approved by the employer, I was able to use the same tools for multiple tasks and in communication or collaboration with all the stakeholders. According to Laccheb and Boling (2018), my rationale for using tools are mainly situational (mandated by employer). Many of the tools were also rationalist selections by the employer because they were the most cost-effective option. The flexible use of tools for different goals and processes also reflects the designerly approach where tools are used to serve a purpose rather than to guide it (Laccheb and Boling, 2018). However, I am curious whether we have chosen different tools for certain tasks if our employer had allowed us to branch out beyond the approved tools.
Lastly, I described some of the key skills (orange) that I needed to have in order to use the tools effectively and complete my tasks. One of my main design tasks was to create new documents or improve existing processes in order to streamline the onboarding experience for new students or enhance their learning experience in courses. Although I was not part of the course development team, I found that my design process seemed most similar to the TAPPA process (Moore, 2016).
Below is an example of my use of the TAPPA process to create a registration support document for students.
Target: To provide students with step-by-step instructions and links for self-registration in courses.
Accomplishment: Students would be able to register for their courses on their own. We should experience a reduced number of incoming calls to the support team for registration help, lower numbers of students who forgot or did not register for the correct courses, smoother student experience on the first day of class including accessing courses and on-time tuition payments.
Past: We have written instructions that were emailed to students in previous semesters. Formatting the text into an appealing PDF with checkboxes to drive action may help students take initiative.
Prototype: The PDF draft was created and circulated to the cross-functional teams for revisions, feedback, and buy-in.
Artifact: The document will be introduced to students by the support team and will be consistently referenced in conversations to empower students to take initiative in their course registration process. The students will refer to the tasks and links listed in the PDF and utilize the checkboxes designed to help them stay on track. The team experienced fewer student communications regarding general registration help and had more time to focus on students who had technical issues or needed to make changes to their degree plans.
Howard, C. (2011). Writing and rewriting the instructional design case: A view from two sides. International Journal of Designs for Learning, 2(1). https://scholarworks.iu.edu/journals/index.php/ijdl/article/view/1104/1315
Lachheb, A., & Boling, E. (2018). Design tools in practice: instructional designers report which tools they use and why. Journal of Computing in Higher Education, 30(1), 34-54. https://doi.org/10.1007/s12528-013-9074-6
Moore, R. L. (2016). Developing distance education content using the TAPPA process. TechTrends, 60(5), 425–432. http://dx.doi.org/10.1007/s11528-016-0094-8