As a content designer, I’ve half-joked on Zoom calls and over afterwork IPAs that it’s hard to describe my job to my parents. I’ve found my work will vary significantly based on a project’s phase in the UX design process. Where I’ve had the most challenge describing my contributions is in the discovery phase.
What is Discovery in UX?
In discovery, teams are researching a problem space and gathering evidence on what to do next. Discovery is usually broken out into discover and definition stages:
- Discover stage - the team asks broad questions and conducts research as they explore the problem space
- Define stage - the team aligns on findings to develop a problem statement and a vision for the future (e.g., concept wireframes to be developed in the next phase)
I recently completed a 12-week discovery (or strategy) engagement with my team at WillowTree where I mostly took a step back from familiar tasks like writing UX copy and collaborating on wireframes, and instead focused on more exploratory activities to arrive at a crisp outbrief for the client.
For context, we are working on an app to help graduate medical students (interns, residents) become more proficient in clinical reasoning, i.e., someone goes to the doctor with abdominal pain and the doctor asks questions and runs tests to try to diagnose them. Luckily, I have an M.D. so this was easy (I’m lying).
With this discovery scope in mind, here’s three lessons I learned about how I could best collaborate with the team.
I: Embed with Research Initiatives
Early in the engagement, our research director shared a learning plan that outlined the activities we would facilitate throughout discovery: SME (subject matter expert) interviews, market survey, diary study, and concept testing.
I loved the structure this document provided. For starters, it gave me clear direction on what was financially viable. If I wanted to run an independent content workshop, I would need to make a case to our business development team that the workshop was worth additional funding. In this case, I felt we could integrate content needs with the research initiatives.
The client provided a broad list of content types that help educate graduate students on clinical reasoning, like textbooks, illness scripts, and podcasts. We wanted to determine which mediums were most helpful and in what context. I conducted an internal audit of these items and consulted with an SME to drill down on their exact use cases. For example, I learned the podcasts weren’t typical long-form files but only 6 minutes long, meaning students could listen to them at the hospital rather than off-duty. This would later impact how we surfaced the podcasts in the UI.
I then collaborated with the research team to include questions on these mediums in the survey:
In this way, I was able to test the assumptions I made in my content audit against our research findings, and benefited from much more thorough data than if I had tried to run an independent workshop.
Collaborating with UX research is obvious, but I had never been in lock step with their initiatives like this before. From now on, I will advocate for working within research scripts for the efficiency and visibility it provides to the rest of the team.
II: Celebrate Overlap in UX Activities across Disciplines
We have a tendency in the UX world to break out tactical work by discipline. In discovery, typically, content design will conduct a content audit, researchers will write protocols, and designers will wireframe concepts in Figma.
These divisions make sense, but I believe there’s actually a cross-section of UX activities that any discipline should be empowered to take on, such as a competitive analysis, jobs to be done framework, preliminary journey map, or user flow diagram.
On this engagement, I worked on a competitive analysis of another clinical reasoning app, but I’ve found this is generally accepted as one of those “any UX disciplines can do it” activities - which is great!
So let’s consider a more design-oriented activity: the user flow diagram. On the onset, it makes sense that product designers would take this on, as it is a visual exercise and a clear precursor to higher-fidelity wireframing. But in practice, others on a product team should be able to take this on with some guidance, and a platform like Figma or Miro will usually provide a template to start from. I might not be able to diagram as elegantly as the designer (especially if we’re producing “wireflows”), but I can at least piece together a rough flow of boxes or screens that the team can fine tune.
Embracing design-oriented activities accomplishes more than just helping me grow as a UX professional. First, it keeps the project moving. If the product designer is swamped with work or out on PTO, other disciplines should feel empowered to do some of the heavy lifting. Second, it can help normalize a design focus for more junior content designers over time. Ultimately, this is a very visual field. I was jazzed about applying my journalism background to UX writing, but I would have been more impactful earlier in my career had I prioritized understanding design-related activities.
III: Embrace synergy and reaction
On UX projects — especially discovery engagements — there’s underrated value in dovetailing with others’ work whenever possible. Not just “collaborating” in the fluffy sense of being an amiable partner, but proactively being reactive: asking critical, tactical questions, and finding bandwidth to leave actionable feedback rather than doing a “quick pass”.
By taking a reactive approach, opportunities for ownership eventually reveal themselves. Towards the end of this engagement, for instance, I partnered with our solutions architect and engineer to explore CMS solutions for a particular product flow. They were driving the work by coding experimental content models on various platforms, but I was able to help define the scope of these models from my content audit learnings. We presented this out to the client, and they asked us to expand on that work by outlining how SMEs might engage with the CMS. I took ownership of creating a preliminary content governance model and editorial flow, but I wouldn’t have had that opportunity to lead if I didn’t assist our tech team’s efforts first.
Striving for a Permanent Seat at the Table
A common refrain among content designers is that we want to be brought in early and often on a project, not just at the point where lorem ipsums need to be filled in or the information architecture needs review. At WillowTree, my team opened the door for me well before those points in the UX process, and trusted me to expand my competencies according to client needs.
I believe this balance of team inclusivity and self-adaptability is key to standardizing the content design role as a consistent partner throughout the UX cycle. I’m excited to build on these learnings in future engagements and find new ways to evolve the breadth of the discipline.
