During one of our late night calls, Christina and I were discussing this viral video on competitive programming. It is a mind sport where contestants write computer programs to solve various puzzles. Judging is based on correctness and time spent, but also other factors like quality of code, memory usage, etc.
We wondered what the equivalent was for designers. How do you determine who's a better designer? By how well they round their rectangles, or speedrun through a design with Figma shortcuts?
We continued to entertain the absurdity of this idea, brainstorming ideas and quickly landed on a vision that we wanted to realize.
And so begins the era of competitive designing...
We began by bouncing ideas off each other to determine the most amusing way to test a designer's skills:
We felt that these ideas were too one-dimensional, both in capturing the abilities of a designer and in gameplay, and would get stale quickly. Also, they're not geared for the competitive, multiplayer experience that we originally sought after.
We wanted something more comprehensive, something that involved other players, and above all, fun.
Eventually, we thought of a game that tests a player's ability to break down designs and identify key elements of it:
Given a random user interface or website design, you have X amount of minutes to memorize it, and Y amount of minutes to replicate it in Figma. Using image similarity programs, whoever's design matches the original's the closest wins.
This format felt like the right one to us for the following reasons:
We went on to formalize the flow of the game and its various states like so:
With this, Christina and I began working together on the design of the plugin, and I started the development side of things, with HTML, CSS, TypeScript and Figma's plugin API docs.
Figma plugins are typically around 300px by 200px in size, so we had to design with this small space in mind, keeping complexity to a minimum while surfacing the most important controls.
We looked at how other plugins made use of this constrained space to fit complex controls, menu items, and more:
Like many of the examples above, we decided to lean on progressive disclosure to inform our design decisions, asking ourselves the following:
The most important information and controls we identified were the number of players, memorization and playing time, as well as a link to an Are.na channel of reference images.
With this hierarchy of information fleshed out, we went on to create basic wireframes to iterate upon, focusing on the layout first:
To add more graphic elements to the UI, I honed in on player selection. Drawing inspiration from character selection screens in video games, I mocked up the following:
The characters are from Evangelion, which is a callback to the thumbnail of the competitive programming YouTube video that kickstarted this project.
From here, we began to iterate on the rest of the plugin's design, making sure to account for secondary buttons and any alerts / messages that might pop up.
For secondary controls and info (like instructions or source code), we decided to hide them behind a menu, since they're less frequently accessed, or set once and forgotten.
With the foundations of the plugin design itself set, our attention shifted to the playing area, i.e. the Figma canvas, where most of the action would happen.
Early on in our ideation phase, Christina and I ran a simple round of competitive designing, even before we came up with the idea for a plugin. We simply copy-pasted the reference images, created two blank canvases, and ran a Figma timer plugin to time ourselves while we memorized and replicated the reference.
It was pretty crude, but we felt that the simplicity of this layout made sense. It worked well with Figma's infinite canvas, and reminded us of the format of table top games, where each player is given their own playing area.
So we decided to continue exploring it, and I expanded on the concept by giving each player a designated template that the plugin automatically creates, based on the number of players. Each template contains:
I also suggested including a header on the board that prefaces how much time players will have to memorize and replicate the reference image, so that everyone is on the same page.
Because of the quick gameplay loop of memorizing and replicating, reducing the time between the game ending and beginning was key. Any clean up or resetting of the board should be handled automatically, to reduce friction.
To that end, I designed and implemented the following features:
At the end of every round, instead of having to manually save everyone's work, the plugin automatically saves a copy of the playing area to a new page with the current date.
With automatic archiving in place, the plugin can also safely reset the playing area when the round begins, so players can get right back into the game.
Like a real board game, players should be able to have control over their playing area. In this case, it means being able to move the templates around the canvas and customizing the name labels.
After each round, or whenever the board is reset, the plugin preserves this layout and player names, so there's no need to configure the board each time.
In the event that the game state is messed up (e.g. when a template is accidentally deleted), there is a way to quickly hard reset the game board to a default state.
Finally, the templates are aware of the color of the canvas and will adapt to it, turning either white or black for better visibility.
As I wrapped up development for this first phase, I came across the Figma widget API and realized that it would be a much better fit for this project than the plugins API.
Unlike plugins that can only be run and controlled by a single person, widgets can be displayed on the canvas for other users to see and control:
This means that everyone can be involved in the game-setting process; there won't be a need for a single gamemaster to setup or reset the game. So the next version of this project would likely be a Figma widget instead of a plugin.
I would also love to explore using more unorthodox UI elements often seen in video games, like Persona 5 or Animal Crossing. They play a big part in making the game fun to navigate, as well as grounding its visual identity.
As is the case with Are:na, this project has been put on hold as Christina and I return to our regularly scheduled programming of school (me) and work (her). But we plan to revisit this once the less hectic seasons of our lives roll around.
Until then, keep on polishing your design skills, because you'll never know when someone will challenge you to a round of competitive designing 👀