Erasing the Distance is a non-profit arts organization based in Chicago that uses the power of performance to disarm stigma, spark dialogue, educate, and promote healing surrounding issues of mental health. Stories are collected from people impacted by mental health issues, then are shaped into monologues and performed for a live audience.
The ask is "How can we simplfy the organization of material needed to produce a touring play?"
Started Feb 2016
Ongoing
My Role: Business lead and presented a tutorial on relational database basics to client and one team member.
Other team member roles: UX Designer and Technical Developer
Client: Scott Letscher, Erasing the Distance (ETD) is not for profit that brings mental illness awareness to the public through story telling.
Following the Service Desgin weekend Jam we continued working as a team to create a database solution to organize some of their data.
Outcome:
Database schema and wireframes have been created. Currently searching for a developer to implement.
Process and Personas
After looking at various points of the business, we decided to focus on the monologues/plays that were part of the touring programs as this was the main source of income. Our team created a database solution to organize the data.
The diagram outlines the entire process for getting plays for into production. It consists of capturing the story from the protagonist, scribing out the story, and then creating a play. Before a play can be performed publicly, ETD has another process that needs to be followed which includes: locate and book the actors, prepare facilitation guides and possibly find a venue. After play is performed there may be a post play follow up process as well.
After outlining the process, we created personas of ETD staff that would be using the database.
Database Fields
Currently data is not stored consistently across ETD; data is saved on different hard drives of the company and some in human memory. The format can also differ for the same type of data (ex. spreadsheet vs text file or MPEG vs QuickTime format). Our client contact Scott, started us with what important fields are currently captured and what other fields would be nice to have. By talking through the fields we were able to spec out a database schema.
Database Screens
Using the database as an anchor point several screens were designed. There were screens needed to input the story data, which linked to the performer. There is a performance table to keep past performances from a historical perspective. There are also a screens created that enable ETD to search by story or performers based on certain criteria.
