İrem Sultan Koçak

01 / Case study · Product evolution & requirements

HERA V2

From a working desktop system to a more scalable web product.

How real operational feedback shaped a new product scope, permission model and research workflows for Tazelenme University.

Development-stageAnalysis & product definition

Manager viewBroad operational module access

My contribution
Product Requirements & Workflow Design
Team
4 people
Scope
14 modules · 4 user roles
Stage
Analysis & product definition

This diagram represents product scope and planning, not a claim that V2 was deployed.

The reason to evolve

V2 did not start from a blank page.

HERA V1 had already been installed and used. That experience surfaced new requirements, while interest from other Tazelenme Universities highlighted the limits of a standalone, local desktop setup. The next step was to rethink the product for wider access and more complex institutional workflows.

Input 01

Operational feedback

Real users identified friction, missing capabilities and workflow refinements.

Input 02

Broader applicability

Interest beyond the original institution prompted web-oriented product thinking.

Input 03

Research needs

Survey reuse and research data required a clearer structure than V1 provided.

My approach

Turn feedback into product decisions, not just a longer feature list.

  1. Observe V1 usage
  2. Collect & filter needs
  3. Define workflows
  4. Set rules & access
  5. Document V2 scope

I contributed to feature scope, module boundaries, business rules, roles and permissions, and requirements documentation. These decisions were made collaboratively; my focus was on making operational needs explicit enough to guide product development.

Four product decisions · a selection

Where the product became more intentional.

Four examples from the 60+ product decisions defined across the project — chosen to show different kinds of reasoning.

01Reusability

A survey pool separate from research

Problem
Rebuilding questions for each research project would duplicate work and blur the difference between a survey and the study using it.
Decision
Define a reusable survey pool, separate from research management, so students can complete assigned surveys without accessing research administration.

02Permissions

Student self-service, with boundaries

Problem
Keeping all updates with administrators creates unnecessary work, but unrestricted editing introduces risk.
Decision
Let students view relevant courses and activities and update selected information, while preserving role-based restrictions.

03Module boundaries

Clubs are not the same as events

Problem
Treating every activity alike would obscure different participation patterns and administrative needs.
Decision
Separate recurring club workflows from event-specific management.

04Domain logic

Progression beyond a conventional GPA

Problem
A standard academic grading model does not fully describe a social-responsibility learning program for older adults.
Decision
Define academic progression and transcript logic around the program's actual rules, not just grades.

Roles & access

One platform. Different responsibilities.

HERA V2 user roles
RoleResponsibility
ManagerInstitutional oversight & administration
TeacherTeaching-related workflows
OperatorDay-to-day record management
StudentControlled self-service & participation

Role descriptions summarize the planned access model; they are not an exhaustive permission matrix.

Management interface · administrative reporting

Management analyticsAdministrative reporting on demographics, course capacity and operational activity

Management analyticsCourse occupancy, request flow, and trip participation & payment

Development-stage product screens, not evidence of a public launch. The visible menu reflects the captured implementation state.

Product evidence · Research workflow

Reusable surveys. Controlled research access.

These development-stage screens make the distinction tangible: a survey is a reusable question structure, while a research project controls its audience, access and repeated measurement.

Reuse without duplication

Design the survey once.

Question formats and required fields are defined at the survey level, rather than rebuilt for every study.

Decision 01A survey pool separate from research

01 / Survey libraryReusable questions, scales and validation rules

Access with boundaries

Keep research governance separate.

Research records include ownership and access controls, so managing a study is not the same permission as answering a survey.

Decision 01Research management stays separate

02 / Research accessOwnership, access level and documentation

Repeatable measurement

Connect one survey to different study waves.

The linked-survey workflow distinguishes survey templates from their use within a particular research project, including pre-test and post-test comparisons.

03 / Linked surveysSurvey assignment and repeat-measurement structure

Screens show a development-stage implementation. Any visible labels, statuses and records are illustrative of the interface, not independently verified research outcomes.

Project output

A defined product direction — not a fabricated launch story.

14functional modules in scope
4defined user roles
60+product decisions defined
4 shown here as examples

The work established a structured set of requirements, workflows and business rules for HERA's web evolution. The case study focuses on analysis and product definition; it does not claim a production rollout or measured adoption of V2.

What I learned

Product evolution is not adding more features. It is redefining how the system should work.

V1 taught us what real operations required. V2 challenged us to turn that learning into clearer boundaries, permissions and reusable structures.

Next case study · 02

AdSphere Designing clearer roles, negotiation rules, and approval steps for an end-to-end influencer campaign workflow.