May 20 -22
Week 1 Recap
Important things related:
- Making technology not the divide (not being able to get through the barrier)
- Future of where designers need to be thinking
- What does democratizing technology mean?
Autopsy Summary
After receiving a general overview of the platform and its users from the Chorus team — my teammate and I planned an exercise where we would attempt to use the Chorus platform to build an app for a hypothetical problem.
We chose to create a basic survey that listed the symptoms of cover and depending on user input would direct the user to a hospital if their symptoms were severe. Prior to this activity neither of its had used the Chorus platform and it was not shown to us during orientation.
We began defining our problem based on the following hypotheticals:
Stakeholders
Medical professionals
The community they serve
Why make an app?
People are unsure what the symptoms of COVID are
There is a lot of panic where someone with a small cough or allergies might think they have COVID
In areas with a large amount of cases — they might not need to go to see a doctor unless symptoms are severe (something that determines location ?)
Is an app appropriate?
Depending on factors:
What resources does this medical center have access to?
How many requests are they getting asking if they should be tested?
Can the symptoms of COVID be easily described through a survey?
Does this population has access to smartphones
We kept the the topic high level because we are not health professionals, these were are guesses.
Our intent was not to create a thorough heuristic evaluation — we wanted to get an idea of what a user who was new to the platform would experience.
Upon first impression, the UI appeared clean and uncluttered; however, as we began to build our survey we were overwhelmed with the number of options presented and the programming language or opaque wording of the interface. We defined our problems into three main pain points:
Defining the problem
There is no help with defining the problem, identifying users and stakeholders, or determining whether Chorus is the appropriate solution. Regardless of programming skill, no one can create a successful app if they have not defined the problem an app intends to solve.
Opportunity
Help users understand the scope of their problem and potential solutions by offering common examples templates and giving an overview of necessary components before they begin building
Possible Solutions
* Increase Accessibility with Templates & Tutorials
* Onboarding tutorials to help new users familiarize themselves with the interface
* Suggest certain features or templates based on user goals
Inaccessible Lingo & Word Choices
The platform uses a lot of programming terms that are inaccessible to non-programmers. There are also some terms that may need additional clarification, such as IVR, SMS, and breakpoints.
Opportunity
* Annotate specific terms or add explanations to clarify what different features do
* Replace some words with more accessible or commonly used terms
Possible Solutions
Clarify & Modify Language for Non-expert Users
Rewording vague terms
Adding annotations & descriptions to unexplained features
Confusing Workflow
The workflow for building an app is confusing and unintuitive (Compose, Clients, Mobilize, Celebrate)
How the pages are related to each other are unclear
Opportunity
Reorganize and clarify the main steps of the process
Provide users with a clearer Overview page where they can easily see the flow of their app and how pages relate to one another
Possible Solutions
Highlight Possibilities of Chorus’s Advanced Features
Allow users to take advantage of the elements and features that distinguish Chorus from Squarespace, Qualtrics, SurveyMonkey, etc
— — — — — — — — — — — — -
My Thoughts
As stated above the biggest obstacle for creating a usable app isn’t the technical components — it’s being able to define a problem area and validate solutions.
This is why I feel the two biggest issues facing the platform are helping users define what problem they intend to solve — and helping clarify whether an app is the best method of solving that problem.
Erasing the language barrier between programmers and those with basic technical skill.
“Competitor” Comparison
I reviewed Scratch — a platform developed by MIT to teach programming to children. Julian emphasized how games can be great tools to learn onboarding — especially from his experience with mobile games — because there is a need to keep the user engaged right away.
My overview of Scratch on Mural.
and useful comparisons:
Similarities to Chorus:
- Uses “programming” words and languages but starts simply enough so that users can create without knowing the definitions
- Programming terms are words — not introducing processes (such as if.. then which is not inherently hard to understand but is presented without context)
Concepts that could be beneficial to Chorus:
- Tutorials are offered even when someone immediately clicks on “create”
— Don’t want users to need to look for help
— Starts with the assumption users have not been on this platform previously
- Process was very incremental
— I was not introduced to more complex attributes like extensions until later
- Instead of templates was presented with “inspiration”
— There is not enough to copy another project — you would need to plan what you wanted and look for short tutorials
Concepts that could be improved:
- Presented all options at once, I believe it would benefit from an option that perhaps showed everything but offered an example or tutorial of how the function would be used
Other teammates documented webflow — which similarly has users work to build a website.
Personalized templates — based on what kind of website you are looking for. Key words “reassurance”
“Break the code barrier”
— — — — — — — — — — — — -
My Thoughts
I think there needs to be a balanced between the kid friendly and the technical. Tome is going to be extremely important to this project.
In addition, the difference between template and tutorial. do we want to give users a template which may only need small adjustments? Or use more of a scratch approach wherein small parts are given to the user — they are given inspiration and guidance but ultimately they are learning the tool to create on their own.
During interviews next week it is going to be essential to get into the mindset of users. My most pressing questions are why they wanted an app and what time they were willing to dedicate to learning to build and maintaining their apps.
