Poll Everywhere is a live-polling SaaS company, serving 75% of the Fortune 1,000.
Here’s how it works: Presenters add live polls to their slide deck and audience members respond on their mobile device. The chart updates live, in real-time, in the presentation.
Our job is to provide value for Presenters, which usually means increased confidence while presenting, higher audience engagement, and better knowledge retention.
Our problem statement
Poll Everywhere relies heavily on the skill and foresight of the Presenter to entice audience participation. This is unreliable.
I framed the problem as job stories, across 3 of our existing 5 Archetypes, to be validated.
When I’m building a presentation;
I want to introduce moments of high-engagement;
So that the audience can better retain key concepts.
When I seek feedback in a vulnerable state,
When I choose to engage by responding to polls
give me a reason to participate
Inside every human being is a desire for mastery and a need to belong. Presenters can leverage this better if they have the ability to present gamified polls, perceiving a lift in audience engagement.
More Participants becoming Presenters after experiencing a Competition (also the KPI)
Increase Presenter 2nd month usage, tracked as monthly-active-users
Adoption, signaled by third consecutive re-use
Multiple-choice polls within a Competition receive more responses
Observed intent to use a Competition in the near future with a real audience
💎 High-level constraints
Competitions should only work from the web at first, and only in our native apps once validated.
Creating a competition should use the same components and creation flow as any other poll.
Competition questions should provide the same amount of time to answer, regardless of length.
⚗️ 1. Generative research
Our internal ad-hoc User Research team interviewed 15 customers and compiled a list of assumptions and how-might-we’s. This formed the foundation of our design work and refined our job stories.
Key insights (Chili’s, ties, formative assesment)
🍱 2. Design banquet
I facilitated a 6 hour Design Banquet, based on the double-diamond design framework. The Banquet included stakeholders, designers, subject-matter experts, the product manager, one founder, and developers.
The output from the Design Banquet included detailed sketches of high-value areas, describing the flow for creating, presenting and participating in a competition.
📈 3. Evaluative research
We scheduled 18 remote customer interview sessions across 5 weeks. The goal of these sessions is to evaluate if our customers could imagine themselves presenting a competition, thus justifying development. I facilitated each session.
I encouraged one of the two designers on the project to build a clickable InVision prototype, that we would manually advance over a video call.
This gave customers a chance to react to a product that appeared to be real.
We discussed our observations after each session and incorporated it into the prototype for the following session.
✅ 4. Validation
As soon as Engineers produced a working version of Competitions, we retired the InVision prototype and switched over to the real thing, this time letting the user drive. This allowed us to observe friction, ease-of-use, and time-on-task, as well as adding character to our job stories.
“ Competitions got a resounding response, echoing in the room and over the next few days how amazing it was. I had people say, “OMG” and give me high fives.
As part of our validation model, we asked each customer if they could imagine themselves presenting a Competition.
The majority of what’s shown below was crafted by the heavy-hitters on my team, not by me.
Creating and configuring a Competition
Create the Competition
Configure the Competition
Presenting a Competition
Participating in a Competition
Basic response flow
The final Leaderboard for Participants
Timer, click to advance, filmstrip, which controls are nice-to-have vs MVP
📦 Iterating through bi-weekly releases
Our Product Manager empowered the Engineers to ship bi-weekly releases across 4 months. Each release included improvements directly based on customer feedback, and many bug fixes.
GA rollout 1/9/90
🎁 What I learned
Maintain relationships with test participants
The people that give early feedback on rough prototypes end up being the best advocates, and are deeply engaged with the product.
Hire designers with strong soft skills
I made a bad hiring decision for my team, which resulted in added risk to the project. I gave too much weight to hard skills and not enough credence to soft skills, particularly communication.