Scenario
Marge has set up scheduled check in requests for both Bart and Lisa right after school and around dinner time, at 7pm. Marge gets home from her full time job and expects to see her daughter, Lisa, at home, but she is not there. She asks Lisa to check in immediately and Lisa checks in not long after the request, since checking in from the application is non-invasive and doesn’t interfere with her activities. Marge sees from the application that Lisa is still at school. Lisa is currently at chess practice, and a couple of hours after she responds to the check in request, she asks her mom to pick her up through the application.
...
- Check in
- Pick up request
- Check in reminder setting
Designs
Design 1
Description: Traditional webapp/app for both user classes. A check-in feature (one-click at minimum, more information optional) pops up on the child’s screen even if they are not within the application (push request) to remind them and give them the opportunity to check in.
...
Safety: Need to be editing a scheduled CheckIn event to delete it prevents spurious deletions by parents. The application doesn’t make it clear to the child that his location (GPS) will be sent - this is not exactly a safety issue, but can lead the child to have an incorrect model of the system. The parent needs to go to the application/website to see check-ins, which means that they might not know that their child has already checked in (also an efficiency issue, as noted above).
Design 2
Description: Webapp/app for parent to set things, app for kid to check in, check in calls parent with recorded message. Details as in design 1 are also available on the website. The check-in history would also differ from design 1 in having all children's histories and settings put together (interleaved). This design could include a different mode (not shown in these storyboards) where the parent does not need an account, just enters own phone number, kid’s phone number, requested info, and time (or instantaneous), then gets the recorded message check-in by phone. (In this case, they would not be able to see the details on the website at a later time.)
...
Safety: Parent may miss the call telling them the check-in info, though it will still be available on the site in the mode where parents have accounts (i.e. reduces to the safety of design 1 in this case). Parent may also be disturbed while busy or woken up by the call.
Design 3
Description: As in designs 1 and 2, the parent can schedule check-ins and send check-in requests in the app/website, but requesting a check-in sends a text to the child. The child texts back in the correct form, which creates an entry for parent to see.
...
Safety: If the child enters something wrong, then the parent will either get no information or wrong information. This webapp also relies on trusting the child to enter the correct location and not fib.
Storyboards
Design 1
Marge goes to the home screen and clicks on "Request CheckIn Now" under Bart's tab:
...
From here, Marge added a once-only 10pm check-in request for Bart.
Later on, Bart sends a "Pick me up" request from the same screen as Lisa did earlier, but instead specifies a reason before submitting.
Design 2
Design 2 is almost the same as design 1, except that a recorded message is sent to the parents' phone instead of a pop-up on their phone to notify them of their child's check-in (not shown). Optionally, the home screen can use a all-in-one feed-style format, so all check-in responses appear on the same page instead of tabs for each child: 
Since tabs will not be used, a single button on the home page "Scheduled CheckIn Settings" directs the parent to the following page for all of their children:
The "Add" button will direct them to the check-in scheduler page, as shown in design 1.
Design 3
Design 3 has the same interface for the parent side (setting up check-in requests, homepage, etc.), but is different on the child side. Lisa or Bart will get the following as a text message to their phone when they are scheduled to check in:
...