03 / Case study · Product discovery & delivery
HERA V1
Turning manual university operations into their first digital product.
HERA was developed for Tazelenme University to replace fragmented paper- and document-based operations with a structured desktop management system.
8 modules · one operationAuthentic HERA V1 interface — shown as product evidence, not a UI redesign.
Project arc · from paper to a working product
- Phase 01DiscoveryStakeholder visit, listening, process mapping
- Phase 02RequirementsRequests filtered into structured requirements
- Phase 03DevelopmentEight operational modules
- Phase 04TestingBefore installation
- Phase 05DeploymentInstalled at Tazelenme University
- Phase 06TrainingPresenting, training and supporting users
- Phase 07FeedbackV1 revisions or V2 backlog
The starting point
It started with paper.
Operational records and processes lived across physical files and documents. As information accumulated, retrieval, tracking and maintaining a coherent operational view became increasingly difficult.
- Physical files + documents
- Growing records
- Difficult retrieval
- Need for structure
Discovery before development
Before designing screens, we had to understand the operation.
- Stakeholder visit
- Listen
- Map processes
- Filter requests
- Define requirements
We met stakeholders in person, listened to how daily operations worked, combined their requests with our own analysis, and translated the underlying needs into structured requirements.
What are they asking for — and what do they actually need?
Turning requirements into structure
The modules were an outcome of the analysis — not a predefined feature list.
- M01Student
- M02Health
- M03Attendance
- M04Journal / Archive
- M05Trip
- M06Club
- M07Library
- M08Donation
The original eight-module home screen is shown above. The architecture here maps the operational scope without repeating the same screenshot.
From request to product requirement
“A user request and a product requirement are not always the same thing.”
Health records introduced a more complex requirement: answers could not be represented by a single data type. Depending on the metric, the system needed to support text, yes/no states, numeric values and explanatory information.
Sensory metrics
Vision
Different metric types required different answer structures.
From requirements to a working product
The result was not a prototype left on a presentation slide.
The application brought student records, health information, attendance, activities and other operational processes into one management system.
Class-based navigation and operational actions, from the original desktop product.
Four states, not a binary checkbox. Attendance was not simply present / absent. The workflow represented present, absent, excused and medically excused states.
Delivery was part of the product work
The product did not end when development ended.
- Test
- Install
- Present
- Train
- Support
- Collect feedback
After testing, the application was installed at Tazelenme University. I presented the product, trained users, supported early usage and collected feedback. Requests were evaluated rather than implemented automatically: suitable improvements became V1 revisions or future backlog items.
07 · Outcome
- 8operational modules
- Real-world deployment
- User training & support
- Feedback → product evolution
HERA moved beyond a classroom concept and into real operations, creating the foundation that later informed HERA V2.
What I learned
Good product work is not about implementing every request.
It is about understanding the problem behind the request, translating it into requirements, and making decisions that work for both users and the product.