GR6: User Testing
Design
Parent interface
In our final design, parents start out at a screen where they see a list of all the jobs they've created:
They can create a new job using the "Create Job" button at the top left, which brings up a pop-up where they can paint over the times they want their job.
They can select an option at the bottom to indicate that they only want a sitter for some specified portion of the time they've painted. We originally planned to let parents paint slots with different colors to indicate how well they worked for their schedule, but decided to remove this after it was confusing for users during our paper testing.
Parents can also manage their contacts using a pop-up by clicking the "Manage Contacts" button
Babysitter Interface
Babysitters start out with a similar screen which lists the jobs they've accepted and other jobs available to them.
They can manage their contacts in the same way as parents and edit their schedule using the "Edit Schedule" button, which brings up this pop-up:
They can view their schedule overlayed with possible jobs by clicking the "Calendar View" button.
We had a lot of feedback on this calendar, originally we were using a bigger variety of colors such as a violet for accepted jobs, we found out was confusing to users. We instead decided to just use a deeper shade of green to indicate an accepted job.
Implementation
We implemented our backend using a django server running on caseymc's scripts account. The django server has a database with entries for existing parents, babysitters, and jobs, cross-linked as appropriate (so for example a job knows the parent that created it, the babysitters that know about it, the babysitters that have applied for it, and the babysitter hired for it).
We kept our webpages from GR4, but altered them so that:
- instead of displaying static data, parts of the page responsible for displaying mutable information make calls to the django server (by hitting a URL that specifies the desired part of the page and any other necessary information - like the username of the person logged in), which responds with an html fragment that the page then puts into the right spot.
- instead of doing nothing, parts of the page responsible for submitting information hit a URL of the django server with a post request; the django server updates its database appropriately. The page then updates areas that may have changed due to the submission.
We made the decision to use django mostly because of its learnability - none of us had experience making a web server, and we were impressed with the quality of django's tutorials and documentation. Our TA mentioned at our GR5 meeting that django was less good than some other options for plugging into a preexisting partial implementation; we can't speak to other options, but we did spend a lot of time rewriting in server-side python features that already existed in client-side HTML and javascript. The implementation we wound up with, static pages that hit various URLs to get the data they need to display, feels a bit piecemeal; it might have been more elegant had we written everything with django to begin with, learned to use its rendering feature, and constructed pages entirely on the server side.
Our code can be found at https://github.com/kpan/sitterPlan
Evaluation
For our user tests, we provided the following briefing:
We're SitterPlan and our goal is to help babysitters and parents coordinate their schedules to find optimal times for babysitting jobs. Our site allows for two type of users - parents and babysitters - who will each see a different view of the site. Parents can use the site to specify times that they'd like a sitter, and babysitters can use the site to look for jobs.
And tasks:
From the babysitter interface:
- Find an available job and apply for it
- You are willing to babysit between 5pm and midnight every day except Friday. Update your schedule accordingly.
From the parent interface:
-You want to hire a sitter for either Friday or Saturday 7-10PM so you can go to the movies. Make a posting for this job.
Here are the results from our user tests:
User A is a mother of a toddler who is used to scheduling babysitter jobs. She had no major problems performing the tasks and said that the interface was "very useable". When she created a job she started by adjusting the slider to only show times between 7 and 10pm. She quickly figured out how to use the flexible schedule option, but also left a comment saying that either Friday or Saturday would be good, which indicates that the interface might not be as clear as we thought. She also adjusted the slider when entering her schedule on the babysitter interface. When asked she said that she originally wasn't sure what the slider did, but said that it only took her a few seconds to figure out that it was just adjusting the calendar.
User B was a babysitter throughout high-school and worked for several families. She had no major issues completing the tasks. When asked to update the schedule, she initially went to the calender page and was initially confused when there was no apparent way to manipulate it. She also initially interpreted 'available' as her schedule being available. When creating a job, the painting interface mis-clicked due to the use of a track-pad, causing frustration. She also expressed uncertainty over what information to convey in the job title. We also discovered several bugs after testing. Calender blocks don't expand when the title overflows the box. Two jobs cause a doubling of the blocks in each location, making the interface look very bad. Babysitter schedule updating does not work correctly in Safari on a Mac (not one of our supported browsers).
User C has done a fair amount of informal babysitting, although he hasn't done it as a job. His only problem completing the tasks was that he missed the entire time / part of the time radio buttons on the create job popup, leading to uncertainty over whether he'd posted a job for both nights or for one or the other. He suggested moving the "Next" button down to the bottom right of the popup to make it more likely that users will read the radio buttons. He thought it was cool that you can click and drag on the painting calendars, although he didn't notice it was possible until the second task involving them. He was sad that the jobs displayed on the babysitter calendar view are not links.
Usability Problems
- Intention of slider is slightly confusing (minor) - We could have solved this by making the slider more consistent with other UIs, for example by putting it on the right side where it is usually found in other UIs.
- "Available" interpreted as schedule is available (minor) - Maybe use a different word, such as "Free".
- Flexible job option difficult to notice (major) - We could use the suggestion of moving the "Next" button to the bottom so that the user will be more likely to find the buttons.
Reflection
We learned a lot about the design process through this project. We saw how some features that made a lot of sense to us could be confusing or difficult to find for users. We also saw that going from paper prototyping to a computer prototype makes a big difference that would be useful to take into account. If we were to do this project again it would be a good idea to look ahead to the implementation stage earlier to get a more realistic sense of what we would build before planning everything out, since we planned some things that we didn't have time to build.
During the iterative design process, we ended up testing different parts of our design during different iterations of the testing. Understanding what one is testing at a given point in time, figuring out how to craft tests that keep the user from getting distracted by features that will be implemented later on, and knowing what features to test early rather than later seem to be critical skill that would have lead us to make sightly different design and testing choices throughout the project. There is also a balance of known errors going into a user test will deteriorate the efficacy of the test and waste time for the tester and user; however, one only has so much time to implement a design. If I had understood the full scope of the project and what technical skills would be required, I would have prioritized my study in a different manner. I believe our risk assessment and navigation through design iterations went well and I don't believe I would have changed that process significantly.