Case study

A few years ago, Chris (the lead developer of Making With Code) was working as a computer science teacher at an all-girls middle school. The school did not have an effective way to share information with teachers, so teachers often experienced confusion and frustration working on everyday tasks like taking attendance, looking up information about a student, or finding an up-to-date school calendar. The school decided to purchase a new student information system, and Chris was asked to lead the process of designing a new teacher portal.

We illustrated our design with a wireframe, a simple design of an app's layout. You won't create a wireframe for your Banjo app because Banjo doesn't support visual apps.

1. Who will use your app? (Who is your app's target user?)

The app will be used by teachers, administrators, and students. However, the teacher portal will only be used by teachers.

2. What need or problem will your app solve? How do you know this is really a need for your target user? How does the target user currently deal with the problem?

We conducted an extensive survey of teachers' technology usage at school. We asked about how teachers accessed various kinds of information, which technologies they used for various tasks, what their pain points were, and much more. Some nuggets:

• Teachers got way too much email. Often over 100 emails per day.
• Many teachers used email to keep static documents like the school schedule. This caused a lot of problems when updated versions were sent out.
• Many teachers created elaborate work-arounds to manage all the school's information. These worked, but were not effective at keeping records up-to-date. For example, some teachers would print out the contact info for all their students. This would usually not get updated when a student moved, the parents got divorced, etc.
• Teachers were often frenzied in the morning as they started the school day.
• Teachers had trouble accessing information about individual students, including parent contact info and health info.
• The school has a complex schedule, which made it hard for teachers to find out where students would be at a particular time and to see their attendance in other classes on a particular day. This was a safety issue.

Our design focused on three main needs:

• Make it easy to start the school day.
• Make it easy to look up accurate, up-to-date school information.
• Make it easy to look up information about students.

3. How will your app's design meet the need you have identified?

To make it east for teachers to start the school day, we designed the landing page to have all the information and forms a teacher needs at the beginning of school. Just log in and you're ready to go.

So that teachers could look up accurate, up-to-date school information, we created a school information page conaining links to always-up-to-date versions of files and current notes relevant to the whole faculty.

So that teachers could look up student information, we created a student search view and an individual student information view which pulls together relevant information from multiple systems.

4. How could your app possibly cause harm? (For example, could someone get hurt if data leaked or if someone used the app inappropriately?) What steps will you take to ensure that nobody is harmed by your app?

Possible harms:

• The teacher portal contains lots of student information which must be kept private and which is protected by laws such as FERPA.
• Additionally, the teacher portal contains information such as the school schedule and internal announcements which are not meant to be public and which could be safety or privacy issues if they were disclosed.
• One more source of possible harm is if teachers need to access information in an emergency and can't quickly find what they are looking for.

The main way our app prevented this harm was by requiring teachers to log in before they could see any information in the teacher portal. Fortunately, we were only designing the layout of the teacher portal, not the whole student information system. So we were not responsible for the security of the system as a whole.

We also restricted which students each teacher could see--teachers only need to see their own students and their advisees.

We believed that our design would reduce the likelihood of harm from teachers not being able to find the information they needed, but user testing was necessary to confirm this.