Pages

Monday, September 14, 2026

Five principles for our design system. How we make design decisions when we build in SLS.

https://sls-ds-principles.godrive.my.id/#2


This is a thoughtful and unusually strong set of design principles for SLS. It is grounded in learning science, avoids many common EdTech traps, and provides actionable decision rules rather than vague aspirations.

That said, if I were reviewing this as an MOE/SLS design strategy document, I would suggest several refinements.

Overall Assessment

Strengths

  1. Anchored in a clear vision

    • Joy, Agency and Confidence provide a coherent north star.
    • The principles connect back to learner outcomes rather than product metrics.
  2. Evidence-informed

    • Cognitive load theory, desirable difficulties, intrinsic motivation, accessibility and automation literature are reflected throughout.
    • The references are appropriate and generally support the principles.
  3. Opinionated

    • Good design principles should help teams resolve trade-offs.
    • Statements such as "Automate busywork, not judgement" and "Earn attention. Do not farm it" provide concrete guidance.
  4. Cross-functional

    • Design, Engineering and QA can all apply these principles.
    • The principles translate into implementation decisions.
  5. Particularly strong for AI-era SLS

    • Teacher oversight.
    • AI as recommendation rather than authority.
    • Protection against over-automation.

Highest-Level Concern

The principles are predominantly product-centric rather than learning-centric

The vision is learning-focused, but several principles drift towards UX and platform design.

Missing is an explicit principle about:

Learning design quality.

For example:

  • Conceptual understanding
  • Feedback quality
  • Assessment validity
  • Transfer of learning
  • Metacognition

An excellent platform can still host poor pedagogy.

Recommendation

Consider adding a statement such as:

"Technology should amplify sound pedagogy, not compensate for its absence."

or

"Design for learning before designing for interaction."

This would resonate strongly with ETD and curriculum perspectives.


Principle-by-Principle Review

P1: Smooth Everything but the Learning

Rating: 9.5/10

This is arguably the strongest principle.

What works well

The distinction between:

  • productive difficulty
  • unnecessary friction

is psychologically sound.

Examples like:

  • e-dictionary in comprehension
  • retryable practice
  • scaffold fading

are excellent.

Concern

The phrase:

"Students can lean on support when they want it"

may overestimate learner self-regulation.

Many weaker students:

  • leave supports on forever
  • or remove supports too early

Suggestion

Reframe towards:

"Supports adapt to learner readiness while remaining under learner control."

This better reflects gradual release.


P2: Earn Attention. Do Not Farm It.

Rating: 8/10

This principle is refreshing because it pushes back against superficial engagement metrics.

What works well

Strong challenge to:

  • streaks
  • leaderboards
  • engagement optimisation

This aligns with self-determination theory.

Concern 1: Slightly anti-gamification

The document risks implying:

gamification = bad

Research is more nuanced.

Leaderboards can be harmful.

But:

  • narrative progression
  • mastery journeys
  • meaningful achievements
  • social collaboration

can improve engagement.

Suggestion

Change from:

Do not farm attention.

to:

Do not manipulate attention.

This provides more room for well-designed motivation structures.


Concern 2: Underestimates habit formation

Students sometimes need behavioural nudges.

For example:

  • reminders for homework
  • notifications about upcoming deadlines

These are not necessarily coercive.

Current wording may discourage useful intervention.

Suggestion

Explicitly distinguish:

Supportive nudges from

Psychological pressure tactics


P3: Automate Busywork, Not Judgement

Rating: 9/10

A strong AI governance principle.

What works well

The phrase:

"Speed alone invites rubber-stamping"

is especially valuable.

Many GenAI implementations ignore this risk.

Concern

Teacher judgement is not infallible either.

The principle currently positions:

Teacher = judgement

AI = proposal

In reality some diagnostic tasks may eventually exceed human consistency.

Example

Automated pattern detection:

  • misconception clustering
  • mastery estimation
  • risk detection

may be more reliable than manual scanning.

Suggested revision

Replace:

feedback, diagnosis and intervention do

with

feedback, diagnosis and intervention require human accountability

This future-proofs the principle.


P4: One Foundation. Fit the Role.

Rating: 8.5/10

Excellent design-system thinking.

What works well

The separation between:

  • structure
  • expression

is elegant.

It should reduce unnecessary fragmentation.

Concern

The principle emphasises:

  • teachers
  • students
  • administrators

but overlooks another major SLS actor:

School leaders

Examples:

  • HODs
  • SHs
  • Principals

They increasingly access data and analytics.

Suggestion

Explicitly include:

leadership users

in role modelling.


Additional Gap

Accessibility is mentioned but feels secondary.

Could elevate accessibility from a requirement to a principle-level concept.

For MOE's scale, accessibility is strategic rather than operational.


P5: Move Complexity to the Right Place

Rating: 9/10

Extremely practical.

This should help prevent feature bloat.

What works well

Excellent hierarchy:

  1. Automate
  2. Progressive disclosure
  3. Main screen

Concern

There is a risk of over-hiding capability.

Many advanced SLS users:

  • learning designers
  • ICT mentors
  • power teachers

need sophisticated controls.

The principle mentions this but does not provide sufficient protection.

Suggestion

Add:

Complexity should be hidden from those who do not need it, but discoverable for those who do.

This balances simplicity with power.


Missing Principle

If I could add a sixth principle, it would be:

P6: Make Learning Visible

Students learn better when they can see:

  • what they know
  • what they do not yet know
  • what progress looks like

Teachers teach better when they can see:

  • evidence of learning
  • misconceptions
  • growth over time

Many successful adaptive platforms revolve around making learning visible rather than merely making tasks accessible.

This aligns strongly with:

  • agency
  • confidence
  • formative assessment

without conflicting with any existing principle.


If This Were Going to Senior Management

I would recommend tightening the message into five memorable executive statements:

  1. Protect productive struggle.
  2. Support learning, not engagement theatre.
  3. Automate administration, preserve professional judgement.
  4. Keep one platform, adapt to each role.
  5. Place complexity where it creates the least burden.

And I would add one overarching sentence:

Technology does not create learning. It creates the conditions in which learning can happen more effectively.

That statement captures what is currently implied throughout the document and would resonate strongly with MOE's long-standing position that curriculum quality and teacher expertise remain the primary drivers of educational impact.

Slides

SLS · DESIGN, ENGINEERING AND QA

Five principles for
our design system.

How we make design decisions when we build in SLS.

These five principles settle the decisions and dilemmas that keep coming back when we groom features for SLS.

They also keep us on the same page. SLS is built by a cross-functional team spanning ETD, DXD and Ufinity, working across design, engineering and QA.

A shared principle gives all of us the same starting point when a call has to be made.

Most features engage two or three of the five rather than all of them.

OUR VISION

Help students learn with joy, agency, and confidence

Our five design system principles help us get here.

Every principle here traces back to that sentence. When a call is close, the vision can help us weigh it up: if one option leaves a student with more joy, more agency or more confidence, that's usually a good reason to lean towards it.

THE FIVE

Five principles, five decision rules

  • P1Smooth everything but the learning
  • P2Earn attention. Do not farm it.
  • P3Automate busywork, not judgement
  • P4One foundation. Fit the role.
  • P5Move complexity to the right place
P1SMOOTH EVERYTHING BUT THE LEARNING

PRINCIPLE 1

Smooth everything but the learning

Remove interface friction. Keep the effort the task was built to demand.

Attention is a limited budget, and students spend it on whatever the screen puts in front of them. A confusing label, an extra click, a cluttered page: all of that comes out of the same pot as the thinking.

Except learning doesn't stick unless it's hard. Having a go at a question before seeing the worked answer, or trying to remember something before looking it up. That struggle is where the learning happens, and we run into both truths together constantly.

We sort the work first. If a task isn't there to teach anything, we smooth it as much as we possibly can. If it is, we work out what the one intended struggle is, guard it, and clear everything else out of its way.

Some of what that looks like in practice:

  • Scaffolds come off as the learner gets stronger, so students can lean on support when they want it and step away when they don't.
  • They can ignore what the AI suggests, because a suggestion isn't a verdict.
  • Work survives a retry, and an error message says what to do next.
  • Student identity is hidden by default on class displays and stays visible to the teacher, so shared mistakes, marks and work never expose the person who produced them.

Anxiety spends the same budget as the thinking does, which is why the space has to be safe to be wrong in.

WHY IT MATTERS

Attention is fixed

Every click, label and navigation step we add is taken from the same budget the task needs.

INTERFACE LOADLEARNING EFFORTCLEARCLUTTEREDNONEALL OF ITONE LEARNER’S ATTENTION, FIXED
FIG 01 — INTERFACE LOAD EATS THE ATTENTION THAT LEARNING NEEDS

Learners have limited attention, and a confusing interface spends it on things that teach nothing. The budget doesn't grow to fit a busier screen, so a learner working out where to click has less left for the passage in front of them.

PRINCIPLE 1: SMOOTH EVERYTHING BUT THE LEARNING

What this looks like when we design

BUILD

DO NOT BUILD

An e-dictionary in a comprehension journal, where vocabulary is not the tested skill

The same e-dictionary in a spelling test, where it removes the skill being tested

Hint frequency that falls as performance improves, and returns when it is needed

The same full hint on every attempt, with no way to reduce or restore support

A retryable practice attempt that preserves the learner’s work

An irreversible attempt on a task that was meant for practice

P2EARN ATTENTION

PRINCIPLE 2

Earn attention. Do not farm it.

Learners come back because the product supports learning. Pressure raises usage and teaches nothing.

Why this matters

Students can only learn on SLS if they open it. The quick ways to get them back are streaks, push reminders, leaderboards and unlockable avatars. These raise logins fast, and logins are easy to count.

Motivation research shows the cost. When pressure or a reward from outside drives the behaviour, it tends to stop when the pressure stops. In one university course, adding badges and a leaderboard left students less motivated and scoring lower on the final exam.

Our team faces a risk too. Logins are easy to measure and learning isn’t. If we’re judged on logins, we’ll keep choosing whatever raises them.

THE SUSTAINABLE REASONS

What brings students back

The three words from our vision, seen from the student’s side.

  • JOYWork that is hard but doable, and worth finishing
  • AGENCYA goal the student chose, about learning not decoration
  • CONFIDENCEAn early real win, feedback, mistakes that stay private

Joy and agency are properties of the task in front of a student right now. Confidence is built out of what happened before, so it takes longer to earn and it is easier to lose.

  • Joy of learning. Students enjoy work that is hard but doable, and they come back to finish something they care about. For example: “You’re 2 questions away from finishing Fractions: Part 2.”
  • Agency. Students stick to plans they made themselves. The system or teacher can suggest a goal, and the student decides whether to take it on. The choices should be about learning, like which topic comes next or how to show what they know. Unlocking an avatar colour isn’t that kind of choice.
  • Confidence. Students return to places where they feel capable. That takes three things:
    • a real win early on
    • feedback on what they did (“You checked your working and caught the error”)
    • mistakes that stay private and are easy to retry

The test

  1. Who set it up? The student or teacher chose it, or the system imposed it.
  2. What does it tell the student? Something useful about their learning (“You’ve got 8 of 10 fraction questions right”), or pressure to keep going (“Don’t lose your 12-day streak!”).
  3. What happens when they miss a day or get something wrong? Either nothing is lost and nobody else sees it, or they lose a streak, drop a rank or get a “We miss you!” nudge.

We can use login and usage data to see what’s happening, but we shouldn’t be tuning a leaderboard, reminder, or recommender to push those numbers up.

PRINCIPLE 2: EARN ATTENTION. DO NOT FARM IT.

What this looks like when we design

BUILD

DO NOT BUILD

A learner sets a goal of five questions a day and can change it

A warning that says do not lose your six-day streak

A teacher shows a small mastery highlight, and each student can opt out

A leaderboard that ranks every student from first to last

Seven of ten activities completed, when completion is the only measure

Seventy per cent mastered, when the system knows only what was opened or submitted

P3AUTOMATE BUSYWORK, NOT JUDGEMENT

PRINCIPLE 3

Automate busywork, not judgement

Saving, formatting and collating need no professional judgement. Feedback, diagnosis and intervention do.

Some of what a teacher does all day costs time and nothing else. Saving, formatting, collating, chasing people for submissions. There's no professional skill in any of it.

The rest is judgement. Working out what a student has misunderstood, deciding what feedback will land, choosing when to step in. Automation should take the first kind away without taking the teacher out of the second.

The measure is whether the teacher's decision comes out both faster and better informed than doing it by hand. Speed alone invites rubber-stamping, and if nobody ever edits the suggestion we read that as a warning sign. Testing includes a known-wrong suggestion for the same reason.

THE SORT

Sort the work first

Busywork is designed out of existence. The teacher’s professional judgement is always respected and preserved.

A TEACHER’SWORKWHICHKIND?BUSYWORKAUTOMATEDGONE, NOSTEP LEFTJUDGEMENTTEACHERDECIDES,THEN SENDS
FIG 02 — SORT THE WORK FIRST. ONE KIND DISAPPEARS, THE OTHER GOES TO A PERSON.

We sort the work before building anything. Busywork gets designed away: autosave rather than a save button, batch actions rather than one at a time, sensible defaults rather than a setup screen. Judgement work gets built as a proposal the teacher decides on, so it never applies itself and they can see it, change it, or bin it.

The question we ask: which kind of work is this?

  • Busywork. Has the design removed the steps, or just moved them?
  • Judgement. Can the teacher see it, change it, and overrule it before it reaches the learner?

PRINCIPLE 3: AUTOMATE BUSYWORK, NOT JUDGEMENT

What this looks like when we design

BUILD

DO NOT BUILD

Auto-collate class submissions, flag missing work and total rubric scores

A marking view the teacher assembles by hand, opening each submission one at a time

Show AI feedback as an editable draft the teacher approves or rejects

Send AI feedback straight to the student with no teacher review

Place the evidence next to the proposed decision

Ask the teacher to approve a proposal without the information needed to judge it

P4ONE FOUNDATION. FIT THE ROLE.

PRINCIPLE 4

One foundation. Fit the role.

Students, teachers and administrators do different jobs on the same platform. The workflow bends. The foundation does not.

SLS has to work for every student, teacher and administrator, at the same quality, across every ability, in all four official languages. The obvious way to do that is to give everyone the same thing, and that's where it goes wrong: one rigid interface will fail the students who needed a different way in.

A teacher writing an assignment, a student doing it, and an admin setting up accounts are three different jobs, and they sometimes happen inside the same feature.

We split the design into two layers. The layer underneath doesn't do exceptions: components, layout grammar, accessibility, how things behave and what things are called. The layer above it is meant to move, and it moves through copy, imagery and content rather than through new components.

The questions we ask:

  • Is this surface generic, cross-role or single-role? Generic works the same for everyone. Cross-role means work passes between people, so we name every role in the flow and design each handoff around whoever receives it. Single-role means one role doing one job.
  • Is the change structure or expression? A new tone with the behaviour unchanged is expression, and we go ahead. Changed behaviour or naming is structure, and it goes for sign-off.

We reuse an existing pattern whenever it fits without a workaround, though that shouldn't keep a bad pattern alive, and we never fork a component just to change how it looks.

Then we test it properly. All four languages have to fit without clipping or losing meaning, and the core task has to work with a keyboard, a screen reader and the devices people actually have, including phones, low-end shared machines and projectors. A third-party tool can look however it likes inside, as long as the button that launches it and the route back follow our patterns.

WHAT VARIES, WHAT DOES NOT

Shared underneath. Different on top.

Behaviour, naming and accessibility contracts hold across every role. Density, sequence and tone adapt to fit each one.

HANDOFFHANDOFFSTUDENTTEACHERADMINSHARED COMPONENTS, NAMING, ACCESSIBILITY
FIG 03 — THE WORKFLOW FITS THE ROLE. THE FOUNDATION DOES NOT MOVE.
TEACHERAUTHORSSTUDENTCOMPLETESTEACHERREVIEWSWORK, EVIDENCE AND CONTEXT CARRY ACROSS
FIG 04 — A CROSS-ROLE FLOW IS ONLY AS GOOD AS THE STATE IT CARRIES

PRINCIPLE 4: ONE FOUNDATION. FIT THE ROLE.

What this looks like when we design

BUILD

DO NOT BUILD

Separate stages for teacher authoring, student completion and teacher review

One screen reused for all three roles because it is cheaper to build

School-level banners changed through copy and imagery

A new component per school level, made only to look different

SLS patterns at the launch and return points of a partner tool

A partner tool with an unfamiliar entry or exit flow of its own

P5MOVE COMPLEXITY TO THE RIGHT PLACE

PRINCIPLE 5

Move complexity to the right place

Put complexity where it costs least, without hiding the platform’s power from the people who need it.

Principle 1 protects the effort that learning takes. Principle 5 covers everything else: using SLS itself should take as little effort as we can manage. Every feature should be easy to find and easy to use. If nobody can find a feature, it helps nobody.

Extra features have a cost too (for more information, see the deprecation workflow from March 2026). Every button or setting on a screen is one more thing to read past for each person who doesn't need it.

Three ways to handle complexity, in this order

  1. Let the system handle it. Use defaults and automation so people don't have to set things up. For example, a new assignment could go to the whole class unless the teacher changes it.
  2. Put the rest one layer down. Keep less-used options behind a “More options” panel, such as rubric settings and late-submission rules.
  3. Keep only must-make decisions on the main screen. For an assignment, that's which class, which lesson and when it's due.

Click count doesn't decide depth. A clear four-click flow is better than a crowded two-click one where the user has to hunt for the right button.

Finally, match the complexity on screen to the user's job to be done. An admin comparing submission rates across 40 classes needs a dense dashboard. A student answering a question needs a clear and uncluttered screen: the question, an answer box and a submit button.

THE ORDER

System, then menu, then screen

Each step up the ladder spends more of the user’s attention. Take the lowest step that can carry the control.

TRY HERE FIRSTLAST RESORTBURDEN ON THE USERSYSTEMMENUMAIN SURFACEAUTOMATE ITDISCLOSE ON DEMANDKEY DECISION
FIG 05 — EVERY CONTROL HAS AN OWNER: SYSTEM, MENU OR MAIN SURFACE

The order is the rule: system automation first, then progressive disclosure, and the main surface last. Skipping a step is how frequent things end up buried and rare things end up on the main screen.

What the ladder is checking:

  • Every control has a clear owner: system, menu or main surface.
  • An automated decision can still be explained when someone asks.
  • A main-surface decision genuinely belongs to the user.

PRINCIPLE 5: MOVE COMPLEXITY TO THE RIGHT PLACE

What this looks like when we design

BUILD

DO NOT BUILD

Autosave with an honest saved state, and no setup at all

Ask every user to configure save behaviour before they start

Configuration density in an admin provisioning console

The same control density on a student activity screen

Module deletion placed deeper, behind a deliberate confirmation

A frequent teaching tool buried to make a demo screen look cleaner

BEFORE WE GO

Five principles, from memory

  • P1Smooth everything but the learning
  • P2Earn attention. Do not farm it.
  • P3Automate busywork, not judgement
  • P4One foundation. Fit the role.
  • P5Move complexity to the right place
Source trailReferences

  1. Bjork, E. L., & Bjork, R. A. (2011). Making things hard on yourself, but in a good way: Creating desirable difficulties to enhance learning. In M. A. Gernsbacher, R. W. Pew, L. M. Hough, & J. R. Pomerantz (Eds.), Psychology and the real world: Essays illustrating fundamental contributions to society (pp. 56–64). Worth Publishers.
  2. CAST. (2024). Universal Design for Learning guidelines (Version 3.0). https://udlguidelines.cast.org/
  3. Deci, E. L., Koestner, R., & Ryan, R. M. (1999). A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation. Psychological Bulletin, 125(6), 627–668. https://doi.org/10.1037/0033-2909.125.6.627
  4. Hanus, M. D., & Fox, J. (2015). Assessing the effects of gamification in the classroom: A longitudinal study on intrinsic motivation, social comparison, satisfaction, effort, and academic performance. Computers & Education, 80, 152–161. https://doi.org/10.1016/j.compedu.2014.08.019
  5. Johnson, E. J., & Goldstein, D. (2003). Do defaults save lives? Science, 302(5649), 1338–1339. https://doi.org/10.1126/science.1091721
  6. Kholmatova, A. (2017). Design systems: A practical guide to creating design languages for digital products. Smashing Magazine.
  7. Nielsen, J. (2006, December 3). Progressive disclosure. Nielsen Norman Group. https://www.nngroup.com/articles/progressive-disclosure/
  8. OECD. (2025). The demands of teaching: Results from TALIS 2024. OECD Publishing.
  9. Parasuraman, R., & Riley, V. (1997). Humans and automation: Use, misuse, disuse, abuse. Human Factors, 39(2), 230–253. https://doi.org/10.1518/001872097778543886
  10. Roediger, H. L., & Karpicke, J. D. (2006). Test-enhanced learning: Taking memory tests improves long-term retention. Psychological Science, 17(3), 249–255. https://doi.org/10.1111/j.1467-9280.2006.01693.x
  11. Ryan, R. M., & Deci, E. L. (2000). Intrinsic and extrinsic motivations: Classic definitions and new directions. Contemporary Educational Psychology, 25(1), 54–67. https://doi.org/10.1006/ceps.1999.1020
  12. Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257–285. https://doi.org/10.1207/s15516709cog1202_4
  13. World Wide Web Consortium. (2023). Web content accessibility guidelines (WCAG) 2.2

No comments:

Post a Comment