Domain Deep Dive
MY OBJECTIVE:
To rapidly build a deep understanding of the study building and conduct stage of clinical trials.
AT THE SAME TIME:
Study Designer Research
Process Building
Form Building
![]()
![]()
The study designer side of a form and how it appears in study conduct
To rapidly build a deep understanding of the study building and conduct stage of clinical trials.
AT THE SAME TIME:
Study Designer Research
Process Building
Form Building
Spoiler:
I am the design team’s go to person for questions concerning building and deploying clinical trials. And that’s not because I’ve been on the product the longest; it’s because I demonstrated within the first four months that I could build my understanding so that I understood the space as well as my cross functional partners. Demonstrating that I wanted and was able to understand all the details and decisions, built the team’s confidence in the design work presented later on. My expertise enabled me to educate seven team members about the space and document my learnings as a reference for the team.
In the beginning...
When I first started working on IBM Clinical Development, I had just begun to understand the definition of life scienes. To say that I started from nothing would not be an exaggeration. I knew that I needed to change my knowledge deficit fast, especially since I had to start on designs and research immediately. On top of that, I knew that the method, depth, and velocity of building domain knowledge would play a crucial role in developing trust with my new cross functional partners. Otherwise how could I expect them to trust any design decision, regardless of how well I explained it, if they didn’t have the confidence that I understood the space they worked in for their entire careers?
I am the design team’s go to person for questions concerning building and deploying clinical trials. And that’s not because I’ve been on the product the longest; it’s because I demonstrated within the first four months that I could build my understanding so that I understood the space as well as my cross functional partners. Demonstrating that I wanted and was able to understand all the details and decisions, built the team’s confidence in the design work presented later on. My expertise enabled me to educate seven team members about the space and document my learnings as a reference for the team.
In the beginning...
When I first started working on IBM Clinical Development, I had just begun to understand the definition of life scienes. To say that I started from nothing would not be an exaggeration. I knew that I needed to change my knowledge deficit fast, especially since I had to start on designs and research immediately. On top of that, I knew that the method, depth, and velocity of building domain knowledge would play a crucial role in developing trust with my new cross functional partners. Otherwise how could I expect them to trust any design decision, regardless of how well I explained it, if they didn’t have the confidence that I understood the space they worked in for their entire careers?
The How:
I started by organizing weekly knowledge share sessions with the design and cross functional team. Since the legacy product was extremely feature and setting dense, each session we could cover only a very small portion of the product. I would ask questions on every little detail: what was the original need, why was it implemented in that way, did it really require this much customization, what do our users think, did it successfully solve for the need, and so on.
Doing this enabled me to begin to see the intricacies of study building process, how a study is structured, and the workflow processes in the perphery that enable a study to run smoothly.
I also spent a significant amount of time building and deploying my own studies. Not only to experience what users did, but to also better understand the system. ICD is a highly customizable tool where everything you see on the study conduct side of the tool is a result of a setting in the study designer side. Beyond the forms for data collection; the navigvation, page titles, and even the iconography were all customizable and differed between studies. In order to truly understand the consquences of an action, I had to track it across both the study design and study conduct sides of the tool.
What’s the big deal?
The result was that these efforts formed the foundation of design team’s understanding of ICD. It enabled me to explore the product with intention and identify key areas to discuss with users. I was able to thoroughly and quickly build domain knowledge so that I could teach two consulting team members about the space and eventually onboard five more. And further down the road when we presented new designs, the cross functional team knew that our work had a sound foundation and better trusted it.
I started by organizing weekly knowledge share sessions with the design and cross functional team. Since the legacy product was extremely feature and setting dense, each session we could cover only a very small portion of the product. I would ask questions on every little detail: what was the original need, why was it implemented in that way, did it really require this much customization, what do our users think, did it successfully solve for the need, and so on.
Doing this enabled me to begin to see the intricacies of study building process, how a study is structured, and the workflow processes in the perphery that enable a study to run smoothly.
I also spent a significant amount of time building and deploying my own studies. Not only to experience what users did, but to also better understand the system. ICD is a highly customizable tool where everything you see on the study conduct side of the tool is a result of a setting in the study designer side. Beyond the forms for data collection; the navigvation, page titles, and even the iconography were all customizable and differed between studies. In order to truly understand the consquences of an action, I had to track it across both the study design and study conduct sides of the tool.
What’s the big deal?
The result was that these efforts formed the foundation of design team’s understanding of ICD. It enabled me to explore the product with intention and identify key areas to discuss with users. I was able to thoroughly and quickly build domain knowledge so that I could teach two consulting team members about the space and eventually onboard five more. And further down the road when we presented new designs, the cross functional team knew that our work had a sound foundation and better trusted it.
