Overview An Android application to help presenters prepare for presentations/pitches by recording & outputting a variety of metrics through voice analysis.
Team + Role
The team of 6 was made up of 1 PM, 4 Devs and 1 designer. I was the designer responsible for
background research, creating UX flows and UI design of our app.
Timeline
February 2019 - May 2019
Tools
Figma, InVision, Photoshop, Illustrator
The other co-op’s and I put together a blog post that tells you more about our
experience at Connected!
Problem It takes a very long time to identify technical oral errors while practicing for a presentation (e.g. videotaping a runthrough & rewatching is heavily reliant on your own ability to find errors)
Goal To reduce the review time after a presentation / pitch runthrough
Primary Users Connected employees who practice individual presentations / pitches on a regular basis (e.g. PMs)
What They Currently Use
I looked into 3 primary tools/methods PMs and other employees at Connected use to practice.
We decided to focus on improving the experience for users who use voice recording mobile applications.
Major Pain Point for Users Using Voice Recorder
Difficult to analyze multiple aspects in one review of a recording (e.g. analyzing tone + number of fillers while
listening to the playback). It then takes multiple reviews of recordings to identify all their critiques.
What do our users look for in these playbacks
“Sometimes I say ‘um’ or ‘like’ so when I tell myself to cut back, I try to keep track of the number of times I say them
whenever I can. Plus, it can also tell me which parts of the presentation I’m less comfortable with.”
“I always ask myself ‘How many times do I pause and where?’ Unintentionally, I’ll pause if my mind blanks or if I’m using a deck at the same time”
“Since I get nervous at times, I want to make sure I'm not speaking too quickly."
While we had 3 months, we all had our own company projects to work on so we set benchmarks to keep us motivated throughout the term. These would also help guide and track our personal learnings.
Goal #1 / Provide technical feedback on the users’ presentation Implement at least 3 metrics to allow users to determine how they feel they did from a technical standpoint
Goal #2 / Reduce the review time after a presentation / pitch runthrough User reads metric information and listens to the playback less than 2 times
Goal #3 / Learn a new language + API Implementation Our tech stack was Android Studio so learning goals included learning Kotlin as well as how to integrate APIs.
To ensure the visual design of the application was visually consistent, I established a fixed set of type and colours. At the time, spacing had not been on our minds but is definitely something to revisit in the future.
Here were the main features of our final product - an Android application tailored to meet your presentation practice needs!
New Recording The objective behind designing the flow of a new recording was to keep it as similar as possible to voice memos and other voice recording applications. From research, the majority of recording applications follow the same process of starting the recording, pausing, ending and then naming/saving.
By using this same process, we target the principle of recall over recognition, meaning the users will not need to learn anything new to use our app.
Results This feature hits the major pain point of reviewing being time consuming and our goal of using 3 metrics to allow users to determine how they felt about their presentation, from a technical standpoint
The feedback in the form of metrics that were developed include...
Playback options, recording length and transcript viewing are also available. During preference testing, we noticed the 'Below Average' grade was ambiguous. This led us to create a metrics screen, which outlines the criteria for our metrics.
Past Recordings / History Past Recordings are found under a separate tab with date and name information, which are the key details interviewees wanted to see to help them differentiate between recordings.
Some applications like voice memos combine the new recording page with past recordings but we chose to separate them to reduce the amount of information users see. The assumption made was if the user is starting a new recording, they will not look at past recordings.
Not everything works out the first time and Project Voice was no different. Each final screen was not achieved on the first try and many designs were created leading up to them. Although the application is not very complex with only 2 major task flows, the designs needed to be simple in a way that would not confuse the end users, which meant constantly trying new designs and asking for feedback.
Recording Screens The layout was important because we wanted to limit the cognitive load as much as possible.
We conducted preference tests and after using those results and discussing accessibility considerations, we settled with option #3.
Pause Screen The pause screen was one of the tougher UI design choices because we found it difficult to communicate that the user has the option to pause & unpause in addition to being able to save or discard the recording.
While these considerations may seem small, the size of the buttons, words vs. icons, colours - all of these play a part in reducing confusion for the user. Should the icons be filled or outlined? Maybe. Do the usears need words accompanied by an icon? Yes! Hence, Option #1 was used!
We may not have finished making the full-fledge application by the end of our term but we all learned from one another and took away valuable soft and hard skills alike. Here are just a few of the outcomes I contributed to:
User Testing Plan We did not have time to test before our work term ended but I had the thought of "what if we could?" I then worked with a UX design researcher at Connected, where she helped me create a user testing plan. Unfortunately, the plan itself cannot be shared due to branding regulations, but I'd love to talk about t!
Prototype + Pitch Check out our Invision prototype, which will walk you through the app. We also pitched our POC to the company and our co-op managers!
Half-Developed Prototype Development is still in progress, with 1 metric implemented.
Learnings This project was many of my firsts - my first time taking on a design role in a long-term team project, my first time creating user flows, my first co-op term, etc. It was a wonderful learning experience and I was able to take away invaluable skills.
Next Steps The next steps for this project include completing the development of the application, implementing more creative features & metrics into the application & conducting user testing. I hope to one day hold a user testing session!
BiteCheck
Midnight Sun Website
Chromaz
