GraphQL and Design Clarity (part 2)

In my first article on GraphQL and design, I gave an overview of what GraphQL is and how it could help you in your design process. In this article, I want to share a simple but practical example of how thinking about the schema behind the UI can actually help prevent some implementation problems down the road, and how the schema can be a powerful way of communicating between the UX team, front-end devs, and the back-end API teams.

Along comes a feature…

We recently added polling support to our product. Polls are used during online meetings or webinars to solicit answers from the audience. The basic structure of a poll is one or more questions, each with one or more answers. The answers are usually predefined choices. For example, I might ask:

What is your favorite Star Wars character?

a) Luke Skywalker

b) Han Solo

c) Baby Yoda

This is a pretty straightforward feature. Along with the product team, we identified a few key workflows / Jobs to be done (JTBD):

1. Creating a poll
2. Adding or removing or editing a question to an existing poll. A poll might be allow only a single answer or multiple.
3. Adding or removing or editing an answer to an existing question. A poll might allow the user to write in their own answer.
4. Deleting a poll

Working in Silos