Millions of people from around the world take out their phones and respond to Poll Everywhere activities each day. It’s essential that our live visualizations are both accessible and comprehensible to diverse audiences so they can quickly give feedback to the person presenting. That’s our “magic moment” interaction that initially draws people into Poll Everywhere. As you’d expect, there are many more types of interactions design must consider. We talk about those interactions through the lens of archetypes.


With archetypes, we explore the best way to solve our users’ problems. We have five primary archetypes:

The five primary Poll Everywhere archetypes

The details of those archetypes:

  • Presenter – Communicates in a vulnerable state in front of their peers, shares new ideas, and requests feedback. Presenting is one of the most nerve wracking activities people engage in during their professional careers; it’s our job to design that stress out of our application and make it reassuring.
  • Participant – The audience. These are the people who are giving feedback to the presenter, live, during a presentation. A Participant could a student in an education setting or an HR professional at a conference.
  • Creator – Crafts content and selects the optimal activity-type. It could be something as simple as a true/false question or something as complex as creating a 10 question trivia competition and distributing it to 20 Presenters.
  • Event producer – Works with a team of people, backstage, supporting the presenter. For very large events, there’s usually a person backstage that works with the audio visual team that’s dedicated to Poll Everywhere.
  • Account administrator – In larger organizations, these are the people who support Creators and Presenters by managing billing, user provisioning, and privileges.

We’ve found that talking about our product internally via archetypes drastically speeds up cross-functional collaboration with various teams and stakeholders.

Design system

We don’t believe design should be a priesthood or a silo; it should be accessible to anybody who needs to communicate how our product or company should look and work. Conversely, we’re also not saying everybody should be a great designer, that’s the design team’s job. Our belief is simply that everybody should be able to participate in design.


Because of our belief that design should be inclusive, we’ve invested heavily in an atomic design system that starts with Sketch. We call it Whisk.

Design system is implemented in Sketch

Product managers, designers, and engineers that work on UI or UX are all expected to know Sketch because it’s where our extensive library of design tokens, elements, components, and page layouts lives. This makes it possible to very quickly and cheaply put together a mock-up or clickable prototype that conveys an idea. Showing something is much better than talking about something.

Brand website

The Whisk design system alone isn’t enough; we also have an internal brand website that documents almost everything a Poll Evian needs to know to properly incorporate our brand values and aesthetics into their projects.

The internal Poll Everywhere brand website helps enforce consistency in design

Everybody from our engineers to marketing & sales consumes it for their work. It’s expected that design works from within these guidelines, and changes the guidelines if they find the brand constraint’s are not working. What we don’t want is to change the brand without updating the brand website.


Toolkit is where design meets front end engineering. When a component is pretty well baked in Sketch, the front end engineering team implements it in toolkit as an element or component. How do we get an idea through Whisk and to production?

First, designers should look in Toolkit and Whisk to see if a component already exists that solves the problem. If design can’t find a preexisting component, they’d implement it in Sketch.

A component implemented in Sketch

Design would then run through user testing to validate or invalidate as much as they can before it gets implemented. When the validation work is complete, a front end engineer works with a designer to implement the design as a component in toolkit in a web browser.

A component implemented in Toolkit

This step makes it possible for the design and front end engineer to actually see what the design looks like in a real web browser. Adjustments may need to be made to the component because of technical constraints, which the designer would reflect in Sketch.

When everything looks and feels good, the components are pushed out to production into their various contexts.

A component in production

That’s when the rubber hits the road and we get real feedback from actual users.


Product design collaborates closely with the product management and engineering team in tight iterations on small, highly functioning feature teams. The faster we can get something in front of our users to validate or invalidate a design, the better. That might take the form of a mock-up created by design or a working prototype put together by an engineer, we don’t really care, what’s important to us is that we’re always shipping and always validating.

Visual designers work with marketing to craft messages and visuals that help us communicate and connect with our customers. The same rules apply; the faster we can get a design in front of real people and validate or invalidate it, the better.

Design system first

All design is expected to start from within our design system; the default must be to try to make something work with our existing design system before creating something completely new. If given the choice of validating the “90% perfect” solution that we can quickly build with off-the-shelf components vs a “100% perfect - build it from scratch” option, we’d go with 90% perfect and finish up the remaining 10% after we’ve validated it with real people.

If the design system doesn’t have a solution to the problem, then we’d go through the hard work of creating, validating, iterating, and shipping a new solution. Once that work is complete, we’d incorporate that back into the design system for reuse.

Process selection

Designers select an appropriate design process based on the size and type of the problem they need to solve.

Different processes are chosen to work on different types of projects

For small design problems, like a quick user interface fix, less process is needed to get the job done. A designer might sit by an engineer, point at the problem, and fix it in a few minutes.

For very large design problems, like building a completely new feature or interaction, a larger process is needed that deals with the increase in complexity that includes more time for exploration, “going wide”, validating or invalidating potential solutions, and narrowing in on something that the product team can use to get started on implementation.

On project epic teams, we embed product designers in engineering teams to maintain tight feedback loops and improve our iteration velocity.

Checklist driven design reviews

All of our designs go through a design review checklist that looks at criteria ranging from “did we utilize our design system to its fullest extent” to “how accessible is this design?”.

Design checklist template

While the checklist might look like a lot, we’ve found in practice that it keeps design reviews with stakeholders much more objective and minimizes personal opinions. Once a team runs through the checklist a few times, they’re able to get through them in 10 minutes and walk out of the room feeling good with very productive feedback.


What’s a day or week like as a designer at Poll Everywhere?


  • Design stand-up - Designers talk through what they accomplished yesterday, plan to complete, and expose any blockers.
  • Project team stand-up - For designers embedded on a project, they may attend that team’s stand-up to sync up on project issues and work that needs to get done.


  • Talking to users - Designers work with product, marketing and sales to identify users who can give us feedback. Typically, we facilitate four research sessions with real customers, every week.
  • Design ops meeting - This is where engineering, product managers, and designers meet to go over what we should add or remove from our Sketch design system libraries. For people who are new to Sketch or the design system, we teach them what they need to know to be dangerous.
  • Prioritization - On Monday afternoons, designers, product managers and stakeholders sit down for 30 minutes and ensure we’re executing on the most important problems
  • Design critique - On Thursday afternoons, designers bring one or two items for feedback from the team
  • Customer Support hours - Everyone at Poll Everywhere spends one hour answering calls or responding to tickets


  • Inclusive design activities - These help us unbox new problems with diverse teams.
  • Design outing - Design related cross-functional field trip, mostly for fun and bonding.

As needed

  • Design review - Stakeholders, designers and engineers review what’s going out into production. We run through a checklist that makes sure we didn’t miss anything.
  • User testing and validation - Designers, developers and stakeholders execute tests based on a template, then document and socialize the results. We call these templates Recipes, which are collected in our user testing Cookbook.
  • Design checklist for QA and accessibility - Core team and stakeholders score a list of usability and brand heuristics.
  • Messaging for 1/9/90% releases - Designers and copywriters craft reassuring copy when new features are released.
  • Experiments - Designers work closely with Growth to launch validate hypotheses in production.


While design’s output is multi-faceted, we generally deliver in two ways:

Epic work

For product and epic-related work, provide a clickable prototype in InVision including all states. Include an InVision Inspect link with all new and existing components clearly labeled. Use InVision’s built-in Workflow feature to indicate the state and fidelity of each screen.

Components and elements for Whisk & Toolkit

When providing new elements and components for our design system, include the new symbols in our Sketch design system, Whisk. Be sure to check in with a front-end developer as the reviewer to make sure there’s no technical constraints and make them aware of the new asset.


Various tools and documents we use to get the job done.

Internal links

Most processes, templates and docs are found at

Design tools


Sound like a team you want to join? We're hiring!

Be a designer in small, highly talented product teams that work on big problems to change the way the world thinks about presentations.

Apply now