KaveXniveD

A hybrid physical-digital education platform arrived as a technical specification with ambitious capabilities but no design path. I used research from a prior OBE system I designed from the ground up to turn it into a complete, development-ready product experience.

EdTech

Mobile App

Live Broadcast

Assessment Systems

Hybrid Learning

EdTech

Mobile App

Live Broadcast

Assessment Systems

Hybrid Learning

Role

Product Designer (UI/UX) | Sole Designer

Platform

Mobile Application

Company

M TECHUB LLC

Status

Design Completed

I received a technical specification. I returned a complete product design ready for development. The gap between those two things was the work.

Three user roles. Live broadcasting. Remote Associates Test (RAT) and Alternative Uses Task (AUT) assessments. Broadcast creation flow. Virtual classroom with real-time collaboration. Outcome tracking. One designer. Built on research from a prior OBE system I designed from the ground up.

My Role

From specification to development-ready product design. Alone.

I received a platform specification document. What I did not receive was a product blueprint, a user flow, a design system, or any prior research. What I did have was deep ground level knowledge of how OBE based educational assessment systems work, built through a full academic project where I designed, researched, and presented a multi module OBE system that a university dean wanted for their institution.

That prior research did not just accelerate the KaveXniveD design. It fundamentally shaped every product decision. I understood how teachers evaluate outcomes, how students engage with challenge-based assessments, and what breaks in educational systems when the design does not account for the gap between what teachers assign and what students can actually access.

I received a platform specification document. What I did not receive was a product blueprint, a user flow, a design system, or any prior research. What I did have was deep ground level knowledge of how OBE based educational assessment systems work, built through a full academic project where I designed, researched, and presented a multi module OBE system that a university dean wanted for their institution.

That prior research did not just accelerate the KaveXniveD design. It fundamentally shaped every product decision. I understood how teachers evaluate outcomes, how students engage with challenge-based assessments, and what breaks in educational systems when the design does not account for the gap between what teachers assign and what students can actually access.

I owned the product design end to end: information architecture, user flows, three role-specific experiences, broadcast creation, embedded assessment, the virtual classroom interface, outcome tracking, and development-ready handoff.

I received a platform specification document. What I did not receive was a product blueprint, a user flow, a design system, or any prior research. What I did have was deep ground level knowledge of how OBE based educational assessment systems work, built through a full academic project where I designed, researched, and presented a multi module OBE system that a university dean wanted for their institution.

That prior research did not just accelerate the KaveXniveD design. It fundamentally shaped every product decision. I understood how teachers evaluate outcomes, how students engage with challenge-based assessments, and what breaks in educational systems when the design does not account for the gap between what teachers assign and what students can actually access.

The Problem

A specification that described what to build but not how anyone would use it

The original KaveXniveD specification described a hybrid physical digital platform combining classroom sensors, audio processing, and educational assessment tools. The concept was ambitious and distinctive, turning classroom objects into a live broadcasting system while measuring student creativity through RAT and AUT challenges.

The problem was that the specification described technology, not experience. It listed features, RAT integration, AUT scoring, virtual studio, broadcast scheduling, without defining how a teacher would actually create a broadcast, how a student would navigate from a live class to a challenge, or how someone listening remotely would know what to do. A feature list and a product are not the same thing.

The deeper problem was the mismatch between the platform's ambition and what students and teachers in a real classroom would actually tolerate. Complexity that serves the technology rather than the user risks becoming a barrier to adoption. The design had to make a technically complex system feel like a natural next step from a normal class.

The original KaveXniveD specification described a hybrid physical digital platform combining classroom sensors, audio processing, and educational assessment tools. The concept was ambitious and distinctive, turning classroom objects into a live broadcasting system while measuring student creativity through RAT and AUT challenges.

The problem was that the specification described technology, not experience. It listed features, RAT integration, AUT scoring, virtual studio, broadcast scheduling, without defining how a teacher would actually create a broadcast, how a student would navigate from a live class to a challenge, or how someone listening remotely would know what to do. A feature list and a product are not the same thing.

The deeper problem was the mismatch between the platform's ambition and what students and teachers in a real classroom would actually tolerate. Complexity that serves the technology rather than the user risks becoming a barrier to adoption. The design had to make a technically complex system feel like a natural next step from a normal class.

"A student opening the app sees their performance, what is live, and what is coming. Three questions answered before they scroll."

The original KaveXniveD specification described a hybrid physical digital platform combining classroom sensors, audio processing, and educational assessment tools. The concept was ambitious and distinctive, turning classroom objects into a live broadcasting system while measuring student creativity through RAT and AUT challenges.

The problem was that the specification described technology, not experience. It listed features, RAT integration, AUT scoring, virtual studio, broadcast scheduling, without defining how a teacher would actually create a broadcast, how a student would navigate from a live class to a challenge, or how someone listening remotely would know what to do. A feature list and a product are not the same thing.

The deeper problem was the mismatch between the platform's ambition and what students and teachers in a real classroom would actually tolerate. Complexity that serves the technology rather than the user risks becoming a barrier to adoption. The design had to make a technically complex system feel like a natural next step from a normal class.

Research and Discovery

Ground-level knowledge applied to a new product context

I did not start from zero on KaveXniveD. My previous OBE system work gave me a strong research foundation in educational assessment, learning outcomes, teacher workflows, and the relationship between activities and feedback. I had already studied how CLO and PLO evaluation works, observed academic workflows, and gathered requirements from faculty and stakeholders.

What I needed to solve specifically for KaveXniveD was how live broadcasting as an educational modality changes the user's mental model. Broadcasting is not the same as attending a class. A student who is also a broadcaster has a fundamentally different relationship to content: they are performing and assessing simultaneously. I mapped this into three distinct user contexts: Student Broadcaster, Teacher, and Listener. Each needed a different dashboard and a different first screen because their primary question when opening the app is completely different.

I did not start from zero on KaveXniveD. My previous OBE system work gave me a strong research foundation in educational assessment, learning outcomes, teacher workflows, and the relationship between activities and feedback. I had already studied how CLO and PLO evaluation works, observed academic workflows, and gathered requirements from faculty and stakeholders.

What I needed to solve specifically for KaveXniveD was how live broadcasting as an educational modality changes the user's mental model. Broadcasting is not the same as attending a class. A student who is also a broadcaster has a fundamentally different relationship to content: they are performing and assessing simultaneously. I mapped this into three distinct user contexts: Student Broadcaster, Teacher, and Listener. Each needed a different dashboard and a different first screen because their primary question when opening the app is completely different.

Core finding from prior OBE research applied here: One pattern from my prior OBE work was that assessment becomes harder to understand when the activity and its feedback are separated. For KaveXniveD, that led me to keep RAT and AUT challenges inside the broadcast experience rather than treating assessment as a disconnected destination.

I did not start from zero on KaveXniveD. My previous OBE system work gave me a strong research foundation in educational assessment, learning outcomes, teacher workflows, and the relationship between activities and feedback. I had already studied how CLO and PLO evaluation works, observed academic workflows, and gathered requirements from faculty and stakeholders.

What I needed to solve specifically for KaveXniveD was how live broadcasting as an educational modality changes the user's mental model. Broadcasting is not the same as attending a class. A student who is also a broadcaster has a fundamentally different relationship to content: they are performing and assessing simultaneously. I mapped this into three distinct user contexts: Student Broadcaster, Teacher, and Listener. Each needed a different dashboard and a different first screen because their primary question when opening the app is completely different.

Users and their roles

Student Broadcaster

Creates and hosts broadcasts. Their first question: what do I have scheduled and what is my current performance? They need broadcast management and performance metrics on landing.

Teacher

Monitors broadcasts, creates assessment parameters, approves content. Their first question: what needs my attention right now? They need pending evaluations and broadcast requests surfaced immediately.

Listener

Joins live streams, participates in challenges, provides peer feedback. Their first question: what is live and how do I join? They need a discovery-first home screen, not a management dashboard.

Key Design Decisions

The decisions that turned a specification into a product

Decision 01 — Most Strategic

Three role-specific experiences instead of one shared dashboard

A teacher and a student broadcaster both use KaveXniveD every day but they open it for completely different reasons. A single interface with toggled permissions was the wrong answer.

The specification described Student Broadcasters, Teachers, and Listeners as user roles within the same system. The natural implementation assumption would be one interface with role-based permissions controlling what each user sees. I chose a different architecture.

A teacher opening the app needs to see: pending broadcast requests, upcoming scheduled sessions, student evaluations awaiting review, and live sessions currently running. A student broadcaster needs to see: their performance metrics, their upcoming broadcasts, their challenge completion stats, and what is live right now. A listener needs to see: what is currently live, what is coming, and their participation history. These are three different mental models. A single shared interface with hidden panels serves none of them well.

I designed three distinct dashboard architectures. The Teacher dashboard surfaces management and evaluation tasks. The Student Broadcaster dashboard surfaces performance and creation tools. The Listener dashboard is discovery-first with a clear entry to join live content. Each role logs in and lands on the information most relevant to them without first navigating through unrelated screens.

The specification described Student Broadcasters, Teachers, and Listeners as user roles within the same system. The natural implementation assumption would be one interface with role-based permissions controlling what each user sees. I chose a different architecture.

A teacher opening the app needs to see: pending broadcast requests, upcoming scheduled sessions, student evaluations awaiting review, and live sessions currently running. A student broadcaster needs to see: their performance metrics, their upcoming broadcasts, their challenge completion stats, and what is live right now. A listener needs to see: what is currently live, what is coming, and their participation history. These are three different mental models. A single shared interface with hidden panels serves none of them well.

I designed three distinct dashboard architectures. The Teacher dashboard surfaces management and evaluation tasks. The Student Broadcaster dashboard surfaces performance and creation tools. The Listener dashboard is discovery-first with a clear entry to join live content. Each role logs in and lands on the information most relevant to them without first navigating through unrelated screens.

The specification described Student Broadcasters, Teachers, and Listeners as user roles within the same system. The natural implementation assumption would be one interface with role-based permissions controlling what each user sees. I chose a different architecture.

A teacher opening the app needs to see: pending broadcast requests, upcoming scheduled sessions, student evaluations awaiting review, and live sessions currently running. A student broadcaster needs to see: their performance metrics, their upcoming broadcasts, their challenge completion stats, and what is live right now. A listener needs to see: what is currently live, what is coming, and their participation history. These are three different mental models. A single shared interface with hidden panels serves none of them well.

I designed three distinct dashboard architectures. The Teacher dashboard surfaces management and evaluation tasks. The Student Broadcaster dashboard surfaces performance and creation tools. The Listener dashboard is discovery-first with a clear entry to join live content. Each role logs in and lands on the information most relevant to them without first navigating through unrelated screens.

"Same product. Three landing experiences. Because three different users open it asking three different questions."

Decision 02

Embed RAT and AUT challenges inside the broadcast, not as a separate module

Separating assessment from the activity would introduce an unnecessary context switch. I embedded RAT and AUT challenges directly into the broadcast experience instead.

The specification described RAT and AUT as an Educational Assessment Module, a separate section of the app where students complete challenges. That architecture would require students to leave the broadcast, navigate to another module, complete the assessment, and then reconstruct the context of what they had just watched. I wanted assessment to remain connected to the learning activity itself.

I designed the challenge system so that RAT and AUT challenges are created by the broadcaster as part of the broadcast itself, attached to the broadcast record, accessible from within the broadcast detail page, and submittable without leaving the session context. When a listener joins a broadcast and sees “RAT Challenge, 30 Questions, 30 mins,” they are not navigating to a separate module. They are engaging with a challenge that is intrinsically connected to the content they just consumed.

For the broadcast creation flow, I built challenge design into step 4 of the 5 step creation process, Design Challenges, making it a structural part of planning a broadcast rather than an optional add on. A teacher who creates a broadcast must consciously decide whether to include challenges. The default is engagement, not omission.

The specification described RAT and AUT as an Educational Assessment Module, a separate section of the app where students complete challenges. That architecture would require students to leave the broadcast, navigate to another module, complete the assessment, and then reconstruct the context of what they had just watched. I wanted assessment to remain connected to the learning activity itself.

I designed the challenge system so that RAT and AUT challenges are created by the broadcaster as part of the broadcast itself, attached to the broadcast record, accessible from within the broadcast detail page, and submittable without leaving the session context. When a listener joins a broadcast and sees “RAT Challenge, 30 Questions, 30 mins,” they are not navigating to a separate module. They are engaging with a challenge that is intrinsically connected to the content they just consumed.

For the broadcast creation flow, I built challenge design into step 4 of the 5 step creation process, Design Challenges, making it a structural part of planning a broadcast rather than an optional add on. A teacher who creates a broadcast must consciously decide whether to include challenges. The default is engagement, not omission.

The specification described RAT and AUT as an Educational Assessment Module, a separate section of the app where students complete challenges. That architecture would require students to leave the broadcast, navigate to another module, complete the assessment, and then reconstruct the context of what they had just watched. I wanted assessment to remain connected to the learning activity itself.

I designed the challenge system so that RAT and AUT challenges are created by the broadcaster as part of the broadcast itself, attached to the broadcast record, accessible from within the broadcast detail page, and submittable without leaving the session context. When a listener joins a broadcast and sees “RAT Challenge, 30 Questions, 30 mins,” they are not navigating to a separate module. They are engaging with a challenge that is intrinsically connected to the content they just consumed.

For the broadcast creation flow, I built challenge design into step 4 of the 5 step creation process, Design Challenges, making it a structural part of planning a broadcast rather than an optional add on. A teacher who creates a broadcast must consciously decide whether to include challenges. The default is engagement, not omission.

"The challenge is part of the broadcast. You do not leave to do it. You do it because you are there."

Decision 03

Design the virtual classroom as a known interface pattern, not a new interaction model

The live classroom was the most technically complex part of the product. The design decision was not to make it feel complex.

The specification described a Virtual Studio Interface with real-time audio visualisation, a virtual mixing console, and multiple audio channels. Technically accurate. Experientially terrifying for a student who has never used broadcasting software.

I designed the live classroom interface using interaction patterns from video-call tools that students are likely to recognise, a gallery view of participants, a bottom control bar with mute, camera, and settings controls, an audio visualiser that shows energy without requiring users to understand what it means technically, and a simple action menu (Request Mic, Request Camera, Raise Hand) that mirrors what happens in a real classroom. The “Science Theme for Middle School” broadcast skin on the visual layer gives the experience context without requiring setup.

The design aimed to reduce cognitive load by borrowing interaction patterns students were already likely to recognise from video-call tools. The sensors, audio processing, and mixing stay behind the interface; students interact with something that behaves like a classroom rather than a broadcasting control console.

The specification described a Virtual Studio Interface with real-time audio visualisation, a virtual mixing console, and multiple audio channels. Technically accurate. Experientially terrifying for a student who has never used broadcasting software.

I designed the live classroom interface using interaction patterns from video-call tools that students are likely to recognise, a gallery view of participants, a bottom control bar with mute, camera, and settings controls, an audio visualiser that shows energy without requiring users to understand what it means technically, and a simple action menu (Request Mic, Request Camera, Raise Hand) that mirrors what happens in a real classroom. The “Science Theme for Middle School” broadcast skin on the visual layer gives the experience context without requiring setup.

The design aimed to reduce cognitive load by borrowing interaction patterns students were already likely to recognise from video-call tools. The sensors, audio processing, and mixing stay behind the interface; students interact with something that behaves like a classroom rather than a broadcasting control console.

The specification described a Virtual Studio Interface with real-time audio visualisation, a virtual mixing console, and multiple audio channels. Technically accurate. Experientially terrifying for a student who has never used broadcasting software.

I designed the live classroom interface using interaction patterns from video-call tools that students are likely to recognise, a gallery view of participants, a bottom control bar with mute, camera, and settings controls, an audio visualiser that shows energy without requiring users to understand what it means technically, and a simple action menu (Request Mic, Request Camera, Raise Hand) that mirrors what happens in a real classroom. The “Science Theme for Middle School” broadcast skin on the visual layer gives the experience context without requiring setup.

The design aimed to reduce cognitive load by borrowing interaction patterns students were already likely to recognise from video-call tools. The sensors, audio processing, and mixing stay behind the interface; students interact with something that behaves like a classroom rather than a broadcasting control console.

"The hardware is complex. The classroom is not. Students see a room, not an interface."

Decision 04

Design the broadcast creation as a structured five-step flow with a clear mental model

Broadcast creation needed to feel fast enough for a teacher to use as part of normal lesson preparation, not like configuring broadcasting software.

Broadcasting is a new behaviour for most teachers. The creation flow needed to guide a teacher through all the decisions required to launch a broadcast, without making those decisions feel like a configuration form.

I designed a five-step structured creation flow: Basic Info, Add Lessons, Schedule, Design Challenges, and Confirm. Each step is focused on one type of decision. A teacher sets the broadcast title, category, and description in step one. They add lesson content in step two. They set the date and time in step three. They optionally attach RAT or AUT challenges in step four. They review and confirm in step five. The progress indicator at the top of each screen (Create Broadcast 4/5) tells the teacher exactly where they are and how much is left.

The challenge step is explicitly optional but it is always presented. A teacher who skips it has made a conscious choice not to include assessment. That decision is tracked in the broadcast record.

Broadcasting is a new behaviour for most teachers. The creation flow needed to guide a teacher through all the decisions required to launch a broadcast, without making those decisions feel like a configuration form.

I designed a five-step structured creation flow: Basic Info, Add Lessons, Schedule, Design Challenges, and Confirm. Each step is focused on one type of decision. A teacher sets the broadcast title, category, and description in step one. They add lesson content in step two. They set the date and time in step three. They optionally attach RAT or AUT challenges in step four. They review and confirm in step five. The progress indicator at the top of each screen (Create Broadcast 4/5) tells the teacher exactly where they are and how much is left.

The challenge step is explicitly optional but it is always presented. A teacher who skips it has made a conscious choice not to include assessment. That decision is tracked in the broadcast record.

Broadcasting is a new behaviour for most teachers. The creation flow needed to guide a teacher through all the decisions required to launch a broadcast, without making those decisions feel like a configuration form.

I designed a five-step structured creation flow: Basic Info, Add Lessons, Schedule, Design Challenges, and Confirm. Each step is focused on one type of decision. A teacher sets the broadcast title, category, and description in step one. They add lesson content in step two. They set the date and time in step three. They optionally attach RAT or AUT challenges in step four. They review and confirm in step five. The progress indicator at the top of each screen (Create Broadcast 4/5) tells the teacher exactly where they are and how much is left.

The challenge step is explicitly optional but it is always presented. A teacher who skips it has made a conscious choice not to include assessment. That decision is tracked in the broadcast record.

"Five steps. One decision per step. The flow was designed around a target of completing broadcast setup in under five minutes, with one decision category per step and no separate instructions required."

Decision 05

Surface performance data as a score, not a table

Make performance understandable before making it detailed. The outcome tracking system had to give students an immediate read on performance, while keeping the detailed breakdown available when they wanted it.

The specification described an Assessment Results Dashboard with RAT and AUT scoring. A conventional implementation would be a table showing challenge completion percentages and raw scores per session.

I designed the performance system around two layers. The first layer is the student home screen, six metric cards showing Completed, Lessons, Request, RAT%, AUT%, and Feedback counts. The home screen gives students a quick summary of where they stand before they enter the detailed Outcomes view. The second layer is the Overall Performance ring showing a single aggregate score out of 500 with a verbal rating (Excellent, 421/500). The summary score gives students an immediate read on performance, while the detailed percentages remain available in the Outcomes view when they need more context.

The RAT and AUT percentages on the home screen connect directly to the outcome tracking module, the Outcomes tab in the bottom navigation. That module shows the detailed breakdown. But the home screen shows the number that matters. The design prioritises the student's relationship with their performance over the institution's need to see granular data.

The specification described an Assessment Results Dashboard with RAT and AUT scoring. A conventional implementation would be a table showing challenge completion percentages and raw scores per session.

I designed the performance system around two layers. The first layer is the student home screen, six metric cards showing Completed, Lessons, Request, RAT%, AUT%, and Feedback counts. The home screen gives students a quick summary of where they stand before they enter the detailed Outcomes view. The second layer is the Overall Performance ring showing a single aggregate score out of 500 with a verbal rating (Excellent, 421/500). The summary score gives students an immediate read on performance, while the detailed percentages remain available in the Outcomes view when they need more context.

The RAT and AUT percentages on the home screen connect directly to the outcome tracking module, the Outcomes tab in the bottom navigation. That module shows the detailed breakdown. But the home screen shows the number that matters. The design prioritises the student's relationship with their performance over the institution's need to see granular data.

The specification described an Assessment Results Dashboard with RAT and AUT scoring. A conventional implementation would be a table showing challenge completion percentages and raw scores per session.

I designed the performance system around two layers. The first layer is the student home screen, six metric cards showing Completed, Lessons, Request, RAT%, AUT%, and Feedback counts. The home screen gives students a quick summary of where they stand before they enter the detailed Outcomes view. The second layer is the Overall Performance ring showing a single aggregate score out of 500 with a verbal rating (Excellent, 421/500). The summary score gives students an immediate read on performance, while the detailed percentages remain available in the Outcomes view when they need more context.

The RAT and AUT percentages on the home screen connect directly to the outcome tracking module, the Outcomes tab in the bottom navigation. That module shows the detailed breakdown. But the home screen shows the number that matters. The design prioritises the student's relationship with their performance over the institution's need to see granular data.

"421/500. Excellent. That is the number. Everything else is detail the student can find when they want it."

The Design Principles I Applied

Every principle backed by a specific decision

Role shapes the first screen

→ Applied in Decision 01

Three roles, three dashboards. The product's complexity is invisible because each user lands exactly where they need to be.

Assessment belongs inside the activity

→ Applied in Decision 02

Decision 02 keeps the assessment connected to the broadcast instead of creating a separate context switch.

Complexity hides, familiarity leads

→ Applied in Decision 03

The physical layer is sophisticated. The student sees a classroom. Known interaction patterns reduce the amount of new interaction behaviour students need to learn.

Make performance legible before making it detailed

→ Applied in Decision 03 and Decision 05

Decision 05 gives students a clear summary first, while detailed outcome data remains available when needed.

Role shapes the first screen

→ Applied in Decision 01

Three roles, three dashboards. The product's complexity is invisible because each user lands exactly where they need to be.

Assessment belongs inside the activity

→ Applied in Decision 02

Decision 02 keeps the assessment connected to the broadcast instead of creating a separate context switch.

Complexity hides, familiarity leads

→ Applied in Decision 03

The physical layer is sophisticated. The student sees a classroom. Known interaction patterns reduce the amount of new interaction behaviour students need to learn.

Make performance legible before making it detailed

→ Applied in Decision 05

Decision 05 gives students a clear summary first, while detailed outcome data remains available when needed.

Outcome

A specification became a product architecture

KaveXniveD arrived as a technical specification and left my design process as a development-ready product architecture. I defined three role-specific experiences, a five-step broadcast creation flow, embedded RAT and AUT assessments, a familiar virtual-classroom interaction model, and a performance system designed around clear student feedback.

Distinct role based systems designed: Student Broadcaster, Teacher, and Listener, each with its own dashboard architecture.

Assessment types embedded inside broadcasts, RAT and AUT challenges integrated into the broadcast structure, not a separate module.

Step broadcast creation flow designed around an under-five-minute setup target, from basic information through challenges and confirmation.

Distinct role based systems designed: Student Broadcaster, Teacher, and Listener, each with its own dashboard architecture.

Assessment types embedded inside broadcasts, RAT and AUT challenges integrated into the broadcast structure, not a separate module.

Step broadcast creation flow designed around an under-five-minute setup target, from basic information through challenges and confirmation.

Development had not started during my time at M Techub. My deliverable was the complete product design and development-ready handoff, with the architecture, role logic, core workflows, interface states, and major interaction decisions defined before implementation.

KaveXniveD arrived as a technical specification and left my design process as a development-ready product architecture. I defined three role-specific experiences, a five-step broadcast creation flow, embedded RAT and AUT assessments, a familiar virtual-classroom interaction model, and a performance system designed around clear student feedback.

Development had not started during my time at M Techub. My deliverable was the complete product design and development-ready handoff, with the architecture, role logic, core workflows, interface states, and major interaction decisions defined before implementation.

The physical layer, the Smart Hub Controller, the classroom sensors, the sound processing unit, is described in the specification but is almost invisible in the mobile app design. I designed for the digital layer because that is what a mobile application can show. One of the most distinctive parts of the concept was the connection between physical classroom interactions and the digital broadcast experience. That connection point deserved its own design treatment, an onboarding flow that shows a student how the physical and digital layers interact.

I would also run structured usability testing on the broadcast creation flow specifically with teachers who have no prior broadcasting experience. The five step structure is clean, but step four, Design Challenges, requires a teacher to understand what a RAT challenge is before they can configure one. That context is not currently built into the creation flow. A brief explanation within the step would close that gap.

KaveXniveD taught me that domain research compounds. The OBE work I had done earlier gave me a stronger starting point for a new educational product, allowing me to spend less time learning the domain from scratch and more time solving the interaction and architecture problems specific to KaveXniveD.

Reflection

What I would do differently

Reflection

What I would do differently

The physical layer, the Smart Hub Controller, the classroom sensors, the sound processing unit, is described in the specification but is almost invisible in the mobile app design. I designed for the digital layer because that is what a mobile application can show. One of the most distinctive parts of the concept was the connection between physical classroom interactions and the digital broadcast experience. That connection point deserved its own design treatment, an onboarding flow that shows a student how the physical and digital layers interact.

I would also run structured usability testing on the broadcast creation flow specifically with teachers who have no prior broadcasting experience. The five step structure is clean, but step four, Design Challenges, requires a teacher to understand what a RAT challenge is before they can configure one. That context is not currently built into the creation flow. A brief explanation within the step would close that gap.

The physical layer, the Smart Hub Controller, the classroom sensors, the sound processing unit, is described in the specification but is almost invisible in the mobile app design. I designed for the digital layer because that is what a mobile application can show. One of the most distinctive parts of the concept was the connection between physical classroom interactions and the digital broadcast experience. That connection point deserved its own design treatment, an onboarding flow that shows a student how the physical and digital layers interact.

I would also run structured usability testing on the broadcast creation flow specifically with teachers who have no prior broadcasting experience. The five step structure is clean, but step four, Design Challenges, requires a teacher to understand what a RAT challenge is before they can configure one. That context is not currently built into the creation flow. A brief explanation within the step would close that gap.

I received a technical specification. I returned a complete product design ready for development. The gap between those two things was the work.