Here we explore questions related to participatory or design-led approaches to (software) product design.
# Design Leads by Listening A common concern is that “design” should not lead, because good design listens, looks, and responds to people and context rather than pushing an agenda. This page argues that this is exactly why design *does* lead: not by telling stakeholders what they “should want”, but by doing the careful work of eliciting stories and needs, then proposing solutions that stakeholders did not explicitly specify, and iterating those solutions with them until they fit.
# What “leading” means in participatory design In participatory work, end users do not “lead” by dictating the design, just as they do not “lead” by dictating the engineering architecture. Stakeholders lead by contributing lived experience: stories, workflows, pain points, motivations, constraints, and feedback on prototypes. Design leads by synthesising that input into coherent interaction models and interface proposals that simplify complexity and support easy role-switching, and by surprising stakeholders with solutions that feel obvious only after they are seen.
# Two valid starting points An Engineering First approach often starts from business ideas, user needs, and system feasibility, then iterates prototypes that naturally lean toward System Architecture and implementation detail. A Design First Approach often starts from the interactions between stakeholders: what each person is trying to do, how they coordinate, where agreements are formed, where trust is needed, and what “good” looks like in practice, before committing to backend decisions. Both approaches can be iterative and participatory, but they differ in emphasis and sequencing.
# What a design-led approach looks like A design-led approach begins with collaborative writing and sketching with stakeholders, focused on interactions rather than screens. This includes mapping stakeholder stories, identifying moments where agreements are formed, identifying moments where exploration happens without agreement, and modelling how people move between roles. Only once the interaction model is validated with stakeholders should teams commit to backend, database, and architectural decisions, because those decisions should serve the validated interactions rather than forcing them.
# When building starts too early When teams jump straight into building and testing, they may unintentionally lock in an architecture-first interpretation of the problem. That can work, but it risks skipping early-stage design artefacts that help prevent building the wrong thing quickly. This is not a moral judgement, it is simply a difference in method and risk profile.
# The core reconciliation Design can listen first and still lead. Leading does not mean overriding stakeholders, it means doing the disciplined synthesis that turns stakeholder reality into simple, usable interaction proposals, and then iterating those proposals with the same stakeholders until they fit.