top of page
the-legal-and-operational-consequences-of-redaction-failure.jpg

Identifying and Documenting IP

Designing an internal service to surface and structure hidden intellectual property.

Overview

This project focused on creating a framework to catalogue and manage intellectual property (IP) assets, improving how internal teams discover and document IP.

​

We conducted user research across departments, mapping existing IP documentation workflows, and identifyed critical pain points to help reduce IP Documentation time and streamline IP discovery process for internal stakeholders.

 

Working with legal and business teams, we aligned the solution with commercialization goals, resulting in a clear roadmap for IP utilization.

Lead UX Researcher, System Designer and Service Designer

Role

11 members

Team

8 Weeks (February 2025 - April 2025)

Timeline

Freelance Project with Ricardo PLC

Context

Figma, Google Forms, Microsoft Excel and Canva 

Tools

I. The Problem

Ricardo had three existing IP documentation frameworks. I audited all three and found the same gaps across each:

​

  • No business context. Frameworks tracked legal details — application numbers, filing dates, registration countries — but said nothing about business impact. There was no way to identify which IP was actually valuable.
     

  • No ownership accountability. Frameworks named applicants but not who was responsible for managing or commercialising each asset going forward.
     

  • Unregistered IP was invisible. Trade secrets, proprietary algorithms, and confidential processes had no documentation at all — not even informal records.
     

  • No cross-departmental visibility. Engineering, legal, and commercial teams were each working from separate spreadsheets with no shared language or process.

II. Research

I mapped the existing IP documentation process end-to-end through stakeholder conversations across engineering, legal, and commercial teams. Three things stood out:
 

  • Individual contributors — engineers and researchers — had no reliable way to know if what they'd created counted as IP. The question "does this qualify?" had no accessible answer inside the organisation. Most defaulted to doing nothing.
     

  • Two very different user groups needed different things. Individual contributors needed simple, guided prompts — they weren't IP experts and couldn't navigate legal terminology. Business unit leaders needed a higher-level view: portfolio coverage, commercial potential, risk exposure.
     

  • The friction was front-loaded. The biggest drop-off in IP documentation happened at the very first step — employees simply didn't know where to start. Once they had a starting point, they could navigate the process.

III. The Approach

1. The IP Questionare

A structured questionnaire was designed to help employees identify and document IP — available in two distinct versions for two distinct user groups.

​

  • Individual Contributor version — For engineers, researchers, and scientists working directly with potential IP. Written in plain language, question-by-question, avoiding legal jargon.
     

  • Business Unit Leader version — For department heads and team leads overseeing IP at a portfolio level. Focused on coverage, gaps, ownership accountability, and commercial direction.

2. IP Assisstant Chatbot

Diagnosing the problem revealed a recurring issue: employees didn't have anyone to ask. The legal team was inaccessible for routine questions, and "does this count as IP?" was a question people were asking on their own, often getting it wrong.

​

So we designed and prototyped an AI-assisted chatbot — the IP Assistant — built in Voiceflow. It draws on general IP knowledge. The long-term vision is to train it specifically on Ricardo's internal IP framework and documentation processes.

Screenshot 2026-04-28 171124.png

3. The IP Inventory Framework

I designed a comprehensive inventory framework to replace Ricardo's existing patchwork of Excel spreadsheets — structured to capture both registered and unregistered IP in a single, consistent system.

​

The framework is divided into two tracks:

​

  • Registered IP — patents, trademarks, copyrights with formal legal standing. Fields cover status, filing and renewal dates, legal challenges, registration territory, and responsible owner.

  • Unregistered IP — trade secrets, proprietary processes, confidential methods. Fields cover protection measures (NDAs, access restrictions), registrability criteria, and planned commercialisation timeline.
     

Crucially, the framework goes beyond legal metadata and also includes commercial metadata.

Screenshot 2026-04-28 175620.png
Screenshot 2026-04-28 175643.png
IV. What Made This Hard

This was a service design problem dressed as a documentation problem. The tools — questionnaire, chatbot, framework — were straightforward to design. The harder challenge was the cross-departmental translation problem.

​

Engineering, legal, and commercial teams used different language for the same concepts. What an engineer called "a new process" a lawyer might recognise as a patentable method, but neither had a shared vocabulary to start that conversation. The questionnaire and chatbot had to bridge that gap without asking either side to learn the other's language.

​

The other constraint was balancing legal accuracy against usability. Every simplification in the questionnaire wording needed to be reviewed against whether it would still surface the right information. That iteration — between clarity for the user and accuracy for the legal team — drove most of the design work

bottom of page