Case Study
A new dashboard for system admins
Summary
The Opportunity
A small, all-volunteer team of software programmers have started developing an online tool, named tinkl, which help trans and non-binary people find public bathrooms. Due to the ongoing workload of highly-technical tasks, the team expects to bring on some additional volunteers who will focus on less-technical administrative tasks, such as fielding reports from users about the public bathrooms. The stakeholder requested assistance with designing a new user interface that these admins can use to efficiently process the user reports.
A Solution
Following some research, I designed a prototype of a series of graphical user interfaces (GUIs) that could be implemented by the software programmers, and then used by the admins. I also provided additional supplemental documentation, such as detailed user flows, to guide the programmers in handling more complex scenarios that were not part of the prototype. I was responsible for most of the UX work on this project, but I did receive some assistance from three other UX researchers.
About the Client
tinkl is a web app, primarily for smart phones, that provides locations of public bathrooms that are gender-neutral and accessible to people who identify as non-binary or transgender.
For some of these people, typical public bathrooms — those assigned to men and women — don't feel accessible to them. It may even be outright dangerous for them to use given the intense anti-trans rhetoric that is commonplace in American society today.
This is why tinkl’s tag line says that they want to help people "pee in peace.”
Currently, tinkl is a very small operation. It is run by its creator and other software developers.
The screen of the pre-existing smartphone app (designed by someone else)
My Role & Collaborations
I worked independently for most of this project, including when I analyzed an early prototype made by the tinkl’s founder, wrote the findings of my research, planned & created the new interactive prototype, and developed documentation for the team of programmers.
I did work with three UX researchers when we collaborated the planning and execution of a contextual inquiry, where we observed the creator of tinkl and another programmer as they performed their daily work. The researchers and I asked them questions and took notes, which I analyzed independently after the session.
Research
Before I joined the project, tinkl’s founder made a video that described their initial prototype, along with ideas on how an admin might perform certain actions. I knew that could be a good starting point for a new design, but I also knew that the sequence of steps deserved to be scrutinized to ensure that new users would be able to learn without experiencing pitfalls.
I combed through each step using the method of contextual inquiry, identifying which steps would make sense to new users and which ones had the potential of causing problems for them.
Futhermore, some problems led to me perform a minor heuristic analysis, such as when I noticed that the early prototype would allow the users to delete important data without the system pausing to ask, “Are you sure?”
After the cognitive walkthrough, I had the chance to observe a team of two programmers as they did their work, asking questions about how they manually (or programmatically) performed the administrative tasks that the new GUI would also be expected to perform. This contextual inquiry, mentioned above, was done in collaboration with three other researchers.
During a contextual inquiry, EJ Makela (left) asks a question of tinkl’s founder, Essie Schlotterbeck (right).
Prototype Plan
Following the research process, I documented the research findings and created a plan for how to approach the prototype.
This included writing user stories for two groups: (1.) Administrators who are leaders on the team, and (2.) General system administrators. I also described some realistic scenarios that would inform the subsequent design process.
User Story #1 : As an administrative leader, I want to have the ability to delegate bathroom-, user-, and feedback-related tasks to other admin team members so that those tasks can be completed more quickly, and I can focus on other kinds of work.
User Story #2 : As a (non-lead) administrator, I want to see the administrative tasks to complete so that I can prioritize and manage my workload effectively.
My Solution
Using my plan as a guide, I created an interactive, high-fidelity prototype in Figma that illustrated to the stakeholders how the new design would work.
This included with written documentation that summarized my work on the project, instructions for accessing the Figma file, and a description of each page of the file. I also created a walk-though video that offered a guided tour of the prototype in action.
Furthermore, because I kept thinking about possible new features for tinkl — features that were out of scope for this particular project — I provided the stakeholder with a detailed list of additional ideas that they may want to consider in the future.
Recommendations
Once the tool is built, I recommend a round of usability testing to ensure that it works as expected or to determine if there are new needs that weren’t foreseen by me or the stakeholder. As tinkl is a new organization that will be bringing on a new team, it may take additional iterations to develop a tool that meets their objective.
Thus, I would recommend designing & implementing small improvements to the interface, followed by more UX testing, and continuously repeating of this pattern until the stakeholders and end users are satisfied with its quality.