Instead of starting with legal precedents like traditional construction lawyers do, we flipped the script entirely. We began by studying actual construction professionals at work, watching how they struggled with contracts, and asking a fundamental question: what do these people need from a contract to do their jobs well?

Think of it like this: most legal teams approach contract writing like they’re writing for other lawyers. After an in-depth analysis of the user personas involved, we decided to approach it like we were writing a comprehensive user manual for construction workers who need to get things built.

Our methodology followed a systematic three-step approach that you can apply to other complex problems.

Phase One: Debiasing through user immersion (Months 1-6)

The most critical aspect of our methodology was recognising and actively countering the inherent biases that legal professionals bring to contract design. Traditional legal training teaches lawyers to prioritise risk mitigation and precedent-following, which often conflicts with user-centred design principles.

We established a “beginner’s mind” protocol where team members were required to document their assumptions about what construction professionals needed before conducting any user research. These documented assumptions were then systematically challenged through direct user contact.

As a result, we conducted seven one-to-one user feedback interviews (conducted both in writing and via MS Teams) with specialised construction lawyers, civil engineers, and digital services providers. Our interview approach was carefully structured to avoid leading questions that would confirm our pre-existing beliefs.

Let’s share a few examples. Wrong way to ask: “Do you find traditional contracts too complex?” Right way to ask: “Walk me through the last time you had to reference a contract during a project. What happened?”

Our key question types included also:

• “Describe the last time you needed to check payment terms during a project”
• “Show me how you currently find liability information in your contracts”
• “What happens when someone on your team disagrees about what the contract says?”
• “What part of contract review takes the most time in your typical project?”

This phase was followed by systematic peer-review sessions focused purely on plain language simplification, ensuring that our legal expertise enhanced rather than overwhelmed user insights.

Phase Two: Business-first information architecture (Months 7-12)

Traditional legal documents follow a lawyer’s logic: terms and conditions, definitions, liability, termination. Construction professionals think differently: What am I building? When do I get paid? What happens if something goes wrong? Who do I call?

We conducted one comprehensive focus group exercise with representatives from construction engineering firms and contracts experts, facilitated by Sarah Fox. This session used mostly journey mapping to understand how different user types prioritised contract information.

Information architecture principles developed:

• Commercial information first: Payment terms, project scope, and timelines appear before legal definitions
• Progressive disclosure: Complex legal concepts are introduced only after establishing practical context
• Task-oriented grouping: Information is grouped by what users need to do, not by legal category
• Visual hierarchy: Most important information gets most visual weight, regardless of legal precedence

Phase Three: Incremental development with expert validation (Months 13-24)

Rather than developing the contract in isolation, we established a formal mentorship and review process that brought in external expertise at each development stage.

Sarah Fox, creator of the ‘500 Words’ contract series, served as our primary subject matter expert. Her role was to ensure that our simplification efforts didn’t compromise legal effectiveness. We established periodical review sessions where Sarah would assess our latest iterations against real construction scenarios from her practice.

We used Notion as our primary legal design technology tool, which provided several methodological advantages such as template modularity, visual prototyping, and faster turnaround with user testing integration. This technological approach offered new perspectives on contract structure by forcing us to think in terms of modular, interconnected components rather than linear legal documents. Here more details category by category:

• Modular thinking: Rather than writing a contract from beginning to end, we could design individual contract “components” (payment sections, liability frameworks, termination procedures) and test how they worked together.
• Visual-first approach: The platform’s visual capabilities forced us to consider how information hierarchy and layout affected user comprehension, leading to innovations like timeline integration and visual payment schedules.
• Collaborative iteration: Real-time collaboration features meant that legal, design, and technical perspectives could be integrated simultaneously rather than sequentially.

Wrap-up: Collaborative testing and iteration (Months 25-36)

We established an internal research group during the ideation phase, led by Marco Mendola and Denis Potemkin, supported by Sarah Fox and Tessa Manuello. This group combined expertise from the Majoto Beta Club with additional insights extracted from Fox’s ‘500 Words’ contract series.

Each iteration was assessed using three distinct requirements:

1. Clarity: Could construction professionals understand their obligations without legal interpretation?
2. Completeness: Did the simplified language maintain legal protection equivalent to traditional contracts?
3. Collaboration: Did the contract language promote partnership or create adversarial dynamics?

• Give people agency over their legal interests: Our tool is not an opaque algorithm that asks a few questions, then tells what to do. We empower lay people (and experts alike) to understand how legal conflicts can be resolved and that they need to prioritise their goals. This requires a certain level of engagement, but ultimately improves access to justice better than magic turnkey solutions.
• Take the “legalese” out of the “legal”: As much of the authoring is inevitably done by legal experts, we aim to always review our content through the eyes of a lay person. We explain legal jargon, avoid references and concepts that non-lawyers would not understand, and generally try to get rid of legal language wherever it is not absolutely necessary.
• Don’t oversimplify; stay transparent: We aim for “quality simple”: while we strive to make the tool and its use straightforward, we do not hide the complexity of the subject. Whenever our system applies filters or makes recommendations, we inform the user and provide means to understand the reasoning and to modify these variables.
• Be playful while remaining trustworthy: Legal tools don’t have to be dead serious. We try to inject some lightness, even gamification elements, while ensuring that they remain trustworthy and reliable. Decades of UI and usability research remind us that legal design does not have to look like an Excel spreadsheet or a court letter.
• Put user value before “lawyer habits”: Anti-patterns, such as asking users to accept a disclaimer before they even start, are lawyer-centric, not user-centric design. We don’t scare users away with restrictions before presenting results. Better still, we let the content itself convey its limitations. We want to make “legal” approachable, not intimidating.
• Collect as little data as possible: No one dealing with a legal issue wants to be profiled by unknown third parties. We ensure that our front-end never connects to other servers and that no user is tracked in an identifiable way. For our research, we collect minimal usage data in such a non-intrusive way that we don’t even need the dreaded “cookie banner” – that’s great UX, too!
• Keep it accessible and “mobile first”: Removing technical barriers is essential to lowering the threshold for the access to justice. Accessibility is part of the process early on (the “V” in MVP stands for “viable”; excluding users based on ability or equipment is the opposite of viable). We apply the “mobile first” dogma from web design to legal design; always designing with outdated, low-cost smartphones in sub-optimal conditions in mind.
• Simplify the tech stack: Over-engineering is futile. By keeping it simple, we ensure good performance, accessibility and universal usability. “Progressive enhancement” ensures that our application will even work on an old device with an outdated browser, aggressive privacy settings, and slow internet. Radical simplicity also makes maintenance a lot easier.

While succeeding in applying some of these better than others, the emergence of this set of guidelines is in itself an important outcome of our research. This project specifically aimed to identify solution spaces – and room for development and debate – where legal design and interaction design in combination can make law more accessible. The use of interactive media for legal guidance has a lot of potential, but it is also very easy for oversights in design and execution to become a hindrance to aspirational goals.