Quira: quests you can read at a glance

Quira: quests you can read at a glance

At a glance

Quira paid developers to fix GitHub issues and to build with open-source tools. Companies ran these quests from a dashboard that had grown one feature at a time. I redesigned four parts of it, so a maintainer could see who was working on what, and what it cost, without opening every issue: zero clicks instead of one per issue.

Role & team

Product designer, working with one developer and one stakeholder. From the stakeholder’s audit to handoff.

Timeline

6 months in 2025. Quira closed in September 2025.

The old way: every quest looked the same

The old way: every quest looked the same

The old org page was a long list of issues. Each row showed a title, a repo, a reward and two small counters, and nothing else. A quest with three solvers fighting over it looked exactly like one nobody had touched. The public org page had the same problem: a row of stats, then cards that all carried the same weight.


Users had made the problem clear before I joined, and the stakeholder had already audited the product. The cost was time: to find out what was happening, a maintainer had to open each issue, one by one.

Before

After

Before / After. On the left every row looks the same; on the right, status and activity show which quests need attention.

The brief: same data, less digging

The data already existed: participants, submissions, rewards and dates. Nothing new had to be tracked. The job was to decide what a maintainer needs first, and keep the rest one click away. It also had to work for two kinds of quest: Solver Quests end in a pull request, and Creator Quests end in a blog post, a video or a demo.

Q1

What does a maintainer need to see before opening a quest?

Q2

How does one page show a pull request and a YouTube video side by side?

Q3

What makes a developer decide a company’s quest is worth their time?

The work: what I designed and why

The work: what I designed and why

I redesigned four parts of the product: the org dashboard, the quest detail page, the public org page and the mobile view. Before designing, I held two sessions with the developer and the stakeholder to discuss the ideas I shared.

A table instead of a list

I turned the quest list into a table: the issue, what’s stashed, its status and its activity. I considered keeping the cards and adding status badges, but a table let you compare quests down a column. Status says what happens next, like “Expecting PR”, and how long it has waited. For the company’s numbers in the header, I tried three layouts before settling on a two-by-two grid.

One row per person on a quest

Opening a quest shows everyone on it: the participant, their relationship to the repo, a status chip and their submissions. “5x Contributor” means little on its own, so a hover chip explains it.

An icon for every kind of submission

A Creator Quest can end in a YouTube video, a Medium post or a GitHub repo. I gave each source its own small icon instead of a generic link, so a column of links became something you can scan in a second.

A public page you can judge in seconds

The public org page is where developers decide if a quest is worth their time. I gave the four key stats equal weight in one row, added tags and a clear open or closed state to quest cards, and rewrote the activity feed in plain words.

Creator Quests

Before

After

Before / After. Creator Quests moved from stacked cards to a table, so check-ins, submissions and reward line up across every quest.

Solver Quests

Before

After · user view

After · company view

Before / After. Each Solver Quest row now shows its status and how long it has waited, so the quests that need attention stand out, in both the user and the company view. Mockup with placeholder content.

Quest detail

Before

After

Before / After. Brand logos and stacked labels became small submission icons and one relationship chip, so each row reads in a second. Mockup with placeholder content.

Public org page

Before

After

Before / After. The four stats get equal weight, and the org details move into one tidy card. Mockup with placeholder content.

Mobile: three columns, the rest one tap away

Mobile: three columns, the rest one tap away

On mobile the quest table drops to three columns: participant, status and submissions. Status becomes an icon, since a word wouldn’t fit. I marked the new pieces, like submission icons and relationship chips, to move into the design system.


Color is never the only signal. The old dashboard showed a quest’s state with a small colored circle and light grey text. The new table writes status out in words, and on mobile each status keeps its own shape: a check for done, an alert for waiting. One thing I’d still fix: the green and orange status text is too light on its chip to pass contrast.

Mobile. Three columns, the rest one tap away. Mockup with placeholder content.

What changed: one screen instead of every issue

What changed: one screen instead of every issue

0

0

clicks to see who’s on a quest and what they sent in. Before, a maintainer opened every issue

clicks to see who’s on a quest and what they sent in. Before, a maintainer opened every issue

2

2

quest types, Solver and Creator, handled by one layout

quest types, Solver and Creator, handled by one layout

Looking back: good dashboards, short runway

Looking back: good dashboards, short runway

Quira was built around quests: companies paying developers to fix issues and build with their tools. As AI coding tools took off, that model stopped making sense, and Quira shut down in September 2025. The redesign never got the chance to be measured.


If I did it again, I’d test the status wording with two or three maintainers before polishing the table. Labels like “Expecting PR” made sense to us, but I never checked them with the people reading them.


The submission icons are the piece I’d keep. They are the clearest example of the whole project: same data, less digging.

Home

Next

Home

Next