THE SCREENSHOT IS THE SPEC: BUILDING SOFTWARE SIMULATIONS INSIDE ARTICULATE RISE
- Jul 20
- 4 min read
Updated: Jul 27
Week 11 · Blog Post 19 · Web 2.0-Based Learning and Performance · Summer 2026
THE PROBLEM WITH TEACHING SOFTWARE FROM PICTURES OF SOFTWARE
I spent last week building software that doesn't work — deliberately. A replica of a modem's configuration screen, rigged to auto-fill the wrong number at exactly the moment the real modem would. All fake. All clickable. And all living inside Articulate Rise — a tool with no native ability to simulate anything. Rather than describe it, here it is. Click around. Get caught by the trap. Try the scored round. (The simulation may stack on narrow screens.)
The project behind it: training field technicians who set up internet connections to configure a particular modem — roughly 20 steps across two pieces of equipment, performed on-site, often from memory. The riskiest step isn't a hard one. It's a field the modem "helpfully" fills in with its own factory default where the customer's unique value belongs. Trust it, and the setup fails after the technician has left the job site. The voiceover I eventually wrote for that moment puts it plainly: "This modem likes to fill in fields for you. Don't trust it." You can't teach someone to distrust an auto-filled field with a bullet point. They need to watch the wrong number appear and get caught — safely, repeatedly, before it counts.
IT STARTED WITH NOT WANTING TO BUILD ANOTHER HOTSPOT
The honest origin story, though, isn't the auto-fill. It's that I didn't want to build another hotspot activity. Click-the-screenshot has always been the default way to fake software practice in Rise, and I suspected Claude could come up with something better — something that could live inside Rise's custom code block, the rectangle that renders whatever HTML you paste into it. So I described the activity I wished existed:
"Design an interactive activity for my Rise course that requires the learner to configure the entire copper static IP order from start to finish — ensuring to include all steps in the attached document. Round 1 should be guided with hints. Round 2 should be scored with no hints and missteps counted. In both rounds, the Gateway Address should autofill the wrong value."
Claude built a beautiful activity that functioned just like the software. It just didn't look anything like it.
THE SCREENSHOT IS THE SPEC
So I thought: if Claude can read images, why can't it recreate them? Simple, I know. I uploaded a screenshot for each step of the process — from navigating to the modem in a simulated browser to testing the final changes — and wrote:
"Instead of a generic UI, generate code that matches the images of the real UI. Reference the attached screenshots and then edit this code:"
That sentence changed everything. Claude rebuilt the actual thing — the logo header, the dark sidebar with the right menu item active, the little green confirmation state — in HTML, CSS, and SVG. The counterintuitive part: the screenshots never end up in the course. Rebuilt interfaces can be cropped, so tabs learners don't need simply cease to exist. Sample data stays consistent — at one point Claude flagged that my screenshots showed a different IP block than the course's sample order, and kept the canonical values. And the file stays self-contained: no hosted images, nothing to break.
Here is an example of a screenshot (with branding removed):
Here is what Claude Cowork built from that screenshot:
The other thing worth stating once, in the first prompt, is your constraint set. Mine: one self-contained HTML file, transparent background so it sits natively on the Rise page, all CSS and JS inline, brand colors declared as variables, mobile-responsive. State it once and every file after inherits it.
DESCRIBE THE SYMPTOM, NOT THE SOLUTION
From there it was iteration — and I never debugged a line of code. I described what I saw: "Add a Restart button to this activity that users can click anytime to start the round over." The IPv4 slider/setting looks weird. The radio button is overlapping the text. Correct this and ensure the setting looks like a slider that the learner clicks to turn on."
The plain-English symptom turned out to be a complete bug report — often a better one than a technical guess would have been. Then came the compounding move: I went back to the software training I'd already built with generic interfaces, uploaded each activity's code plus its screenshots, and wrote some version of
"Revise this activity so that the login page matches the attached image."
The second sim cost a fraction of the first, and every one after was cheaper still, because the last working activity became the template for the next.
WHERE THE SEAMS ARE
Honest limits, because there are a few:
Code blocks don't report to the LMS, so anything graded or tracked stays a native Rise block and the sims carry the practice.
QA is on you — preview every activity in Rise before publishing, every time. And screenshots of internal tools need permission before they become training material, rebuilt or not.
But the headline stands. I've essentially figured out how to create a basic, sandboxed version of any software from screenshots — not a picture of an interface to click on, but the interface itself, with traps, feedback, and scoring, living inside an ordinary Rise lesson.
So here's what I'll put to you: Knowing that a screenshot is now enough to rebuild any interface as a safe, breakable fake — what would you build? And where would you take this that I haven't thought to?
Comments