Design Artifact Library
Overview
This project was completed as part of IBM's Patterns Getting Started program — a selective, 6-week intensive where IBM designers are pulled off their day-to-day work to solve real business problems using Enterprise Design Thinking.
The Challenge:
IBM designers and product teams struggled to find and organize design artifacts (personas, journey maps, roadmaps, etc.) scattered across Teams, Box, and other tools. This slowed down projects, caused duplicate work, and made it difficult for new employees to leverage existing research.
My Role:
-
UX Designer on a cross-functional team (India, Canada, USA, Ireland)
-
Led research with real IBM users: designers, content designers, researchers, PMs, and executives
-
Collaborated across time zones to deliver end-to-end design solution
Project Scope:
-
6 weeks (full-time, dedicated work)
-
Real stakeholders and sponsor users from IBM business units
-
Enterprise Design Thinking methodology
-
Deliverables: Research insights, prototypes, experience-based roadmap for handoff
Context:
Patterns is IBM's flagship design training program. While educational in nature, projects are sourced from real business units with real problems. Our sponsor users were actual IBM employees struggling with artifact discovery, and our deliverables were designed to inform future product decisions.
Problem Statement
IBM is grappling with the task of organizing and making easily searchable a vast collection of design artifacts generated and used by designers and product teams. These artifacts encompass persona descriptions, requirements hierarchies, roadmaps, and task-object models scattered across multiple storage locations such as Teams, Box, and other tools.
The Process: IBM Enterprise Design Thinking (EDT)
Analysis & Prioritisation
TIP! These are anchor links that will scroll you down to that specific part of the page
Research
Introduction
Our first step was meeting our teammates and doing some icebreakers, our team was assigned by the Patterns team based on our project preferences and our skills.
We had a dynamic team of designers from India, Canada, USA and myself in Ireland. We all worked on completely different products and had never met before. While all of us were designers our day-day role varied from content design, visual design, marketing page design and UX Design. Timezones were a prevailing challenge throughout but we worked through that.
Research Plan:
Throughout this process we followed the EDT framework and used the EDT toolkit.
Goal: Define our goals and action steps to understand our users and address our team’s unknowns.
Pre-work:
We completed these activities at the start of the project to get our bearings and set expectations.
Assumptions & Questions: When your team needs a “reality check,” identify your assumptions and the best ways to address them.
Hopes & Fears: Learn and discuss each others’ hopes and fears before starting a project or on-boarding new team members.
Stakeholder Map: Identify project stakeholders, their expectations, and their relationship to each other.
Interviews
We connected with a varied group of sponsor users, such as UX designers, content designers, UX researchers, product managers, and an executive. objective was to gather insights into their viewpoints, experiences, and challenges regarding the discovery and storage of design artifacts. These discussions allowed us to investigate their existing approaches and obstacles, revealing crucial information that will guide our project's development. Their input is vital in crafting solutions that genuinely address the needs of design professionals.
Questions:
-
Can you describe your role and responsibilities with your team and organisation?
-
What do you consider a design artifact to be?
-
Do you create or use design artifacts?
-
How do you currently manage and store project related artifacts?
-
How do you utilize artifacts in your work? How often do you search for these artifacts?
-
What characteristics do you look for when needing to use a well designed artifacts?
-
Pain Points
-
What are the biggest challenges you face when searching for artifacts?
-
What are the most common problems that you recognize with your current artifacts?
-
How do these problems impact the overall project or workflow?
-
What strategies have you personally implemented to make this process easier for you?
-
Have you tried using centralised repositories in the past? If so, what has worked well and what hasn't?
-
Needs
-
What features would you like to see in a centralised repository for artifacts?
-
How important is it to be able to connect, link, tag or categorise artifacts?
-
What search capabilities would be the most helpful to you? (Eg, keyword search, metadata tags, advanced filters?)
-
Do you utilize AI in any way with these artifacts?
-
How often do you collaborate on these artifacts and how?
-
Is it important for you to have version control or track changes on shared documents?
-
Do you need artifacts from multiple devices and locations? How often do you access files on the go?
-
Success
-
What would success look like for you if a new repository system is implemented?What outcomes would you expect?
Empathy Maps:
Build empathy for your users through a conversation informed by your team’s observations.
Based on our findings from these interviews we created empathy maps for each person.
Pain Points, Insights & Quotes from our interviews
Pain Points:
-
Difficult to find what we need to find
-
Confused on where to start: slack? folder? google search?
-
No editor access to figma - cost associated (need to buy in)
-
Airtable library - accessibility problems + people outside BU do not have access
-
Having difficulty finding artifacts (new name, file location, and expired links)
-
There isn't consistent ways to find things
-
Lack of product culture surrounding the artifacts
-
Lost - Artifacts would be missing in meetings leading to miscommunication
-
Finds it hard to find Figma files
-
Having difficulty finding artifacts (new name, file location, and expired links)
Insights:
-
Version changes are important - how it's developed over time
-
Artifacts should be collaborative and visual
-
Gets notified via email when shes mentioned in a Figma comment
-
Artifacts are also non digital
-
Prefers the term "library" to repository for artifacts are always a work in progress and are truely never final
-
Dont want full public access to their artifacts
-
Well connected, knows who to ask, where to find artifacts
-
Writes down name of associated designer so she can contact them
-
Would be great if the purpose is defined
-
“Used in” text below the artifact
-
Definition of design artifact unclear and different to different people
Quotes:
-
"They're all in different places"
-
"Where do I search for it, how do I find it"
-
"It stretches the timeline"
-
"You dont know what you're searching for"
-
"If its named a different thing you wont find it"
-
"Not a clear difference between a design and research artifact"
-
"The most valuable thing an artifact an do is get buy in"
-
"People might not know they need a design artifact or that it could be useful for them"
Key themes from the interviews
Personas
Based on our findings from our interviews we created 2 different personas.
Persona 1: Designer
As-Is Scenario 1
We then mapped out the current experience this persona is facing.
"As-is Scenario Maps help to document collective understanding of user workflows and are best used as precursors to exploring new ideas or for finding the right problem to solve."
Persona 2: Product Manager
As-Is Scenario 2
We then did the same for our second persona.
More research & prioritisation
Second round of sponsor user interviews
We were very happy with the broad range of backgrounds and experience our sponsor users had, however there was one gap we had identified. This was designers, developers or PMs who were new to IBM. We had some great insight from employees who have been here a while and an observation we made was that because of their experience either just knew where to look or who to ask. But someone new to the company wouldn't have this knowledge, so we wanted to see how this problem was affecting them.
We interviewed 2 more users, both designers who were relatively new to IBM (>2 years), to get their perspective.
Empathy Maps
Now we had this fresh perspective we could keep in mind for the next phase, priositiation and ideation.
Big Ideas
Rapidly diverge on a breadth of possible solutions to meet your users’ needs.
We followed the steps from the EDT toolkit which were:
Step 1 Set up the prompt:
Begin the activity with a good prompt, such as a needs statement, a user story, a Hill, or just a pain point identified in an As-is Scenario Map. Write this prompt somewhere everyone can see it.
Prompts:
-
Designers, developers, PMs and executives need a way to access, reference, share, edit and use artifacts created as part of the PDLC.
-
There is no one central place to go to find an artifact right now, and there is no guarantee you'll even find it!
-
The current process to finding artifacts is slow and manual.
-
The context behind artifacts is often lost, such as when it was made, at what point in the process, who made it and what versions exist.
Step 2 Generate ideas, not features:
A big idea describes the experience a user might have with the solution. Features describe the implementation of a solution. If you find that your ideas are starting to depict features, try using metaphor: “It’s kind of like...”
Step 3 Diverge:
Create many big ideas and quickly share them with each other. Build off others’ ideas, but stay out of the weeds and avoid drifting into features or talking about implementation details.
Step 4 Cluster, title, & discuss:
Look for similar ideas and natural affinities. Move them physically closer together. As you do, name the clusters. Identify any clusters or individual ideas that stand out. Converge on a set that you would want to advance.
Step 5 Vote (optional):
Technically not part of the process but due to the time constraints we had as a team we voted on the most important clusters to prioritise. We voted on both importance and feasibility.
The result:
Now we knew the key themes from our ideas and what to focus on, from there we put these themes into a Prioritisation Grid.
Prioritisation Grid:
Decide your next move by focusing on the intersection of importance and feasibility. Again with very strong time constraints this activity helped us keep focus of what was most important but also most feasible. This was really helpful not only for our team and our work but it will also help guide the next steps and handoff that we conducted later on.
Competitor Analysis:
We then conducted some competitor analysis to see what other products are doing to solve these problems. We knew there were a couple of simply "artifact libraries" within IBM but we had advice from our sponsor team that we should look into Spotify too. This was really interesting as it was not something we had considered. The use case is completely different, an employee looking to use a tool to help find his colleagues work and help guide his own work. This was versus a product that is B2C, very mainstream and is mainly for entertainment purposes.
BUT crucially, while the outcomes or end goals may be different, the experience of finding and consuming content was actually really similar. The actual content was different but the main goals are the same, I want to find X quickly and easily.
To-Be Scenarios:
Draft a vision of your user’s future experience to show how your ideas address their current needs.
Based on all of our research, our ideas and our competitor analysis we drafted some To-Be scenarios for our personas - how we could improve their experience, save them time and make them more confident in their work.
To-Be 1 Designer Persona:
To-Be 2 PM Persona:
Hills
If you don’t know where you’re going, you might not get there. Use Hills to clearly state your intent in terms of user and market value.
"Hills describe something a specific user is enabled to do, not a specific implementation. They give teams the creative space they need to come to breakthrough ideas, without the need for detailed requirements. Write Hills at the beginning of a project or initiative, after you’ve identified the real needs of your users."
We wrote one main hill to encompass the general experience we are aiming for but we also included hills specific to PM and new designers based on our research.
Journey Map / Task Flow
We were then tasked with creating a journey map, however this wasn't your typical user journey map. It was actually the journey (or flow) of an artifact, essentially the lifecycle of an artifacts and all of the users that interact with it.
Prioritised Task List
We then created a task list, a list of tasks each user would like. We divided them by creator (someone who creates artifacts) and consuming (someone who consumes artifacts) and had overlap in the middle as it is very possible and likely a user would be both, depending on their context.
We then ranked these in terms of priority. Again, this was not only to help us in our designs and solutions but to also guide the handover and experience based roadmap that we would deliver at the end of the project.
Sketches
We used hand-drawn sketches as a powerful tool for quick brainstorming. This method helped us visualize different designs rapidly while incorporating insights from our research. By sketching out ideas, we ignited creativity and ensured our concepts aligned with user needs. The adaptability of these sketches allowed us to iterate quickly, leading to refined solutions.
First Draft
Homepage
Search + Filter
Artifact + Template pages
Versioning + Upload
Prototypes
We then used these sketches to help guide our prototypes. We kept these at low-fidelity, with the intent to use them for user testing and to get the ideas and concepts across, not be a fully designed product.
Prototype 1: Finding an artifact
(view in full screen)
Prototype 2: Finding a template
(view in full screen)
AI related designs for future phases
Experienced Based Roadmap
And finally, the last thing we did as a team is create an Experience Based Roadmap.
"Break down your long-term experience into the most essential near-term outcomes for your user."
As we only had 4 weeks to complete this project not only did we have to manage our own time and priorities but we also had to make an actionable plan for next steps and handover so the product can continue on and be taken over by other people.
Project Outcome & Reflection
What Happened Next:
We delivered a comprehensive handoff to our sponsor teams: research insights, prototypes, prioritized roadmap, and integration recommendations. The intent was for them to use this as a foundation if they decided to build an artifact library solution.
It hasn't been built yet — common with exploratory work. The value was in thoroughly investigating the problem and providing a clear path forward for future investment decisions.
What I Learned:
Enterprise Design Thinking in Practice
-
Full immersion in EDT with real complexity and tight timelines
-
Learned to balance research rigor with speed
Design Storytelling & Stakeholder Engagement
-
Regular playbacks to senior designers and business stakeholders
-
Learned to present complex research clearly and build alignment
-
Practiced defending design decisions to experienced audiences
Cross-Functional Collaboration
-
Worked across 4 time zones with designers from different specializations
-
Built alignment through async communication
Designing for Enterprise
-
Solutions must fit existing tools and organizational constraints
-
Well-researched ideas don't always ship — and that's the point of exploration
Applied to Current Work:
These skills now inform my approach on watsonx Orchestrate: EDT methodology for 0→1 thinking, stakeholder storytelling and alignment, designing for complex enterprise needs, and understanding what gets built vs. shelved.