GLKB Dev Experience

Shipping the questions with the answers.

Company

GLKB · Jie Liu Lab, University of Michigan

My Role

UX/UI Designer

Tools

Figma · Claude Code · Markdown

Timeline

May – Aug 2026

Description

GLKB is an AI-powered research engine that synthesizes biomedical literature into answers grounded in real publications, which provides a public agent API. Its developer surface was my first project there and my last: the documentation in the first week, the dashboard at the end of the summer.

Context

I was handed a 21-page document and told to turn it into API documentation. I kept its argument on the front page and built the half it did not have around it: endpoints, parameters, response fields, and more. The documentation is deployed to a protected dev site and held there until a developer has reviewed it in full. The dashboard is live on glkb.org, behind sign-in.

Shipping a developer site with its unanswered questions written into the code

I designed the developer surface end to end: the competitive research behind it, the information architecture, the page content and the interface. The PM set the brief and carried it between me and the agent team, who own the API. A front-end developer built the site.

An API, a console for keys, and nothing to read

GLKB’s interface is built for a researcher asking a question. The API is for the opposite person: someone who will never open the web interface, and who wants to push 5,000 genes through it from a script. That person had a working endpoint, a screen for generating keys, and nothing to read.

Three things made the writing harder than writing it well:

Nothing in-house to match. No documentation existed for any other part of the platform: no house structure, no house voice, no precedent.
Engineering’s own questions were open, and the documentation could not wait for them.
No reader to ask. The API had users inside the team and none outside it; I asked to speak to a developer using it and was pointed at the team’s own.

Headed with the brief as a quotation: “Go design the third tab.” Beneath it, the GLKB API console as it stood: a left rail of icons, a page headed API, and three tabs reading API Keys, Usage and API Docs, with API Keys open. A line reads Manage authentication keys for GLKB API access, beside a count of 3 keys · 2 active and a Create new secret key button. A table lists a Production Key, a Development Key and a Testing Key with their masked key strings, created dates, last-used times, a status of Active, Active and Inactive, and Revoke, Enable and Delete actions. A security notice sits beneath, warning never to expose API keys in client-side code or public repos. Below that the screen is empty for roughly half its height.

I dismissed it as not documentation, and it was half of one

I asked what I was building from and got a 21-page document. My first read was that it was not documentation: “sure there’s some good content, but this thing does not read like API doc really.” No authentication section, no parameter table, no response schema, and the address of the API is a placeholder in every code sample it contains, including the one headed “try it in sixty seconds.”

So I read Anthropic’s and OpenAI’s developer documentation, not for a structure to copy but for the shape of the thing. My first judgement was wrong. The document was one entire half of documentation and none of the other: all persuasion, no reference. Five of the 12 pages that shipped carry its section titles.

A map from the 21-page source document to the 12-page documentation set that shipped, banded by what happened to each part. Six of the document’s 11 sections were reworked into the five pages of Get Started and Core Concepts. Five were kept one to one as the Use Cases group, drawn as five connectors. The two API Reference pages, Batch Endpoint and Health Check, have nothing beside them: they came from nothing in the document.

The word was “tab” and we meant different things by it

On the same day, I was told the documentation went under the third tab. The screen already had a sidebar down the left and tabs across the main content, so a 12-page reference under one of those meant a third level of navigation: a sidebar inside a tab inside a sidebar. I asked the PM to confirm. She confirmed. So I built it there.

I laid the whole document out at product width inside that panel. Two days. Then it came back. “Why are these under the tab?” She had never meant the documentation should live in the tab. She meant the tab should be a button linked to a site of its own. We had wanted the same thing the whole time.

Headed: What I built under the tab, and what shipped instead. Two screenshots side by side at the same height, each captioned beneath. Captioned under the tab, on the left: the source document laid out inside the product’s API Doc tab, a narrow text column headed Large-Scale Literature Exploration with the GLKB Agent API, with Scale and Reliability cards inside it and a third navigation rail of section links crammed against its right edge, and no search anywhere on the screen. Captioned on its own site, on the right: the same material deployed as GLKB API Docs, full width with its own header, a sidebar carrying a Search anything field above all four groups, and an overview page holding a blue GLKB API hero card with Get Started and Get API Key buttons, a panel of knowledge-base statistics reading 263M+ biomedical terms and 14.6M+ relationships, four Why GLKB cards, and a What you can build table with columns for workflow, what you send and what you get back.

So I argued that it should not be a tab at all. The finished set is 12 pages and 1,067 lines, and a panel cannot hold a persistent sidebar, a search field, an on-page table of contents and 12 long-form pages carrying parameter tables and copyable code. A tab is a place. This needed a door.

That went on hold, and the tab stayed, which left it still needing something underneath. I drew three options and we took the one that looked right and asked least of the dev team, as the answer for now.

Three designs for what could sit under the API Doc tab, drawn at the same size. On the left, the link on its own as a single card in an otherwise empty panel. In the middle, framed and labeled as the one that was taken, the same link with the external site previewed in a browser window beneath it. On the right, a condensed reference kept inside the product: an authentication and endpoint block, a parameter table, and a quickstart carrying a link out to the full documentation.

At the end of the summer I got the screen back

By then I had rebuilt the design system, and the brief was the user experience of every page in the product. The API screen still had its three tabs: the third carried the stopgap, and the other two showed the same table keyed on the same items, differing only in a few columns.

I proposed no tabs at all: one screen, everything on the surface, and the way out to the documentation as a button sitting on it. It was agreed within a day. So the tab became a button.

A close detail of the rebuilt API screen, enlarged as a preview: a button reading API Docs, the Connect key and Create key controls beside each other, and the head of a usage table with columns for request, token and cost above an empty row.

The Outcome: Something to Read, and Somewhere to Watch It Run

12 pages in four groups on a site of its own, and the console rebuilt into a single screen.

The top of one page of the shipped documentation site: the Use Case Gallery, subtitled 12 more workflows, one batch endpoint, with the line that each entry is a complete use case — audience, what you send, and a prompt sketch ready to adapt — on the same infrastructure as the four main guides. The persistent sidebar down the left carries a Search anything field and lists all four groups: Get Started, Core Concepts, Use Cases and API Reference, with Use Case Gallery selected. On the right, under the section heading Genomics & Genetics, numbered entries each pair a card with a copyable code panel labeled prompt sketch: rare disease phenotype-to-gene matching for clinical geneticists and rare disease researchers, pharmacogenomics drug-gene interaction triage for clinical pharmacologists and precision medicine teams, and a third entry running off the bottom of the crop.

Overview: Keeping the Argument, Building the Reference

The front page is the source document’s argument, re-cut and kept. Four cards under Why GLKB compress four of its sections into a sentence each. Beneath them, What you can build turns its four worked tasks into three columns: the workflow, what you send, what you get back — the first thing on the page that is not in the document.

The shipped GLKB API front page above four versions explored on the way to it. In the shipped page a gradient hero card sits beside a panel of knowledge-base statistics, over four Why GLKB cards and a What you can build table. Across the four explored versions the hero changes, from no colored card at all to a solid blue one to a gradient, and the statistics panel appears and disappears with it, while the four cards and the table beneath them stay exactly where they are.

Shipping the Questions With the Answers

Three things were not settled when this had to ship: the production base URL, the name and format of the authentication header, and where the user identifier in the path comes from — the same three the source document had left open. So I put each one into the deployed build as a comment on the line it blocks. A developer meets the open question at the point that stops them, instead of finding it in a list afterwards.

The same three lines of the quickstart, twice. On the left the local source file, pages/1.2-quickstart.md, carrying no markers. On the right the deployed page, where three DEV comments sit on the lines they block: replace with production base URL on the BASE_URL assignment, confirm URL structure on the endpoint path, and confirm header name and format on the Authorization header. A note beneath records that api.glkb.dev is a documented placeholder and not a live host.

Structure: Two Ways In

I drew five site maps on the same 16-item outline, each changing only how much sits on a page and how much nests behind an index. All five capped out at eight pages. What shipped is 12, in four groups, and five of those are use cases — more than twice the endpoint reference. The person pushing a gene list through a script needs to know what to ask the graph before they need to know how to authenticate to it.

Search I did not specify, so it went to build as a line in the sidebar too narrow to show a result. It moved to a panel over a dimmed page. A rail can carry a page title but not the sentence the term was found in, and without that sentence the reader is choosing between 12 page names instead of 12 answers.

The documentation site with the search overlay open over a dimmed page. The sidebar behind it lists all 12 pages in their four groups. The query is protein, and every result is three lines: the group the page sits in, the page’s own title, and the sentence the term was found in with the term set in bold.

The Dashboard: A Key List Becoming an Account

The spend is read off the whole account rather than summed in the reader’s head. From running my own keys against somebody else’s models on a side project that summer, I knew the number you want is what all of them cost together, not what each one cost.

The bottom half of that screen is not a reorganization. A key list tells you what each key has done; it does not tell you where the month is going. So the table got a monthly view beneath it, funds and balance together, so that somebody running keys sees the whole month instead of assembling it from rows.

The shipped GLKB API dashboard, headed API Dashboard with the line Manage keys and monitor usage for GLKB API access, and no tab row anywhere on it. A button reading API Docs sits at the top right. A Keys section marked 3 keys · 2 active lists three test keys — test3, test2 and test — across eight columns: key, created, last used, status, query, request, token and cost. All three were created in September 2026, all three read Last Used: Never, two are marked Active and one Inactive, and every query, request, token and cost cell holds a dash. A Create key control is available; a Connect key control beside it is grayed out. Beneath the table, a panel headed Usage this month carries four figures — Total Queries 0, Total Tokens 0, Total Cost $0.00, Balance $0.00 — with Add funds and Billing controls grayed out above them. A security notice at the foot warns never to expose API keys in client-side code or public repos.

Impact

12 pages in four groups, from 1,067 lines of drafted content, deployed behind a password on a development host. The dashboard is live on glkb.org behind sign-in, with the tabs gone. Its funds and balance controls are built, disabled on the development host and hidden in production, waiting on payment coordination. The two surfaces point at each other: the dashboard carries a button out to the site, the site carries one back.

Saying it is not the same as making the case

I made the same argument twice about the same screen. The first time was half a sentence on the second day. I raised it, asked the PM to confirm, and treated her yes as the end of it.

The second time, four months later, I brought the cost with me: two days spent laying a document into a panel that could never hold it, and a summer of the documentation living at an address the product had to explain. It was agreed within a day.

The idea did not improve in between. What I brought to it did.

Credit

Product manager — Zhiyuan Liu

GLKB — Zhaowei Han, the PhD student who led GLKB

Agent team — Xiang Zhang

Front end — Bing Han

Lab — Jie Liu Lab, University of Michigan