sandeshsubedi.com
ROUTE CLARITY / ACCESSIBLE TRANSIT OPERATIONS

Color was doing too much work.

Making route identity easier to recognize - and a dispatch decision easier to verify.

RESEARCH STUDY + CONCEPT REDESIGN

A color-matching experiment opened a larger design question: how can an operator recognize the right assignment and know their action was accepted?

Route Clarity/ Verification concept
SIMULATED
1Next departure → Springfield
S

Select the matching route, then confirm.

MMoraine
○M · Moraine
XXenia
○X · Xenia
LLinden
○L · Linden
SSpringfield
◉S · Springfield
✓ Selected
CColumbus
○C · Columbus
HHuber
○H · Huber
3Selected: S - Springfield
Confirm route
01 The destination leads.02 Each route has a code and full name.03 Selection is visible before commitment.
CONTEXT

Individual HCI coursework 2024 study - 2026 extension

CONTRIBUTION

Need-finding, prototyping, data collection and analysis

DESIGN FOCUS

Accessible recognition, feedback and error recovery

STATUS

Local interactive prototype No operational deployment

Original work is documented in the supplied report. The 2026 synthesis, redesign and implementation were developed with AI assistance. This case study distinguishes those contributions and their evidence.

THE CASE IN A MINUTE

The useful shift.

Problem.

The study interface asked people to identify routes through color, making color discrimination part of the task.

Response.

The concept adds readable route identity, explicit selection, and a confirmation flow that accounts for uncertain outcomes.

Evidence.

The original palette test improved one participant's observed accuracy. The redesigned workflow still needs evaluation.

01 / THE QUESTION

[ 01 ]

What does the interface ask a person to compensate for?

In the Dayton Transportation Company study scenario, each color represented a destination. An operator's ability to distinguish the colors became part of their ability to complete the task.

The report described incorrect selections and longer decisions for operators with color-vision difficulties. The original project explored whether a different palette could make the task easier. That was a useful starting point, but it still left route meaning inside color.

The redesign asks a broader question: what information would let someone recognize the destination even when the color cue is unhelpful?

DESIGN QUESTION

How might we make the intended route identifiable, the selected route explicit, and the result of confirmation understandable?

Who is affected?

Operators completing the task, supervisors resolving errors, and the service that depends on the assignment.

What is established?

The source documents a color-recognition problem in a study. It does not quantify real dispatch failures or financial loss.

What is inferred?

Interruptions, stale assignments and uncertain responses are proposed operational scenarios to investigate.

02 / THE RESEARCH

[ 02 ]

A real signal. A deliberately narrow claim.

The report describes a five-minute need-finding interview with a participant who experienced particular difficulty with shades of red, green and brown.

The participant selected shades they found easier to recognize. Two color-matching interfaces were then compared, recording the prompted color, chosen color, time and accuracy. The participant with reported color blindness took part on both days; a comparison participant joined on day two.

Original class-presentation slide showing the color-matching interface surrounded by recorded task tables. The interface contains six unlabeled color choices, a Start Task button, and a target color marked Choose Me.
Original research artifact - Class presentation, slide 4.Study apparatus, not a screenshot of a deployed transit system.
REPORTED RESULT / PARTICIPANT A / DAY TWO

Correct color selections

Counts from report pp. 6-7 and presentation slide 9. Percentages calculated from the reported counts. Participant labels are anonymized in this case study.

MEAN REACTION TIME / SAME PARTICIPANT & DAY
1.08sOriginal palette
0.99sNew palette

The report also records a request for stronger background contrast. This became a concrete design input for the later concept.

What these results mean

The tested palette helped this participant in these trials. They do not demonstrate that the 2026 redesign prevents dispatch errors, works for every form of color-vision difference, or improves service performance.

PARTICIPANT-GROUNDED PROFILE

A person before a palette.

Participant A (Anonymized from the source report)

REPORTED

Difficulty with particular color shades

Red, green and brown were especially challenging. The participant selected more recognizable shades and recommended improving background contrast.

INFERRED DESIGN NEED

A reliable way to identify the destination

Readable route names and codes could offer another way to recognize the task. Explicit feedback could help the person check their choice before committing.

No age, tenure, biography or verbatim quote is invented. This is a focused design profile, not a claim that one participant represents every operator.

03 / THE DESIGN DECISIONS

[ 03 ]

Each decision removes a different kind of uncertainty.

01
RECOGNITION

Give the route a name where the decision happens.

The concept keeps the six route colors and adds a one-letter code and full destination name. The task heading names Springfield before the operator reaches the choices.

This reduces the need to infer a destination from a swatch or remember a color-to-route mapping. The code supports quick recognition; the name carries meaning. Neither replaces the other.

Tradeoff

More text takes space. Full destination names earn that space because the destination is the task. Stable internal identifiers would still be required behind these display labels.

INTERACTIVE DESIGN COMPARISON

What remains when color is removed?

Codes and names identify all six routes, including S - Springfield.

The color-only view is an explanatory reconstruction using the requested palette, not the original study screen. Grayscale demonstrates color dependence; it is not a simulation of a specific disability.
02
LEGIBILITY

Preserve the palette. Repair the label surface.

The brief prescribed both route fills and label colors. Checking them exposed a conflict: the Moraine and Linden pairs have contrast ratios of approximately 2.87:1 and 2.38:1. Both fall below the 3:1 threshold for large text.

The redesign preserves those exact tokens but puts light labels on a dark backing inside the colored field. Xenia keeps dark text directly on its yellow fill. Readable code-and-name captions also repeat below the swatches.

Why not recolor every route?

It would break the specified identity palette without evidence that a replacement works better. Changing the text surface addresses the measured contrast issue while preserving the familiar color cue.

PRESCRIBED PAIR / MORAINE
2.87:1Below 3:1

Light label directly on the prescribed pink fill.

REDESIGNED LABEL SURFACE
15.54:1Passes WCAG AA

The same light label on #1E1E1E backing.

03
SELECTION & FOCUS

Make a choice visible before it becomes a commitment.

A selected route uses a checked radio control, a solid border, a checkmark and "Selected" text. A summary repeats the code and full name. Keyboard focus has a separate dashed outline.

These cues answer different questions: where am I? and what did I choose? They also keep the state understandable when color is unavailable.

The interaction question I would test next

If the assignment already specifies Springfield, a prefilled review may be safer and faster than selecting it again. The six-card flow preserves the study brief; it is not evidence that manual selection is the best production interaction.

KEYBOARD FOCUS / DASHED OUTLINE
TWO DISTINCT STATES

Focus identifies the control ready for keyboard input.

Selection identifies the chosen route and remains visible when focus moves.

Diagram of the concept’s states. The live prototype uses native controls.

04
RECOVERY & TRUST

Explain the result when the system is uncertain.

The original test restarted after a choice. In a proposed operational workflow, the end of an interaction needs more care. "Selected," "submitted" and "accepted" describe different events.

The extended prototype blocks stale submissions, clears a choice when the assignment changes and holds an unknown result for reconciliation. It never describes a local click as proof that a bus departed.

The boundary

These are proposed safeguards tested as local logic. Real authorization, freshness, concurrent updates and durable receipts require a supported operations-system integration.

01

Selected

Review the named route.

02

Submitted

Await the authority's response.

03

Outcome unknown

Check the existing request.

04

Acknowledged

Show a specific receipt.

Illustrative recovery path. A delayed response is not automatically a failure, and resubmission is not automatically safe.

04 / THE EXPERIENCE AROUND THE SCREEN

[ 04 ]

The task continues after the button.

The research focused on color matching. This proposed journey extends the design lens to context, review and recovery. Stages and emotional states are hypotheses for fieldwork.

Orient

Operator action

Read the departure request.

Potential feeling

Attentive

Design support

Persistent task heading

Evidence boundary

Destination task in report p. 1

Recognize

Operator action

Find code and destination.

Potential feeling

Cautious

Design support

Redundant identity cues

Evidence boundary

Color difficulty in report p. 2

Review

Operator action

Compare route and assignment context.

Potential feeling

Reassured if clear

Design support

Explicit selection and context

Evidence boundary

Proposed extension

Confirm

Operator action

Submit and await acknowledgment.

Potential feeling

Uncertain while waiting

Design support

Separate pending and accepted states

Evidence boundary

Original test auto-restarted, p. 3

Recover

Operator action

Refresh a conflict or check an unknown result.

Potential feeling

Confident after resolution

Design support

Actionable reason and recovery path

Evidence boundary

Not studied in the original work

For the operator

Can I complete and correct the task without help or relying on color?

For operations

Does the review reduce rework without slowing the control room?

For engineering

Which system owns the assignment, the permissions and the final receipt?

05 / THE INTERACTIVE PROTOTYPE

[ 05 ]

Try the decision. Then try the failure.

The full concept includes more than the successful path. Its scenario menu lets you explore stale data, disconnection, concurrent changes, rejection and a delayed acknowledgment.

Route Clarity
Interactive Demo
Launch Interactive Prototype
AVAILABLE SCENARIOS
Current assignmentStale assignmentConnection lostConcurrent updateAcknowledgment delayedAuthority rejects request
Download raw .html file (13KB)

Self-contained. Opens in any browser. No installation or connection required.

The recommended test path

01
RecognizeFirst, choose a different route (e.g., Moraine) to see the mismatch safeguard block your confirmation.
02
VerifyThen, choose Springfield. Observe the explicit selection state and successfully confirm the route.
03
RecoverFinally, switch the scenario to 'Acknowledgment delayed'. Try to submit, and check the status of the hanging request.
ACCESSIBILITY IN THE INTERACTION

Usable through more than one cue.

  • Keyboard: native radios, arrow-key selection, native buttons and visible focus.
  • Meaning: code, full destination, checked state and specific feedback.
  • Legibility: corrected text surfaces, per-route label colors and neutral captions.
  • Recovery: clear blocking reasons and distinct pending, unknown and accepted states.

06 / OUTCOMES & NEXT EVIDENCE

[ 06 ]

Clear about the progress. Precise about the proof.

MEASURED IN THE ORIGINAL STUDY

A more recognizable palette for one participant.

On day two, reported correct color selections changed from 58/99 to 104/104, and mean reaction time from 1.08 to 0.99 seconds. These belong to the original palette experiment.

DELIVERED IN THE DESIGN EXTENSION

A broader interaction model for recognition and recovery.

The extension adds readable identity, a corrected label surface, distinct selection and focus cues, and simulated recovery states. It has not been tested with operators or deployed.

The next study should decide whether this deserves to ship.

Compare the right alternatives. Test the existing workflow, labeled manual selection and a prefilled assignment review with balanced tasks and counterbalanced order.

Recruit beyond the original sample. Include relevant color-vision differences, low vision, keyboard use, experience levels and shifts. Do not require unnecessary diagnosis disclosure.

Measure the whole task. Record correct completion, time, recovery, help requests and abandonment. Include wrong vehicle, stale data and interrupted work - not only route matching.

Validate the operational fit. Agree the assignment owner, integration contract and continuity procedure. Measure attributable rework before making a business case.

PRODUCT JUDGMENT

An incumbent-system improvement may be the best outcome. If labels and review can be added safely to the current platform, a separate product could introduce more fragmentation than value. I would make that comparison before asking an agency to adopt another tool.

07 / REFLECTION

[ 07 ]

The most valuable work was deciding what to question.

01

The constraint can reveal the problem.

Preserving the specified colors exposed weak label contrast. The useful response was to change the reading surface while keeping the identity cue - not to assume the supplied palette was already accessible.

02

A safeguard can create its own burden.

A second selection may prevent an error, or create another opportunity for one. The manual-selection requirement deserves testing against prefilled review rather than automatic acceptance as a best practice.

03

The result matters as much as the control.

Adding a confirm button is easy. Defining what confirmation means when the source is stale, another person changes the assignment, or the response disappears is the harder design work.

CRAFT IN AN AI-ASSISTED PROCESS

Fast execution. Accountable claims.

AI supported the 2026 research synthesis, interaction exploration, copy and HTML implementation. It did not conduct the original interviews, supply new participant evidence, or validate a live transit workflow.

The case study makes that boundary visible: measured results stay attached to the original study, inferred journeys are labeled, and the concept's untested benefits remain hypotheses. The design argument rests on the reasoning and evidence, not the speed of producing screens.

A useful interface gives people enough information to recognize the task, understand their choice and recover with confidence.

PROJECT NOTES

[ 08 ]

Sources & authorship.

Original project: Sandesh Subedi, individual HCI coursework. The class presentation is dated October 1, 2024. The 2026 concept extension was developed with AI assistance. No client engagement, shipped outcome, management role, team size or commercial impact is asserted.

  1. [1]
    Mini Project 1 - Report.pdf

    "Designing an Interface for a Color-blind Person," Sandesh Subedi. User-supplied report, 9 pages. Need-finding pp. 1-2; collection pp. 3-4; results pp. 5-7; future work p. 8.

  2. [2]
    MP1 Class Presentation | Subedi.pptx

    User-supplied deck. Original artifact from slide 4, reproduced without alteration. Results on slides 7-10. The deck and report describe the same study, not independent replication.

  3. [3]
    W3C - Understanding Contrast (Minimum)

    Basis for interpreting the calculated label contrast. Normal text requires 4.5:1 and large text 3:1, subject to the standard's exceptions.

  4. [4]
    W3C - Understanding Use of Color

    Basis for providing meaningful identification and state cues beyond color.

  5. [5]
    W3C - Web Content Accessibility Guidelines 2.2

    Proposed production evaluation target. This case study and prototype are not a conformance certification.

The proposed operational context is a study scenario. The journey and broader stakeholder needs are design hypotheses. No new field research was performed for this portfolio extension.

CONTINUE READING

Interested in the business case behind these design decisions?

View Product Investment Brief