System Design

System Design

MU School of Medicine Web Applications

Work ethnographies have identified orientations for design, including the creation and use of shared artifacts and structured communicative practices (Suchman, 1995). Combining this type of ethnographic work with design-based research allows alignment of designs with their ultimate embedded contexts-of-use as understood and mediated by those engaging in the activities (Bell, 2004). For the following MU School of Medicine (MUSOM) applications, I used a “situated action” approach to design, requiring me to match the way people behave and use technology with the details of the work practice (Suchman, 1983).

Guided by Isaacs and Walendowski’s (2001) design process and an iterative ADDIE design model, I take the following, overlapping steps to design performance support applications at MUSOM:

  • Task analysis with key stakeholders to understand the users’ needs and create user task lists: I conduct multiple rounds of interviews, focus groups, and direct observations with key stakeholders to understand the business rules that guide the process. I use feedback from stakeholders to develop user task lists (see Appendix A of the M4 Registration Functional Requirements Document).
  • Design user interface mock-ups: User task lists guide the design of interface mock-ups. Using image manipulation software, I create mock-ups of each interface. Nielson’s (1995) heuristics for user interface design help me make design decisions. For example, the M3 and M4 Registration systems embraced the “recognition rather than recall” heuristic and provided users quick access to course descriptions and instructor information while searching for courses. The design also embraced the “visibility of system status” heuristic and kept users informed of how many seats were available for each course, how many students were on a reserve list, and their number on a reserve list. Mock-ups are shared with stakeholders to gather feedback and establish proof of concept.
  • Draft functional requirements document: The functional requirements document describes business rules and existing processes, the purpose of developing an online system, and outlines the scope of the project. The requirements section includes tagged mock-ups with corresponding user specifications. Each element and function is specified for all user interfaces. The document also includes a project timeline and appendices for reference information.
  • Present project to programming team and begin iterative development process: I co-led a work group to formalize the iterative development process our team uses to develop web applications. The outcome of the work group outlines our process. Development takes place in five phases with constant interaction between the designer (role titled “Product Business Analyst”) and the lead programmer (role titled “Primary Engineer”).
  • Formative usability testing: I am responsible for coordinating and facilitating formative usability testing during the development process. The purpose of usability testing is to ensure that the people who use the product “can do so quickly and easily to accomplish their own tasks,” and I embrace the following five characteristics (Dumas and Redish, 1999): 1) the primary goal is to improve the usability of the application, 2) the participants represent real users, 3) the participants do real tasks, 4) I observe and record what participants do and say, and 5) the resutls identify problems and solutions.
  • Diffusion and implementation: For the applications I design, I serve as the change agent for diffusion and adoption. As described by Rogers (2003), as change agent, I work with stakeholders to develop a need for change, establish rapport, empathize with their needs and translate their needs into actions that influence their behavior change. My work as change agent begins during task analysis and throughout each step of the design and development process. I also coordinate and facilitate training for each innovation.
  • Summative evaluation and revision: After implementation, I continue to evaluate usability and user satisfaction and lead the process of fixing bugs, incorporating enhancements, and providing help materials, as needed.

M3 Two-Week Elective Registration and Add/Drop System

In March 2016, the School of Medicine launched the M3 two-week elective registration and add/drop system. A curricular change provided third year medical students an opportunity to enroll in two-week electives. I designed an application that allows students to enroll in courses online and add and drop their enrollments throughout the academic year. Project artifacts include the functional requirements document and student tutorial.

M4 Registration and Add/Drop System

In March 2012, the School of Medicine launched the M4 Registration and Add/Drop System. I served as co-functional designer and co-project manager. In collaboration with a fellow colleague, we designed an application that allows Year 4 medical students to enroll in courses online and add and drop their enrollments throughout the academic year. In addition, the application serves as an advising tool for the Associate Deans who have the ability to request meetings with students they feel need advisement and deny students’ access to the registration system until the advisement meeting occurs. The system increased the efficiency of the registration process and student satisfaction was impressive. Furthermore, the additional advising features serve as a tool for educational improvement during student’s fourth year. Project artifacts include the functional requirements document and a student tutorial.

Exam Re-evaluation Request System

As lead functional designer of the Exam Re-evaluation Request System, I used a situated action approach to design a system that moves a complex, idiosyncratic paper process to a streamlined online application. Before launching the system, the “manual” exam re-evaluation request process was conducted via e-mail and hard copy forms. Using the paper process, a student’s re-evaluation request for one exam question required office staff to send and receive information to all stakeholders using five unique paper forms. The five paper forms contained duplicate pieces of information with some pieces intentionally excluded to insure student anonymity. During the last re-evaluation cycle in which the manual process was used, there were a total of 23 requests for re-evaluation of an exam question resulting in 115 unique forms for office staff to quality control, send, receive, and track. The amount of administrative work required to facilitate re-evaluation took away from the potential learning opportunities the process offers students. In addition, the manual process frustrated faculty who had already given large amounts of time to the exam process.

Using a “bottom-up” approach to task analysis, I actively participated in the re-evaluation request process for one year to observe and participate in “embodied actions” of the actors facilitating the process. After thorough task analysis, it was clear that by moving the paper process to an integrated web-based application, information could be entered by office support staff only once electronically and then pieces of information could be sent and received to and from stakeholders electronically. In addition, an online system could successfully track the process and eliminate the need for the five paper forms that comprise a single re-evaluation request.

As part of the functional requirements document, I included detailed mock-ups of each screen and mapped each mocked-up function to written detailed specifications. Development took place in three iterative phases and included creation of four unique user interfaces. An “admin” interface was developed for office support staff. The admin interface is the most complex and serves as the driving force for moving the re-evaluation process forward. Development of the application is complete and the system has been used for the past six re-evaluation request cycles. Project artifacts include the functional requirements document, a faculty tutorial, a student tutorial, and screenshots to represent the process and display each interface (click the image below to view screenshots).

Coursework Web Applications and Reports

Distance Learning with Blackboard

During the ISLT 9471: Instructional Systems Design course, I collaborated with student colleagues to develop an instructional site for MU Direct graduate students recently enrolled in an online Blackboard course. The purpose of the site was to familiarize and guide users through the Blackboard platform to build their confidence and demonstrate how utilizing specific Blackboard tools and features can contribute to a student’s success in their Blackboard courses. The Web site provides demonstrations for specific tasks that Blackboard users need to know when getting started, navigating, communicating, and managing files. Project artifacts include the Web site and final project report.

Graduate Student Progress System Enhancements

Artifact:
Link to ReportProject Report

During the ISLT 9410: Human Computer Interaction course, I employed a situated action approach and ethnographic methods to 1) analyze a problem, 2) design a solution, and 3) develop a plan to evaluate system performance outcomes for enhancement to a Graduate Student Progress System (GSPS). Project artifact includes the final report.

Needs Assessment Report: Documenting Patient Education on Patient Teaching Records

Artifact:
Link to ReportProject Report

During the ISLT 9474: Needs Assessment course, I identified a performance problem at my workplace—a health care system—in which policies and regulatory requirements states that every patient’s chart must include a completed Patient Teaching Record (PTR). Monthly audits of patient’s charts showed that overall only 10 to 25 percent of patient records included a completed PTR. I conducted a needs assessment using Dr. John Wedman’s Performance Pyramid as a guide. Data was gathered using techniques such as extant data analysis, interviews, observations, and surveys, and I identified instructional and non-instructional solutions to the performance problem. Project artifact includes the final report.

Evaluation Report: A.T. Still University’s School of Health Management’s Faculty Orientation Course

Artifact:
Link to ReportProject Report

During the ISLT 9455: Formative and Summative Evaluation of Instruction course, I collaborated with colleagues to develop an evaluation plan for A.T. Still University’s School of Health Management (ATSU SHM) new faculty orientation course SHM-FAC 100. The plan outlined an evaluation study, with both formative and summative components, designed to assist data-driven decisions regarding the ongoing improvement and effectiveness of SHM-FAC 100. Specifically, the formative component would assist the client as they identify course, faculty handbook, and delivery system improvements prior to the course release in July 2009. The summative component would investigate the course’s effectiveness at preparing faculty for facilitating online courses at ATSU. Project artifact includes the final project report.

References

Bell, P. (2004). On the Theoretical Breadth of Design-Based Research in Education. Educational Psychologist, 39(4), 243–253.

Dumas, J. S., & Redish, J. (1999). A Practical Guide to Usability Testing. Intellect Books.

Isaacs, E., & Walendowski, A. (2001). Designing from Both Sides of the Screen: How Designers and Engineers Can Collaborate to Build Cooperative Technology. Indianapolis, Ind: Sams.

Nielson, J. (1995). 10 Usability Heuristics for User Interface Design. Available at http://www.nngroup.com/articles/ten-usability-heuristics/.

Rogers, E. M. (2003). Diffusion of Innovations, 5th Edition (5th edition). New York: Free Press.

Suchman, L. A. (1983). Office Procedure As Practical Action: Models of Work and System Design. ACM Trans. Inf. Syst., 1(4), 320–328.

Suchman, L. (1995). Making Work Visible. Commun. ACM, 38(9), 56–64.