The homepage is the only page that nails it: a modern, commercial-product look with a layout that's spot on. Everything else needs serious UX and UI work. This isn't a criticism of the engineering. Treat it as an engineer's handoff to a UX team.
Page by page
-
Network weights
A series of cards with no organizing idea. It reads like raw JSON rendered as boxes.
-
Reports
Clicking shows cryptic progress text, spins, and then eventually shows something. It should be a collection of reports, each with its own link.
-
Library
Items are labelled with internal identifiers, so it's unclear what you're looking at. Everything needs a human name.
-
Runs
An "as of" timestamp over loose columns: it looks like a markdown file, not a web interface. Runs need to be clickable, expandable and linkable.
-
Models
You pick a world, then a list of per-level experts appears. The single best model for the world should come first, with a drill-down to the level experts. The "snapshots by run" column is disorganized and unclear.
-
What we learned
Wordy and hard to scan. Organize it like teaching material: high level first, then down into the detail.
Second pass: the runs board
After the first round of mockups, the runs board got a closer review:
- Plain titles. "What runs now" is awkward English. "Current runs" says it.
- Every card is a link. A card opens that run, on a dedicated run page if one doesn't exist yet. It's a website as well as a research log, so normal web conventions apply: every item in the database has a page, and you can link to it.
- Cohesion over clutter. The first pass felt thrown together, with words scattered around and no single voice.
- Grounded in real data. The pages should read from the real database, not feel like static text pasted into a template.
- One card, one pattern. Similar run cards rendered the same action differently: a dropdown on one, a button on another. Standardize every element across cards, and pick one control for each action instead of offering two.
- Correct routing. Opening a run from the library went to the wrong page. It should open the player with that run already loaded.
- Readable detail text. Strings like "no fallback, the game ends at the first stage without a member" need rewriting until a newcomer can follow them.
- The phone layout matters. The mobile versions looked broken. They need their own pass, with a specific list of what's off.
Naming
Don't choose between a plain name and a playful one. The main label follows a convention: model type, then level, then a short note on what the run is doing. For example:
memory · 2-2 · dodging the fish
That tells you at a glance what it is and what it's learning. The fun title moves to the subtitle. And show every world from the start, filling each one in as runs reach it, instead of hiding the later ones.
Principles
- Not more stuff. Don't add elements. Make what's already there link up and hang together.
- Professional wording, everywhere. Every string on every page should meet the standard of a professionally written website, not just the headings.
- Write for newcomers too. Explainers should use pictures and concrete examples from the game, expandable definitions, forward and back steps, and live values, so someone who has never heard of an emulator can follow along.
- Design first, build after approval. Nothing ships until the boards are signed off, and the live version should match the approved design exactly: layout, palette, type and wording.
- Always keep a way back. Switch to the new pages in a way that can be reverted with one step, and don't remove the old version until the revert has been tested.
The short version
Engineers build dashboards that show everything they know. Users need a site that shows what matters, names things like a person would, links every item to its page, and reads like someone edited it. The work is mostly subtraction, consistency and writing, not new features.