Building a Shared Language
When we start a project at DockYard, we rely on a process that we refer to as ‘Discovery.’ This exploratory period occurs at the start of an engagement and helps to uncover the parameters of a project. We treat discovery as an opportunity to identify stakeholders, business goals, project requirements, user types, communication expectations, etc.
During a discovery we select techniques to help distill out problems. These problems then inform decisions for building a product. Over time this process has gotten more efficient but I wouldn’t say it’s gotten easier. Strictly because every project drums up a different set of problems, each unique to the design and the industry we’re designing for.
Recently, our design team read Practical Design Discovery, a great resource, chock-full of strategies and techniques for running a valuable discovery. One section that I found interesting talked about “building a shared language.”
A crucial component of discovery is understanding - understanding the people, the users, & the problems. For this, we rely on language. However, as with any new project comes a glossary of new terms often referenced while explaining a project’s goals. If it’s an unfamiliar industry, this can be confounding, almost like being in a country that is foreign to you.
The most recent discovery I was a part of was for a project in an industry very foreign to me.
Before discovery had started, we prepared by reading a few materials including project goals, user descriptions, and desired functionality. It was quickly apparent to me that there was quite a few terms that I was unfamiliar with. I immediately thought of “building a shared language.”
To help us get acquainted with the industry, I scoured the documents pulling out each unfamiliar term. I then dropped those terms into a document with space to the right of each item. During discovery we printed out the document handing it over to the stakeholders of the project. We asked them to independently define each term and its association to the project at hand, an activity that took maybe 20-30 minutes.
The results were insightful. These definitions helped outline expectations for delivery. It shed light on alignment between stakeholders. It showed us that these terms could mean something different for each person, or that a discussion needs to happen to help bring people onto the same page. Not only was this revealing, it will also serve as reference material when we move deeper into the project. We can feel confident about decisions around functionality, because together we have agreed on the meaning.
Discovery is really about understanding and it always helps to be able to speak the same language.
Think your company can benefit from a design discovery or other UX support? Contact us.