All work

Case study 07 GSA and other federal agencies

Six Coding Challenges

Blank page, hard deadline, working prototype. Six times.

Client
REI Systems, across federal challenges for GSA and USCIS
Role
Designer across six competitive technical challenges
Timeline
April 2019–2024
Recognition
REI named to the GSA COMET BPA in 2019
6 federal coding challenges designed
$1B+ vehicle won, sole designer
8 hrs shortest documented challenge window

Summary

A blank page, a hard deadline, and a prototype that has to work.

A federal coding challenge is not a design review. An agency hands a team a business case and a room, starts a clock, and expects a working prototype and a demo before the clock stops. There is no requirements document to push back on and no backlog to defer things into. Whatever exists when time runs out is what gets evaluated.

Across my time at REI Systems, this happened six times: COMET, SPEED, RMSS, ODOS III, FINCH, and an earlier ODOS engagement whose exact date is still being checked against my employment record. Only one of the six left behind something concrete enough to show in detail, the RMSS challenge for USCIS, alongside a solo practice run I built afterward to keep the same speed sharp between live challenges.

This study is built from both, with the other four named honestly rather than illustrated.

The problem

The work does not run in the order a normal project runs.

Research does not finish before design starts, and design does not finish before development starts. All three run at once, on the same few hours. A static comp does not survive a room that wants to see something work, and a developer sitting idle for an hour is an hour the team does not get back.

The challenge is not to make every screen perfect. It is to get the highest-value flow moving early enough that the team can test it, change it, and still have something credible to demo when the clock reaches zero.

What I did

Build, verify, and revise on the same clock.

The pattern held across every challenge. Ship a thin slice first: the first hour goes to one flow, built well enough that a developer can start on it immediately. Keep researching while the build runs: stress-test the flow against records with no owner, permissions a supervisor has that an employee does not, and edge cases that the business case may or may not actually contain.

When research changes the plan, help the room change it fast. A found edge case is not useful if it becomes a note for later. On a deliverable measured in hours, catching a problem and fixing it need to happen in the same conversation, which means bringing the team a specific change to make rather than a general concern to worry about.

That loop repeats, tightening, until the clock runs out.

The shape of a challenge day

Design and build run on the same clock, not in sequence

A five-step challenge loop. A problem lands, a thin slice ships fast, research continues in parallel, research changes the plan, and the team is brought a specific change to make. The loop returns to shipping until the demo is evaluated.

01

Problem lands

Business case, user stories, a deadline measured in hours.

02

Ship a thin slice fast

One flow, screens a developer can start building from immediately.

03

Keep researching in parallel

While the build runs, pressure-test the flow against real edge cases.

04

Research changes the plan

A found edge case means a field, a role, or a flow has to move.

05

Bring the team the change, not just the news

The designer shifts from making screens to helping the room re-decide fast enough that the deadline still holds.

Demo

Whatever exists at the buzzer is what the room evaluates.

Two runs of this loop, documented in this study

RMSS · USCIS 10-person team · 8 hours · Feb 27, 2022
Solo speed drill 1 designer · 5 hours · self-directed practice
The shape of a challenge day: build, verify, and revise on the same clock.

RMSS

The version with a full team behind it.

USCIS ran the RMSS Human Capital Management Solution Challenge on February 27, 2022. Ten people, eight hours, and a business case built around onboarding employees and handling their documents securely. I was the lead UX designer: personas, journey maps, high-fidelity Figma, and enough HTML and CSS to keep the front end from drifting away from the design mid-build.

Four personas got built that day: an HR employee who uploads a new hire’s documents but loses access to them the moment intake is done, an HR supervisor who is the only role that can reopen and redact a file afterward, a records manager who owns compliance without owning intake, and a security analyst who ran out of runway before the team could finish her. Her page still has the placeholder text nobody replaced. It stayed in the deliverable exactly like that, because that omission is more honest than a fourth persona finished after the fact would be.

Who the RMSS challenge was designed for

Four personas, built inside an eight-hour window

Four persona cards from the RMSS challenge. Linda is an HR Supervisor with full PII access, Katie is an HR Employee with no PII access after intake, Jon is a Records Manager with records-only access, and Susan is an unfinished HR Security Analyst persona marked as having run out of time.

Linda HR Supervisor

15 yrs in HR

Goal

Secure PII and keep employee files complete and accurate.

Access

Full PII access · can redact

Katie HR Employee

4 yrs in HR

Goal

Create and update profiles accurately without breaking anything.

Access

No PII access after intake

Jon Records Manager

8 yrs in records

Goal

Keep records compliant with NARA retention rules.

Access

Records-only, no ingestion authority

Susan HR Security Analyst

Goal

“fasdfasdf”

Access

Goals, expectations, and challenges: unfilled

Ran out of time

The fourth persona was still lorem-ipsum text and empty goal fields when the eight hours ended. It stayed in the file exactly like that. Cutting it after the fact would misrepresent what the team actually shipped.

The four RMSS personas, including the one the clock ran out on.

The team’s own definitions page set the rule that shaped everything else downstream: a record is a document with a retention policy, and once something is declared a record, it does not get edited, it gets a new version. That single sentence is why the redaction flow works the way it does.

A supervisor opening a passport image to black out a Social Security number is not editing the file. She is producing a second, separate version next to the first, with the original left untouched underneath it. Which role can even reach that toolbar was decided on the spot: full access for the supervisor, none for the employee once a document is filed, and a records manager who can confirm a file exists without ever seeing its contents.

A document's path through RMSS

Every record is a document, and a change makes a new version, not an edit

Four connected steps show a document moving through RMSS: an employee uploads identification documents, the documents are filed to a record, a supervisor redacts a sensitive field, and the redaction is saved as version two beside the untouched original version one.

  1. 01

    Employee uploads

    Katie · HR Employee

    Documents land unredacted. Nobody has trimmed anything yet.

  2. 02

    Filed to the record

    Employee Profile · Olivia Rhye

    Supporting documents sit on the profile as a plain, unmodifiable list.

  3. 03

    Supervisor redacts

    Linda · HR Supervisor only

    Redact tools sit next to the file. Nobody else in the app has this toolbar.

  4. 04

    Saved as a new version

    Not an edit to the original

    The definitions page was explicit: a record never changes in place, it gets a new version.

A document's path through RMSS, from upload to a redacted second version.

The reporting tool is the part of RMSS that reads as the least like an eight-hour build. It shipped two ways to ask the same question: a drop-down query builder for a records manager who has never written a line of SQL, and a raw SQL editor for whoever the technical member of the team was, both feeding the same results table so neither path was treated as the throwaway option.

It also shipped the actual failure states: an empty results panel, a loading spinner, and a required-field error on the rule builder, not just the version where everything works.

One feature, two ways in

The ad hoc report generator shipped with both a visual builder and a raw SQL editor

Two report-building paths feed one query-results table. The visual builder lets a user choose department equals Accounting and an entry date before January 1 2020. The raw SQL editor shows a query for the same report. Four result states are shown: empty, loading, populated, and error.

Visual builder

For Katie, who has never written a query
ValueConditionCriteria
departmentequalsAccounting
AND
entry datebefore01/01/2020

Drop-downs only. No syntax to remember, no way to typo a keyword.

Raw SQL editor

For power users who already think in queries
SELECT name, size, sum(number) AS total
FROM staff-2014
GROUP BY name, size
ORDER BY total DESC
LIMIT 10

Same underlying report engine. The result set does not know which editor built it.

Query results One results table, fed by either path

And every state the report could be in when someone looks at it

Empty

Run your query to generate results.

Loading

Spinner over a dimmed table.

Populated

7 results, sortable columns.

Error

“required field is missing”

The ad hoc reporting tool: two ways in, four states to land in.

Not everything got the same amount of attention. The sign-in flow, password reset screens, and base employee-profile form kept the placeholder brand of the component kit the team started from rather than being reskinned. On an eight-hour clock, that is a deliberate trade, not an oversight: time went to the parts specific to USCIS and human capital management, not to screens every enterprise product needs and few evaluators score closely.

A solo run, for practice

The muscle has to stay sharp between live challenges.

Separately, and on my own initiative, I built a second exercise in Adobe XD: a five-hour, one-person build of an Employee Self Service tool covering timesheets against project charge codes, overtime requests, and absence requests. It was never submitted anywhere. It exists because the gap between live challenges is exactly when the muscle atrophies, and a timed solo drill is a cheap way to keep it from doing so.

Smaller in scope than RMSS by design; one person cannot replicate what ten people cover in the same span. What is consistent between the two is the discipline: build the flow that matters first, and do not let a compressed timeline become an excuse to skip a state a real user would actually hit, like a day with a mismatched hour total or a charge code someone forgot to add before submitting.

Two different clocks

A full team challenge and a solo drill test the same muscle differently

A side-by-side comparison of the RMSS challenge and a solo practice drill. RMSS used Figma and coded HTML/CSS with a ten-person team in eight hours, building four personas and about eighteen screens and states. The solo drill used Adobe XD with one designer in five hours, covering about nine screens and states.

RMSS Challenge

USCIS · 10-person team · 8 hours · Feb 27, 2022

Tool
Figma, then coded HTML/CSS
Personas built
4 (one left unfinished)
Core systems
Auth, records, redaction, reporting
Edge states designed
Empty, loading, error, populated
Outcome
Lost, an AWS environment issue
~18 distinct screens and states

Solo Practice Drill

Self-directed · 1 designer · 5 hours · Adobe XD

Tool
Adobe XD
Personas built
None, time-boxed for speed
Core systems
Timesheet, overtime, absence requests
Edge states designed
Date conflicts, partial entries
Outcome
Practice only, never submitted
~9 distinct screens and states
Why both belong in this study

RMSS shows what the process looks like with a full team and a real client behind it, redaction rules, role permissions, and compliance vocabulary that only come from working alongside people who live in that domain.

What the solo run proves

The solo drill shows the same instincts running without a team to lean on. Same rhythm of shipping a thin slice first, same discipline about states, at a fifth of the scope and half of the time.

RMSS and the solo practice drill, compared side by side.

What came of it

Six challenges, six different results.

Naming all of them is more convincing than naming only the win. COMET is the best documented of the two wins: the GSA Blanket Purchase Agreement for CIO Modernization and Enterprise Transformation. GSA selected REI as one of twelve companies out of thirty-nine quotes submitted. I was the sole designer on REI’s submission for that challenge.

The honest version of that sentence stops there. The vehicle’s funding belongs to the vehicle, not to any one designer’s screens, and REI’s win belongs to the whole team that built and presented the submission. ODOS III was the second win, awarded to the ADG-REI joint venture in 2022.

Six challenges, six different results

Naming what happened is more credible than naming only the win

Accessible table of six federal coding challenges. COMET and ODOS III were wins. RMSS was a loss caused by an AWS environment issue. SPEED and FINCH were not selected. An earlier ODOS engagement is still being confirmed against employment dates.

What happened on each of the six coding challenges
ChallengeAgencyYearResultWhy
COMET GSA 2019 Won One of 12 BPA awardees, selected from 39 quotes.
ODOS III USCIS 2022 Won Awarded to the ADG-REI joint venture.
RMSS USCIS 2022 Lost An AWS environment issue during the challenge, not a design problem.
SPEED USCIS 2021 Not selected No REI award; five other primes were named.
FINCH USCIS 2022 Not selected No REI award; two other primes were named.
ODOS USCIS Date being confirmed Confirming Timing under review against employment dates before publishing.

Two wins, one loss with a documented cause, two not-selected, and one date still being checked before publishing.

What actually happened on each of the six challenges.

RMSS is the one loss with a clear, documented cause. The challenge did not come down to the design work shown earlier in this study; an environment issue, specifically a technical problem with the AWS deployment, got in the way during the challenge itself. SPEED and FINCH did not result in an REI award either, with no design work surviving from either to show here. The remaining engagement, an earlier ODOS challenge, is still being checked against employment dates before it gets a firm place in this list.

One precision matters across the whole record: COMET is CIO Modernization and Enterprise Transformation, not “Challenge to Modernize IT.” “Sole designer on REI’s COMET challenge submission” is accurate; it describes who built REI’s entry, not who decided the government’s award. Nothing from before April 2019 belongs in this study, because that is when my REI tenure started.

What I would do differently

Archive the work before the fire is out.

Neither of these should have needed reconstructing years later. The COMET challenge has no surviving screens at all, only the story of it and the award that followed, and RMSS survived only because one export sat untouched in a folder. Nothing about a timed challenge prevents a team from spending the last five minutes exporting the file somewhere it will still exist in three years. That habit is worth building deliberately, because the next fire always feels more urgent than the archive until the archive is the only thing that would have made the next portfolio update possible.

The unfinished fourth persona is the other one worth sitting with. It was the right call in the room: an eight-hour clock has to spend its last minutes on the system rather than on a document nobody would open that day. But nothing stopped a return trip afterward to close it out once the pressure was off, and that follow-up never happened.