How might we let archers record scores during a competition without breaking their focus, in unpredictable outdoor conditions?
Outdoor and unpredictable
Sun glare, rain. High readability was a requirement.
One-handed use
Archers other hand might be holding a bow or equipment. Every primary action has to stay within the thumb's natural reach.
A wide age range
Archery is multigenerational, so the interface had to be high-contrast and intuitive for both a 16-year-old and a 60-year-old.
Pressure
Competitors are focused on target, and an error is visible to others. The interface must not add anxiety on top.
My own experience on archery ranges, where I watched a simple paper scorecard break an archer's focus. That makes me a user, which is useful but also a risk. I had to filter my own bias as an archer. I combined this lived experience with a short questionaire, where I asked my colleagues inside the archery club more about how the competition feels from a group dynamic view and current state of score keeping.
To test my approach, I ran two usability studies, one for each stage of prototyping.
Study 1, Wireframe prototype.
5 participants tested the score keeping flow in the early stage. Focus was on familiarity of the proces. Task completion rate 4/5.
Study 2, Functional prototype.
6 participants attended the in person test. Focus was on ergonomics during the score writing. Task completion rate 5/6.
"I always feel a bit guilty when I write the wrong score. Even if I fix it, it throws me off how the paper looks after. It's never just about the arrow. It's about the pressure and who's watching."
That quote moved the problem from "entering numbers" to "how an error feels". This inspired the dual score writing methods approach, dragging the “pills” and tapping on the score field inside card.
First direction: minimalism. I tried to fit every score-entry element on one compact screen. It looked clean. [What exactly happened in testing: how many participants struggled, what did they do, what did you see?] Without visual hierarchy, the screen was unusable under the stress of a competition.
Pivot: room to breathe. I gave the interface space and prioritized clarity over density. Show the before and after side by side, as you do now.
Second pivot: two input methods. I offered a choice: a gestural drag-and-drop "pill" for speed, and a conservative "drop-up" menu for reliability. Testing showed that the pills felt innovative, but under pressure, or in the rain, users went back to the menu. [Was the rain real or simulated? State which.]
1. Give the screen space
Problem: One compact screen had no hierarchy, so it failed under stress.
Decision: Larger targets, clearer grouping, fewer simultaneous elements.
Evidence: Usability study 1 [add the numbers].
2. Keep both input methods
Problem: Speed and reliability pulled in opposite directions, and users differed in digital confidence and conditions.
Decision: Keep the drag pill and the drop-up menu.
Evidence: [Add the data. Which method was faster? Which had fewer errors? Which did people choose when they were stressed? Without it, "keep both" reads as indecision, so show the numbers that justify it.]
3. A prototype built for testing
Problem: Comparing two input methods across test sessions risks comparing two different prototypes.
Decision: I built a modular scoring card component with multiple states and nested interaction layers, so I could switch between the drag and tap systems without rebuilding anything. Every participant saw the same flow.
Evidence: Consistent test conditions across [how many] sessions.
4. A training mode
Problem: Usability study 2 showed archers also want to use the tool outside tournaments.
Decision: A hidden Training Mode, added after testing.
Evidence: [What did participants say in study 2 that led to it?]
Validated in testing: [Add the completion rate, error rate or time per entry from your studies.]
Not validated: use at a real competition. The prototype was built to test whether a digital tool can keep pace with a live event without becoming a distraction. [State the answer your tests gave.]
Outreach: I offered the solution to the Slovak 3D Archery Association. It produced no partnership and no feedback. I treat that as a finding: a good product needs institutional readiness, not only good UX.
What happened next: the prototype became a working system, described in Phase 2.
What users say in a controlled setting often differs from what they do under pressure. My biggest lesson was to filter my own bias as an archer and to design for the psychological weight of the interface, so that every interaction builds trust, not anxiety. The case for keeping two input methods is also a case against assuming that the more innovative option wins.
