Ben Nakic

Senior product designer based in Melbourne. Currently untangling school software for teachers, families and school offices.

AI workflow: Research synthesis, ideation
Coded prototypes, design QA
Experience: 8+ years in design
Digital, product, then EdTech
Focus: Design systems at scale
Multi-role workflows and data

Selected work

Design SystemWeb and mobile · Ongoing

One system, every school module

One system for every product, built and governed across four work streams.

One shared language for design and engineering
Faster, more consistent delivery across teams

Design System cover: one system, every module, with an attendance screen built from shared components

MarksbookWeb · End-to-end UX

Every mark, in its place

Set up classes, plan units and lessons, and mark against learning outcomes.

Setup to marking in one connected flow
Validated with teachers before build

Marksbook cover: a teacher markbook showing outcome levels for each student

Parent–teacher interviewsWeb and mobile · End-to-end UX

Ten minutes that matter

Event setup and booking management for schools, and booking for parents.

Less manual coordination for school staff
Every teacher booked in one go, on a phone

Parent–teacher interviews cover: a hand holding a phone with the parent app booking screen

AttendanceWeb and mobile · End-to-end UX

Every absence, accounted for

Marking the roll, parent absence notes and resolving every absence, in one flow.

Four roles, one connected flow
Every open absence tracked to resolution

Attendance cover: a hand holding a phone showing the teacher's Today screen, with a parent note and a resolved absence beside it

Wellbeing single viewWeb · Ongoing

One student, the whole picture

Three wellbeing products connected into one view of the student.

Three products, one student view
Earlier, better-informed check-ins

About

Designing since 2018

Product designer who ships. Strong on complex workflows and the systems behind them.

I started in service design at Litmus Group and PwC, across government, health, retail and utilities. Since 2022 I've been in EdTech, leading design on school workflows and the design system behind them, and testing with real educators until things are simple to use.

Experience

EdTech, senior product design2022 – Now

PwC2018 – 2021

Litmus Group2018

Bachelor of Design, Swinburne2017

Capabilities

Product and UI design
Design systems
User research
Usability testing
Journey mapping
Prototyping
AI-assisted workflows
Figma

Contact

Let's make something clear.

ben.nakic@gmail.com

LinkedIn ↗

← Work

Design System

One system for every product, built and governed across four work streams.

Role: Design system build and governance
Status: Ongoing
Platform: Web and mobile
Scope: Four work streams, global ecosystem

Problem

Four work streams shipping in parallel will drift apart unless something holds them together.

Teacher, administrator and parent products were being designed and built at the same time. Without shared foundations, the same decisions get remade in every stream and the products start to feel like different products.

Before and after: scattered modules with duplicate student records, then connected modules sharing one record — Before, every module had its own look and its own copy of the student.
After, every module builds from the same parts and points at one record.

Approach

I built the system from the bottom up: foundations, then tokens, then components, then patterns lifted from real product work like roll marking and report building. Alongside it I set up how the system is governed, so it keeps its shape as more teams use it.

The system as layers

Foundations

ColourTypeSpacingElevationMotion

Tokens

PrimitiveSemanticComponentThemes

Components

ButtonInputSelectTableChipModal

Patterns

Roll markingReport builderData tableFilters

Products

Teacher webMobileParent appAdmin

Four work streams contribute across every layer

Work stream 1Work stream 2Work stream 3Work stream 4

The system as stacked layers: tokens, shadcn/ui components, school patterns and modules — Tokens at the base, shadcn/ui components in the Nova style above them, then school patterns, then the modules teachers use.

Key decisions

Tokens in three tiers.Primitive values feed semantic tokens, which feed component tokens. A colour change happens once and reaches every product.

Patterns come from real work.Roll marking, report building and data tables were designed for shipped features, then promoted into the system.

Governance is a process, not a document.Any work stream can raise a need. A regular review decides whether to reuse, extend or add something new.

One colour, three tiers

Primitive

Semantic

Component

green.600#0B8A47

color.action.primary→ green.600

button.primary.background→ color.action.primary

neutral.900#1B2330

color.text.default→ neutral.900

table.cell.text→ color.text.default

neutral.0#FFFFFF

color.surface.default→ neutral.0

card.background→ color.surface.default

The same components used across Attendance, Markbook and Student Wellbeing — The same cards, badges, toggle groups, tables and buttons, used across Attendance, Markbook and Wellbeing.

An attendance screen split in two: the finished interface, and a blueprint labelling each shadcn component and token — What teachers see, and what it is made of. Every part of the screen maps to a component or token in the system.

Governance

Requests move through six stages. Usage and feedback feed the next request.

From the first need raised by a work stream to tracking adoption, every change follows the same path. That is what keeps the system honest.

From request to adoption

RequestAny work stream raises a need with a real use case.
TriageWeekly review: reuse, extend or add new.
DesignSpecs in Figma with states and usage guidance.
BuildTokens and components versioned in code.
ReleaseRelease notes and migration guidance.
AdoptUsage tracked across products and teams.

Usage and feedback feed the next request.

In the product

Three products, one anatomy.

Attendance, Marksbook and Parent–teacher interviews are built by different teams, yet they share the same navigation, headers, badges and tables. Each product only swaps its theme tokens.

Attendance, Marksbook and Parent–teacher interview screens side by side, with numbered pins on the shared sidebar, header, status badges and data tables — Real screens from three products, built from the same parts.

A component library sheet with buttons, status badges, inputs, a data table, a card and a toast, beside the same primary button and nav item in three product themes — The component library, and the same components themed for each product.

Outcome

One shared language.Designers and engineers across work streams build from the same foundations, tokens and components.

Faster, more consistent delivery.Teams reuse proven patterns instead of redesigning them, and products feel like one ecosystem.

A system that scales with the teams.Governance gives every work stream a clear way to contribute and a clear way to be heard.

What changed: one source of truth, consistent everywhere, accessible by default, faster to ship

Screens show sample data.

Next projectMarksbook →

← Work

Marksbook

An end-to-end teacher markbook, built around how schools actually teach.

Role: UX lead, research to delivery
Platform: Web
Users: Teachers
Scope: Classes, units, lessons, assessments, outcomes

A teacher markbook showing each student against three learning outcomes

Problem

A mark only means something when it connects back to what was taught.

Teachers needed one place to set up their classes, plan units and lessons, create assessments and mark against learning outcomes. Each part depends on the one before it, so the structure had to be right before any marking screen could make sense.

Structure

I mapped how teaching is organised in a school, from a class down to a single learning outcome, and made that hierarchy the backbone of the product. Everything a teacher creates sits somewhere on it, so marks always trace back to what was planned and taught.

A chain of cards from class to subject, unit, lesson and assessment, ending in a highlighted learning outcome, with a single entered mark traced up to that outcome — One mark, traced from the class all the way to the learning outcome it evidences.

My role

I led the UX from the first interview to the shipped workflows.

I ran research with teachers to understand how they plan and mark, mapped their workflows, and validated concepts in prototype testing before anything was built. Then I designed and specified the key workflows with product and engineering, and stayed close through delivery.

Research, validate and deliver: interview notes, prototype frames and the shipped marking screen — Research with teachers, validation through prototype testing, then delivery with engineering.

Key workflows

Four workflows carry a teacher from an empty term to finished marking.

From setup to marking

Step 1Set up a className, subject and students pulled from the roll.
Step 2Plan units and lessonsA unit holds the lessons that teach it.
Step 3Create an assessmentLinked to the learning outcomes it measures.
Step 4Mark and reviewA score plus a level for each outcome.

Four screens: new class, unit and lessons, assessment with linked outcomes, and marking a student

Key decisions

Outcomes, not only scores.Each assessment records a level for every outcome it covers, so teachers see what a student understands, not just a total.

Assessments carry their outcomes.Outcomes are linked when the assessment is created, so marking never needs extra setup.

Patterns at a glance.The outcome view shows the whole class at once, so gaps stand out and re-teaching can be planned straight away.

A class heatmap of outcome levels with a selected outcome and a plan re-teach action — The outcome view: every student against every outcome, with the selected outcome broken down on the right.

In the product

From the term plan to the last mark.

The shipped screens: teachers plan topics against the syllabus, then mark assessments inline in the markbook, with totals and grades updating as they go.

The Science Year 10 markbook with callouts on an inline edited mark and the unsaved change bar — The markbook: edit inline, review the change, then save.

Outcome

One workflow from setup to marking.Classes, planning, assessment and marking live in one connected flow instead of separate tools.

Marks that mean something.Every mark traces back to a learning outcome, so reporting reflects what was taught.

Validated before it was built.Prototype testing with teachers shaped the workflows before engineering started.

Screens show sample data.

Next projectParent–teacher interviews →

← Work

Parent–teacher interviews

Ten-minute conversations, booked and run smoothly for the school and for every family.

Role: End-to-end UX
Platform: Web and parent app
Users: School staff, teachers, parents
Scope: Event setup, booking management, parent booking

Problem

Two sides of the same booking, and both have to work.

Schools need to set up an interview event, open it to families and keep every teacher's schedule on track on the day. Parents need to book the right teachers at times that work for them, often for more than one child, from their phone.

The school console beside the parent app, joined by a confirmed booking — One booking, seen from both sides: the school managing the event and the family holding the confirmation.

Event setup

I designed the setup so a school can take an event from nothing to open bookings in four steps, with the defaults doing most of the work.

Event live in four steps

Step 1Create the eventName, date, time window and format.
Step 2Add teachersImported from the timetable.
Step 3Set slotsSlot length and regular breaks.
Step 4Open bookingsFamilies are invited to book.

Four setup screens: create event, add teachers, set slots and open bookings

The shipped create interview event screen, with a callout on the invitation summary — In the product: event details and invitations in two steps, with nothing sent until it is published.

Coordinating bookings

Every booking in one view.A schedule grid shows every teacher against every slot, with breaks and open times clear at a glance.

Changes notify families.Moving a booking updates the schedule and tells the family automatically.

Capacity is visible.Full teachers and waitlists surface before they become a problem on the night.

A schedule grid of teachers and time slots with a move booking panel

A teacher's shipped daily schedule, with the selected slot magnified and linked to its magnified booking details panel — In the product: tap a slot in the day, and the booking opens beside it.

Parent app

Booked from the sofa in four steps.

Parents choose a child, pick the teachers they want to see, choose times and get a confirmation they can add to their calendar.

Times that work in practice.Back-to-back bookings are spaced so parents can walk between rooms.

No dead ends.Full teachers are shown as full, rather than hidden.

Four phone screens: choose child, pick teachers, choose times and booking confirmed

A hand holding a phone showing the parent app's Booking confirmed screen, beside four booking steps from choosing a child to confirmation — The parent app: four steps from choosing your child to a confirmed booking.

Outcome board: higher parent engagement shown as a stack of confirmed family bookings, seamless event management as a filled slot grid, and one flow from school to teacher to parent — Screens show sample data.

Next projectAttendance →

← Work

Attendance

One connected flow, from marking the roll to resolving every absence.

Role: Product design, end-to-end UX
Platform: Web and mobile
Users: Teachers, parents, attendance office, leadership
Scope: Roll marking, absence notes, follow-up

A hand holding a phone showing the teacher's Today screen, with a parent's absence note and a resolved absence floating beside it

Problem

An absence isn't one task. It's a hand-off between four people.

A teacher, a parent, the attendance office and leadership each hold one piece of it. The work linked the teacher app, the parent app and the office console, so no absence gets stuck between people.

Three apps, one flow: the teacher marks the roll, the parent explains the absence in the parent app, it lands in the office queue, and the office closes it with a reason code

Teacher app

Rolls are marked on a phone between classes, often in a corridor, so the flow is built for one hand and a quick glance.

Three phone screens: a class list defaulting to present, a late status sheet, and a roll submitted confirmation

Parent app

The best time to explain an absence is while it's fresh, so parents are asked the moment the roll goes in, and can follow their note until it's accepted.

Office console

Every open absence sits in one queue until someone makes a decision on it. The decision itself had to be quick, and easy to correct.

The explanation review in three steps: the parent's explanation, the office decision with Approve highlighted, and the outcome preview for teacher and parent

Decision trail

Schools have to show how every absence was handled, long after the day, so nothing in the flow is ever overwritten.

Outcome board, less chasing for everyone: staff get back to teaching faster, schools let no absence slip through, and parents no longer need to call the office — Screens show sample data.

Next projectWellbeing single view →

← Work

Wellbeing single view

Three wellbeing products, connected into one view of the student.

Role: Product design, ecosystem
Status: Ongoing
Users: Teachers, pastoral and safeguarding staff
Scope: Three products, one student view

Problem

Each product held part of the picture. None held the whole student.

Provision planning, behaviour and safeguarding information lived in three separate products. Staff had to move between them to understand how a student was really doing, and early signs could sit in one system while the context sat in another.

Provision planning, behaviour and safeguarding, brought together into one profile.

Approach

We are building towards a centralised single view of the student. It brings what each product knows into one profile, and surfaces insights and alerts when the signals line up.

The single view: support in place, behaviour over time, concerns kept restricted, and every signal on one timeline.

Insights and alerts

Signals, surfaced early.When patterns line up across sources, the view raises an insight instead of waiting for someone to notice.

Every alert explains why.Each insight lists the signals behind it, so staff can judge it for themselves.

Staff stay in control.Alerts suggest a next step, like assigning a check-in, and staff decide what happens.

Three signal lanes over six weeks converging into an insight card — Signals from three sources line up in the same week and become one insight.

Right info, right person

One profile, shaped by role.

Wellbeing data is sensitive. A class teacher, a pastoral lead and a safeguarding lead each see what they need to act, and safeguarding detail stays with the people trained to handle it.

Outcome

A whole picture of the student.Staff see support, behaviour and wellbeing context in one place instead of three.

Earlier conversations.Insights bring patterns forward while there is still time to help.

A foundation for the ecosystem.Connecting three products sets up a shared student view other products can build on.

Screens show sample data. Product names are kept general.

Next projectDesign System →