A redesigned platform for better public speaking​​​​​​​

We kicked off the project with domain research. We wanted to immerse ourselves in the world of public speaking and become experts on the best practices, scientific literature and tools/competitors already out there. 

Scientific literature backed the promise of the product; by invoking the same fear response, virtual audiences can help treat people’s public speaking anxiety. A music school, for example, was using virtual audiences to prepare musicians for recitals. 

We also dug into Speakeazy's competition. We wanted to not just eliminate usability issues, but also help position Speakeazy's product to succeed in the long run. Their team believed their closest competitor was Toastmasters, but maintained "as far as we know, we're the only ones in this space." My research on Reddit and Quora's public speaking channels revealed that there were actually handful of public speaking simulators already on the market or being tested.

However, the majority of the public speaking apps we found were VR simulators focused mainly on desensitization, and we didn't find any built for desktop. A couple had interesting functionality like slide integration, they lacked built-in recording or feedback mechanisms. We saw these as important differentiators. 

While we were conducting our domain research, we started scheduling interviews with leads our client had given us—a mix of target users and actual clients. 

With our interviews, we wanted to understand how people think about public speaking, how they practice, and any frustrations they had. We typically led by asking “tell me about the last time you had to do some public speaking,” and transitioned into questions about their role, the amount of public speaking they did, and pain points. We also saved some questions about speakeazy concept for the end of the interview.

7 x 45min remote user interviews

While we were interviewing we also did some quick dog food usability testing with the Spekeazy product. We selected three people who were interested in improving their public speaking to test the product. 

We found really serious usability issues. Not only was the platform hard to use, but it was broken. The majority of the times we used it, we couldn’t actually get videos to properly upload and save. Navigation and on-boarding were also lacking. However the concept resonated with people, which was promising. If we could eliminate these usability issues we might actually have a solid product. 

From the affinity diagramming, we were able to start building out our “synthesis deliverables for the next client presentation: competitive analysis, interview findings, problem statement and design principles.

With research complete, we used affinity diagramming and to boil down our interviews, secondary research and usability testing into a set of "nuggets," design principles and a reframed problem statement.

We did this by going through some whiteboarding—doing "requirements definition" and building out a preliminary sitemap. A lot of the requirements came from client feedback, since these are things that were core to the product or within the realm of the technically feasible. The sitemap was challenging because a lot of the screens only came after working out the key flows.

When it came time to ideate, we initially started as broad and crazy as we could. Our team did a series of creative warmups to help us get into the brainstorming mood ("how might we solve world hunger with this coffee mug?"). We then kicked off a series of crazy eight's—where we had 5 minutes to come up with eight separate ideas for features and facets of the platform. The point wasn't so much to nail the final interface, or even specific features, but rather to scratch at ideas that were truly new.

After this inital divergent exploration, we split up to make our own wires.  Although everyone in my group was fairly skilled in Axure, we decided to do paper prototypes in InVision.  

Splitting off to make separate paper prototypes was great in that it allowed us to envision the same product in multiple ways. Because we were working off of the same requirements, the products would have the same core functionality, but because the visual formats and structures would be different, we would be able to get more client feedback.

Before I set off prototyping, I did a little bit of competitive UI analysis. Competitive UI analysis is a great way of not reinventing the wheel when it comes to specific feature sets. A lot of what I and my teammates researched was centered around dashboard design patterns, but the analysis also helped us when breaking the platform into specific features. Broadly speaking, there were really three core components of functionality to our platform: (1) the file hierarchy, (2) video recording and (3) video commenting.

Video recording was the easiest. We were able to look at patterns like Skype and Google Hangouts to see how they had solved these problems. One of the things we wanted to add was some kind of visual signifier that you were recording, while you were recording. We also wanted an elapsed time timer, to show people how long they had been speaking.

The other two pieces of functionality were slightly harder. When it came to the file hierarchy—navigating projects and individual recordings, we knew we needed a way to keep things really clear. Because Speakeazy's corporate clients had all mentioned using Google Drive, we thought it might offer us a nice way of structuring the file hierarchy. Because one of their specific asks was to think about functionality specifically for corporate clients, we thought this might be a familiar pattern.

The other core functionality—video commenting—took a little more research. I think initially we were drawn to youtube's commenting format, where people can add timestamps to refer to specific parts of the video. We also thought about soundcloud's commenting format, where you added comments inline on the timeline.

 

But our research also took us to a video editing collaboration tool, called Wipster. Wipster had a nice interface, and allowed you to add comments to videos by clicking on the video, as it was playing. Then, when you returned to replay the video, it would cycle through the comments in a right hand column, as they appeared. In some way, this way of feeding comments back to you in realtime reminded me of a Periscope recording.

Looking out of category allowed us to really iron out the key elements of our design. We were going to borrow the file hierarchy and structural format from Google—with folders for projects and video recordings. We were also going to borrow video recording patterns from apps like Quicktime, Skype and Google Hangouts. And finally, we were going to implement a video commenting style similar to the Wipster interface, where comments were added inline, in realtime.

Having the general feature sets scaffolded out really helped us when it came time to wireframe. We were going to work in paper, so I actually started drawing out some exploratory wireframes on paper. The goal here was not so much to capture the final flow, but to explore different variations of key screens to get a sense of what patterns might work best. That way, when it came time to assemble the more refined paper prototype, I would be able to pick and choose from the best ones, and make any minor edits that I needed to make in the process.

All in all, I was able to build out a 25-screen paper prototype in Invision. I stuctured the prototype into a series of key screens and modals, laying different variations of screens and securing them in place with masking tape. In the future I'd like to figure out a system that uses less sharpie marker (I had headaches at the end) and less masking tape. I've thought about having a clear overlay to get everthing to lie flat. Anyways, below you can see three key screens in the paper prototype:

Because I and my teammates were each developing different prototypes, we ended up with three very different paper prototypes that we could test. Each of us really chose to focus on separate features. In mine, for example, I wanted to use a product demo on the homepage to serve the dual need ot enticing new customers, and onboarding existing ones when they went to sign up for the service. It allowed you to test out two features: the "Magic Hat" feature, and the video recording functionality.

 

My teammates (who were responsible for prototypes #2 and #3 developed other aspects of the platform. Caity, for example, used a dashboard to provide sort of big data feedback on a range of different speaking quality metrics (like eye contact, tone, body language and conttent). Thomas, on the other hand, focused on developing a platform with excellent video feedback and commenting.

When we did user testing, we had pretty good feedback from the people who used it. They loved the magic hat feature, and could navigate between core features much better than the previous prototype. But the core problem was one we hadn't managed to solve from our initial user testing of the existing platform: people still didn't know what groups were—which was a core and important feature of the platform. We started to question whether "groups" were best for the mental model

The client also had feedback for us. They loved the prototypes, but they wanted us to limit our final medium-fidelity prototype to features that they felt were core—or actually implementable. They didn't envision the platform having deep learning functionality, so the kind of hyper-granular feedback on things like eye contact, posture and tone didn't make the cut.

The process of going from paper prototype to medium-fidelity wireframes was basically us taking the successful components of each platform, and combining them into something we felt was cohesive. One of the drawbacks of our approach (which was to “divide and conquer” the flows) was that our wireframes had fairly visually different stylings, and that Caity was stuck with defining the main dashboard, which was easily the most complex screen. We also had trouble coordinating on things like the size of the grid we were using, but eventually it all came together. The only key change we made was opting for the shared folder model from Google Drive, rather than SpeakEazy's "Groups" model.

Nevertheless, we were able to come together with a fairly cohesive medium fidelity prototype making the screens in Sketch. When we presented it to the client, they were happy with it.  Our final step was to annotate it, and package it all up into pdfs. This was pretty straightforward, it just took a lot of time to capture the detail. Below are some of the key screens:

Because the DESIGNATION team behind us was actually responsible for creating the visual interface, it was important that we leave them good work. We later got excellent feedback on our annotated wireframes

The czar manages all of the materials for a given presentation. In any group, there should be one teammated responsible for all of the key materials for a presentation, and getting all of the styling to line up. Divide and conquer only works so well for certain scenarios (our wireframes, similarly, could have benefitted from uniform styling).

It won’t necessarily revolutionize your product, in terms of features, but it’s a foolproof way to uncover any glaring usability issues. We learned so much just running throught the key flow with three of our classmates.