The Linux Foundation
A self-serve legal workflow (CLA/licensing) and developer access flow for corporate members of The Linux Foundation. From manual, email-driven approvals to a docu-sign + CLA portal that records approval and grants repo access.
The Challenge
The Linux Foundation is a nonprofit that supports Linux and open-source software, with over 1000+ corporate members (like Google and Facebook). When a corporation purchases a membership license, their developers need legal approval (a CLA) before they can access Foundation-managed GitHub repositories. There was no online workflow to do this. Everything happened through manual email chains between legal and engineering, which caused delays, confusion, and no single source of truth. The brief was to: Design and launch a self-serve licensing (CLA) workflow and developer dashboard, So corporate developers can sign, get approved, and access code repos quickly, While giving legal and engineering teams visibility and control. ⚡ Challenges While working on this project, these were the main challenges I faced: No existing design system UI elements across past tools were inconsistent Had to first create a unified design library from scratch Multiple stakeholders with conflicting priorities Lawyers were hesitant to move approvals online Engineers wanted automation and speed PM needed to keep both sides aligned Complex user journeys with multiple edge cases Developers losing access whenever licenses updated Difficult to add/remove developers quickly Needed to track legal approval + GitHub access status together Organizational constraint This had to be built as a standalone portal, not inside the existing corporate dashboard (different team ownership) Change management risk Some corporations were used to manual workflows and might resist adopting a new system
Perfect — this is exactly how we can make your case study feel richer, more immersive, and more like a story, not just a report.
Here’s how we can expand the design process section and plan where to add visuals so hiring managers can see your thinking (not just read about it).
🧠 Expanded Design Process (Story + Visual Plan)
📍 Step 1 — Understanding the Journey
Goal: Figure out how developers currently get access and where things break.
What I did:
- Ran through the existing license approval process myself
- Collected screenshots of every email, form, and handoff involved
- Interviewed 5 developers from different member companies
Key insight:
There were 5–7 disjointed steps across legal and engineering, and no way to know where a request was stuck.
Add visuals here:
- 📷 Screenshot collage of the actual old process (emails, legal forms, spreadsheets)
- 📷 Journey map (Before) — swimlane showing Legal, Dev, Engineering
📌 Caption idea: “Mapping the current developer journey revealed major friction points and no source of truth.”
📍 Step 2 — Mapping Opportunities
Goal: Redesign the experience to be faster and clearer.
What I did:
- Turned user quotes into sticky notes and grouped them by themes (access delays, legal confusion, no status visibility)
- Created an affinity map → identified top priorities
Add visuals here:
- 📷 Affinity map board screenshot (sticky clusters)
- 📷 Key user quotes as pull quotes
“It took 9 days to get access last time.”
“We don’t know if legal approved someone or not.”
📌 Caption idea: “Grouping pain points helped us see that the bottleneck was legal approval visibility.”
📍 Step 3 — Designing the New Flows
Goal: Create a seamless experience for both corporate admins and developers.
What I did:
- Sketched low-fi flows on paper (to test with PM and legal quickly)
- Converted into mid-fi wireframes in
- Iterated 3 versions based on legal + developer feedback
Final structure:
- Admin creates an Organization CLA
- Adds/removes developers
- Developer gets invite → signs CLA via → system records signature → auto repo access on
Add visuals here:
- 📷 Lo-fi sketch of flow on paper
- 📷 User flow diagram (Admin + Developer paths)
- 📷 Wireframes: Org Setup, Invite, Developer Signing
- 📷 High-fi mockups of same 3 screens
📌 Caption idea: “Moving from low-fi to mid-fi let us quickly align stakeholders before polishing the visuals.”
📍 Step 4 — Building the Design System
Goal: Fix UI inconsistency across the company’s tools.
What I did:
- Created a mini design library inside their approved design tool ( Design)
- Standardized colors, typography, buttons, form fields, tables, and page templates
- Shared the system with engineers to implement
Add visuals here:
- 📷 Screenshot of color + type tokens
- 📷 Buttons, form fields, tables in states (hover, active)
- 📷 Page layout templates (wizard and list/detail)
📌 Caption idea: “A unified design system ensured the UI stayed consistent across teams and future features.”
📍 Step 5 — Final UI & Prototype
Goal: Deliver the end-to-end experience for launch.
What I did:
- Delivered polished screens and clickable prototype
- Supported dev team during implementation
Add visuals here (as a gallery):
- 📷 Org Setup wizard
- 📷 Developer roster screen
- 📷 Invite email
- 📷 Developer signing via DocuSign
- 📷 Success confirmation
- 📷 Legal audit record view
📌 Caption idea: “The final flow reduced onboarding time from days to minutes.”
📝 Why this matters
By showing the steps (sketch → wireframe → UI) instead of just telling them, you:
- Prove your design thinking and iteration skills
- Help hiring managers understand your decision logic
- Make your work feel tangible and real