DDM: Discovery & design mapping-verktyg (DDM)

Resultat

DDM används aktivt i ett multinationalt B2B-produktprojekt och i mitt eget konsultflöde. Jag designade och byggde det för att hålla produktarbetet knutet till ett valt outcome: rankade opportunities i ett Opportunity Solution Tree, mänskligt ledda experiment, strukturerade designspecs och markdown-export innan prototypning.

Interactive demo

• Project site: https://project-rlsxp.vercel.app

Bakgrund

Produktarbete driver iväg när discovery, specs och prototypning inte är knutna till ett outcome. Över flera konsultuppdrag upprepades tre mönster. Det är svårt att få godkännande att göra research. När den väl är gjord bryr sig ingen utom den som körde den om råmaterialet. Stakeholders och teammedlemmar vill ha skarpa insights och tydlig riktning, inte transkript. Designers kör ofta egen research för att behålla kontroll och ägarskap över hela resan från research till feature. I praktiken betyder det att tidigare research ignoreras eller görs om.

Generativ AI lade till ett tredje lager. Prototypning med AI går fort, men när flera personer promptar från samma brief oberoende av varandra divergerar resultaten. Scope creep följer. Det fanns ingen gemensam ram för att koppla discovery-evidence till ett outcome, eller för att skriva designkrav innan någon öppnade Figma Make, v0 eller Copilot.

Jag har utvecklat konceptet parallellt: som sidoprojekt i mitt eget repo, och som ett separat verktyg för en kund med specifika säkerhetskrav. Det kombinerar outcome-led metoder jag använt som konsult med det produkt design kräver när AI är med i loopen.

Utmaning

På discovery-sidan hopar sig researchdata och feedback utan ett upprepbart sätt att omsätta dem till prioriterade opportunities knutna till ett valt outcome.

Produktteam som använder generativ AI saknar ett gemensamt planeringslager. Briefar kommer fortfarande fragmenterade: Jira-tickets, PowerPoints, PDF:er, skärmdumpar, ibland på olika språk. Beslut tas på intuition eller tidig övertygelse, och luckorna syns senare.

På designsidan förstärker generativa verktyg problemet. Samma mål, olika prototyper. Utan en gemensam spec driver variationerna iväg och AI-påverkad scope växer tyst.

Tre saker behövde hålla:
- Discovery mapping förankrad i evidence, där AI hjälper till med analys snarare än att ersätta omdöme.
- Strukturerade designspecs innan AI-prototypning, i samma anda som spec-it men för design.
- Markdown-export så att samma kontext fungerar i Figma Make, Spark, Copilot och andra verktyg.

Förutsättningar

Sedan hösten 2025 har jag kartlagt discovery-till-spec-flödet i FigJam och byggt verktyget parallellt, itererat på struktur och handovers och byggt om delar tills helheten höll ihop. Flödeskartan ovan använder påhittat demo-innehåll för att illustrera modellen, inte riktig kundresearch eller kunddata.

Angreppssätt

Uppdrag börjar med ett överenskommet outcome. Discovery mapping följer ett [Opportunity Solution Tree](https://www.producttalk.org/opportunity-solution-trees/?srsltid=AfmBOor0rTPPFAgmYZjg0sujtLX9Lq1rM0HvdTNdy1ZvqCglyYkrhTtL). DDM använder AI för att analysera befintlig kvalitativ research, kvantitativa signaler och feedback, och föreslår sedan opportunities som teamet kan ranka efter affärsvärde och genomförbarhet. Solutions och experiment förblir mänskligt ledda. Jag använder AI som bollplank för experiment, inte som idégenerator, eftersom den saknar full kontext och kan platta till det kreativa perspektivet.

Design spec mapping. Det andra läget går igenom problem, antaganden, edge cases, öppna frågor, scope-versioner och designreferenser i en fast struktur. Klistra in från Jira, möten eller PDF:er; AI fyller fält, men sektionerna förblir konsekventa. Export ger en markdown AI-brief: delad kontext för prototypverktyg så att olika designers och olika AI-utdata kan jämföras mot samma kriterier.

Jag designade och byggde verktyget själv. Det finns i två helt separata miljöer: ett repo för en multinational B2B-kund, ett jag underhåller för mig själv. Kundinstansen körs under deras GitHub- och Vercel-konton, med anpassningar för deras säkerhets- och arbetsflödeskrav; utvecklingen där är begränsad till VS Code. Mitt eget repo deployas via mina GitHub- och Vercel-konton, där jag jobbar i Cursor, mitt föredragna verktyg. Båda används aktivt: kundprojektet för teamets discovery och design mapping, mitt för vardagligt designarbete och fortsatt iteration.

Effekt

Team kartlägger från ett outcome via rankade opportunities till experiment i ett verktyg, i stället för över separata docs, decks och tickets. Specs exporteras som markdown för prototypning, så att designers och AI-utdata kan kollas mot samma kriterier. Där DDM används blir handovers enklare och research dupliceras mindre.

FigJam-flödeskartan och inbäddade demos använder fabricerat innehåll. Kundinstansen kör på riktig projektdata.

Reflektioner

Verktyget växte ur konsultuppdrag. Att hålla en sidoprojektversion separat från en kundbuild med säkerhetskrav lät mig iterera på metoden utan att blanda ihop ägarskap.

Att förankra arbetet i ett outcome var beslutet som fastnade. Opportunity Solution Tree för discovery och markdown-export för specs följde ur det. Den öppna frågan är hur mycket struktur teamkollegor vill ha när AI gör det lätt att hoppa rakt till en prototyp. Jag fortsätter förfina DDM för uppdrag där discovery och designarbete behöver en gemensam ram knuten till ett outcome.