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 details of those archetypes:
We’ve found that talking about our product internally via archetypes drastically speeds up cross-functional collaboration with various teams and stakeholders.
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.
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.
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.
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.
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.
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.
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.
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.
Designers select an appropriate design process based on the size and type of the problem they need to solve.
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.
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?”.
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?
While design’s output is multi-faceted, we generally deliver in two ways:
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.
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.
Most processes, templates and docs are found at poll4.com/design-links