Watson Health planned to transition to a Platform as a Service (PaaS) model, with the intent of having Watson Health developers lean into the open source in the future. As an introduction into this new frontier, Watson Health will create a new way to accelerate healthcare innovation through a scalable, open platform.
Project Length
1 Month
Outputs
Personas
User Scenarios
Road Map
Team Size
6
Watson Health aimed to create a service that sits on the current framework of Annotator for Clinical Data (ACD). Through ACD, unstructured clinical data is collected and packaged into analytics cartridges/data paks by the Watson Health development team. With the introduction of the new service, analytics developed in-house and by third-parties would be brought together in one place, where they can be accessed by any user for any use case.
In order to ensure the success of this future service, our team, consisting of six designers across IBM, conducted multiple rounds of research and ideation focusing on the development process for this platform and how it could be optimized for both in-house and third party developers.
Our team conducted secondary research by interviewing subject matter experts within Watson Health, analyzing the existing software that Watson Health intends to incorporate into the new service, and learning about the current end-to-end process for defining, developing and delivering software.
Early mapping of the development process at Watson Health, the gaps in team understanding and potential pain points
In the early stages of our process, our team found the most gaps in understanding regarding the developer experience. We received more insight into this area of impact by interviewing multiple development leads within Watson Health and conducting multiple rounds of mapping our findings. This led us to developing Jerry, our solution architect persona.
The key pain points identified Jerry's experience included the following:
- Technical requirements for the product were determined almost exclusively from a business standpoint and excludes the developer perspective early on, which creates communication issues down the development pipeline. As the project enters the phase of development, the feasibility of certain features are at risk of being lowered. Roadblocks begin to emerge and impact the project so severely that time to delivery is slowed.
-These issues compound especially when multiple projects are concurrently in motion, creating a stressful and undesirable experience for the solution architect overseeing the product development.
-Documentation through out the development process is also very inconsistent and siloed. Transparent is lacking between stakeholders.
These pain points happening simultaneously not only impacts our persona's workflow, but the workflow and production capability of Watson Health as an organization. Therefore, the core objective of our team was to create a strategy to improve the development process in order then solidify a more optimal process when 3rd party developers use the new service.
Jerry's pain points are summarized into two needs:
1) IBM Watson Health Architects need to be able to identify and address technical roadblocks early so they can prevent unexpected development issues later.
2) For IBM Watson Health Architects to be able to clearly communicate the capabilities and interoperability of WH services with other platforms to better serve those user's needs.
When Watson Health Architects can clearly communicate and work with other developers - the true power of Watson Health's new service can be unlocked!
After determining the ideal experience for the Watson Health solution architects, our team drafted immediate suggestions that can help improve the current development workflow:
One Management Tool
Jerry and the other teams involved in the development process would benefit from one holistic work experience, such as using an approved project management tool like Jira. This would allow them to oversee the progress of their projects and facilitate cross-functional communication, providing stakeholders with a central source of truth that will prevent issues that may come up much later down the road.
Documentation Template
Jerry and other team leads should be utilizing a standardized template for documentation, which would allow them to communicate the status of development and project roadblocks to team members and other stakeholders involved. Providing stakeholders with a documentation format will enhance everyone's understanding of any given project.
Routine Syncs
All team leads, including Jerry, should be consulted earlier and routinely in the project planning process. While the team does meet frequently, syncs are more directed towards alignment and addressing problems that stakeholders may not even know they have. This will allow key stakeholders to judge the feasibility of a project from their perspective earlier into the process, and will address any re-alignment needed throughout development.
We make additional recommendations through a roadmap showing the steps that should be taken later after implementing the immediate suggestions. We then presented this to the Watson Health product team, who are currently incorporating these recommendations into their roadmap as they continue planning for the development and release of the new service.