Student Information System (SIS)
How might we build an intentional university?
In my first year as product design lead for the Minerva Project's Schools team I built a number of student-facing apps to reinvent the classroom experience and support the operational challenges of our first class of admitted students and the staff who supported them.
Established universities have years of institutional knowledge, structures, and staff roles to handle all the day to day details and any problems that might emerge. My job was to design new software that would help the company with all the small, but important details as we grew. How might we build an intentional university?
Minerva Schools, 2018
Why solve this problem?
Design tools to simplify complex operational challenges for students and staff.
After a successful first year, the plan was to grow quickly and house many more students in cities all over the world across many different time zones. Our first residential campus expanded to house many more students in cities around the globe including Berlin, Buenos Aires, Istanbul, London, Seoul, and Tai Pei. The operational challenges for students, staff, and faculty quickly became much more complex.
For instance, students needed to collect and submit information relating to citizenship, visa applications, travel-related medical forms, and insurance. Many of these transactional tasks were completed on one-off interfaces & apps and initiated by individual email communications.
Scope: 12 weeks to build a new responsive singe page web app.
Role: I led product design as individual contributor.
Team: Myself, a PM, 3 designers (visual, brand, and front end), and 12 developers.
Type: Task flows, story mapping, prototyping, wireframes, mockups, design thinking
Tools: Sketch, HTML prototyping, front end frameworks, InVision, Zeplin.
Defining the problem
To improve the consistency of experience across a broad product surface area we would need at least two new products that would help students & staff make sense of scattered tools without adding to the mess.
A new dashboard web app for students to better plan for study abroad each semester, complete required paperwork for travel, access grades, view & update student records, and understand their status with the university across a number of distributed platforms.
A student information system (SIS) so that faculty and staff could all access the same data in order to better support students and meet requirements, solve problems, and handle special cases.
Student dashboard web app
Planning
I got cracking right away on mocks and early prototypes. Because these design artifacts aren't time consuming to make. I wanted to explore a wide range of ideas with the dev team before we started digging into scope & budgeting and in order to flag any refactoring that might come up, so we could make thoughtful decisions about whether or not it was worth the extra time for the team.
I worked with my PM to reach and met with a number of developers who would be on the project to begin to explore the technical constraints and opportunities and reality check them about some of our aspirational ideas.
At the same time I recorded some screencasts of my presentations to share more broadly in order to help the product team better align around the problems we're trying to solve and to surface any technical constraints we should consider as a group.
Info architecture walkthrough for dev team (7 mins)
Student dashboard web app
Discovery
To better frame the problem I interviewed students as they used our current system to prepare for their next semester. I created quick prototypes so that we would have both existing and aspirational artifacts so that interviews would be less conversational and grounded in actual task-flows. Across the interviews I discovered insights relating to the following broad themes:
Recognition— The student data entry system was built to accommodate the unique circumstances of our many students with different backgrounds and special circumstances. But, the overall design was generic and inflexible treating one student like the rest. Students were required to answer complicated yes/no decision trees regarding information they knew we already knew about them in order to fill out forms and input basic information.
Support— Most students didn't understand how each of the many small tasks they were asked to do impacted their overall status with Minerva. Rather than feeling appreciated for their unique backgrounds, their individual circumstances seemed to be a problem University.
Control— Complicated visa processes with many special exceptions were constantly changing depending on the individual countries of origin and the politics of the moment. These requests often came last-minute and demanded urgency. Students didn't have the opportunity to plan for and schedule this work. The many tasks were transactional with small bits of information exchanged in ad-hoc back & forth email communications.
Remote interview sessions with students (1 min).
Student dashboard web app
Implementation
After identifying aspects of an improved experience, I began to prototype & explore new concepts to help the team envision these improvements.
I explored a few competing concepts that situated upcoming tasks, completed paperwork, and overall status within a broader framework that might be more relevant to students.
Prototypes of 3 alternatives: timeline-centered view; view of progress for the current academic year; academic performance-centered view.
Student Information System
Planning
Now that the dashboard for students was finished, I wanted to get started on a Student Information System (SIS) for staff and faculty.
I decided to begin with the goal of making the current interface one step better than what we had. There were a number of ad-hoc tools for student data built with Django admin, but they were tricky to use. Access was limited to the product team, so faculty and staff had to put in requests for the product team to pull specific queries. In this case, the biggest impact would come from access to the toolset and we wanted to deploy something soon— but I wanted to take the opportunity to improve on the toolset and worked with my PM to budget some time for improvements.
I started by creating low-fidelity prototypes and diagrams. That way, I could work with a few developers and think creatively about how to improve things without getting bogged down in technical challenges. As before, I recorded screencasts of the presentations I delivered in small meetings to share with the entire product team.
Exploration of preset filters for planning with dev team (4min).
Student Information System
Discovery
After getting a better idea from some folks on the dev team about the technical challenges and considerations. I spent a few days improving the fidelity of the mocks and fleshing out details.
After that, I reached out to faculty stakeholders to begin to better understand the problem space and reality check some of our aspirational ideas.
We knew we wanted to help stakeholders answer questions by more broadly offering data without making requests to the product team. More importantly, we learned through stakeholder interviews that access to data helped people understand what they wanted to know and the right questions to ask.
Stakeholder interview with prototypes situated in a workflow. (90 second clip)
Student Information System
Implementation
I got busy scoping with a few of the developers and began to iterate on prototypes with stakeholders. At the same time, other engineers were busy refactoring our database and building out the back end to accommodate the new UI. Using our design system and custom front end framework, I switched from pixels to HTML and continued to prototype in code.
In discovery we learned that basic access to data, was valuable in helping people know what they didn't know and ask better questions. For this reason, we focused on building a really good UI for the most basic access to data to get things out quickly. We budgeted time in the future for some of the more complicated workflows we discovered, so that we could build updates on top of the core system. Rather than do all the work at once, I thought it would be better to wait until stakeholders spent some time with access to the data and got a better idea of what new tools they might need.
Prototype walkthrough for stakeholders. (4 mins)
Outcome
After building the student information system for staff & faculty. I was able to design important tools and flows on top of this infrastructure. For instance— I designed tools for advisors and other faculty to access student grades, for staff to forecast housing requirements, and a tool for staff to attach sensitive student records relating to special accommodations or involuntary leaves of absence. As a result, the company was able to enroll many more students without increasing headcount. As we scaled up, we need to make one staff hire per 100 students. As we continued to grow, this number got even better. Most other universities hire many more instructional staff and have ratios closer to 10-20 students per non-instructional staff member.
It's harder to quantify the impact on students. Support ticket requests relating to travel preparation and course registration became much lower. Staff were able to shift from pursuing students for the necessary information to proactive information sessions. Going forward we were able to build important tools on top of this initial app including new tools to better support payment plans and financial planning, to prepare for interviews, and— very soon— an experience for our first alumni.
Walkthrough of SIS mvp for faculty & staff (7 min).
More Case Studies
