The Problem: This organizational design project was initiated due to the challenges the IBM Analytics design team faced during the development of Data Science Experience, a recently released product. After conducting a research study, we discovered misalignment and distrust between design, offering management, and development teams. This was partially because IBM's agile product development process does not leave room for design thinking. Without trust, clear deadlines, and alignment across disciplines, our IBM analytics teams will not deliver truly "human-centered" products.
Our Solution: I and two user experience designers at IBM Analytics Design Studio designed a workflow that we hope will facilitate collaboration across design, offering management and development on future projects. This workflow also leaves room for user research, prototyping, user testing, and multi-discipline product strategy sync-ups. We believe that if we can initiate a more structured and intentional approach to the product development process, then we can eliminate a lot of the pain points we experienced while working on Data Science Experience.
Step 1: Data Collection
We conducted four different empathy sessions with designers and researchers to understand their pain points and experiences with their current workflow. My teammates conducted interviews with team members in the SF design studio. I conducted interviews with design researchers, offering management, and development in the San Jose office. We identified pain point development and offering management had while collaborating with design teams. We identified design and research pain points, as well as ideas for improvement.
Step 2: Data Synthesis
I synthesized the insights from interview data, observations, and four different empathy sessions and abstracted them into high-level themes. For a more in-depth understanding of my process and insights, check out my blog post!
Here are our insights at a high-level: Between design teams we felt strongly about having better shared research resources and better justification for design decisions. When collaborating with Product/Offering Management, we felt strongly about the lack collaboratively developed roadmap and felt shut of conversations with clients. We also were unclear of what an offering manager was responsible for, and how they were supposed to help us as designers. With development, we often felt that design decisions were made without the input of design, and we struggled to meet agile delivery dates. We were often out of sync, which bred resentment. We began to map these pain points onto an as-is product development journey map.
I did a deeper research study into the as-is collaboration process of user experience designers and user researchers. (To read more about this design/research collaboration study, feel free to checkout my blog post!) At a high-level, I consolidated insights from the study in order to create an as-is journey map of IBM's design/research collaboration workflow. I mapped out pain points in the as-is process and ideated a to-be scenario to improve future collaboration processes.
We started to define our process by creating ‘to-be’ goals that emerged from our research. Problems we noticed, like the lack of clear deadlines, led to the high level goal of having a collaboratively defined roadmap. We began to break these goals into phases, and then tried arrange them into a workflow.
Step 3: Ideation
We ideated phases, and the actions that we felt should be covered in them. For each phase we defined the team and their workload, the actions that should be taken, and the outcomes that are required to move to the next phase. We combined these phases into a high-level workflow.
Here is an outline of our to-be scenario:
In the foundation phase, there is participation from each team. At a high level, this first phase is for team building, rule setting, and an introduction to the user. The foundation phase is especially important to us because it addresses the lack of alignment we experienced so much during DSX. This is something we also felt needed more structure than what we saw in the current IBM design thinking process. The activities listed under the foundation phase help teams set the tone for working with one another, including things like defining roles, and setting a schedule together.
The design phase was created to better protect the design thinking process when there is pressure to move at an agile pace. This phase is reserved design thinking: this is for immersive research and ideation. We specifically put the project roadmap as an outcome in the design phase, so that our knowledge of user needs can inform how we roll out features. We also have a hills workshop in this phase so the three teams can reflect on research together and be informed as they author the product hills. Hills are a part of the IBM design thinking vocabulary that are used to reference a particular user need across a team.
The development closes the cycle. This final phase is for implementation and measurement. Development owns the delivery playbacks in this phase, these should be built on style guides provided by design. These style guides should be maintained and updated as user testing and design reviews expose breaks and inconsistencies. The outcomes of this phase are tactical.
Step 4: User Feedback and Iteration
After designing a high-level workflow, we asked asked the two IBM design studios (Austin and Germany) to follow a similar process of identifying their current pain points and ideating "to-be" scenarios. At a multi-studio meeting, our SF design team reflected and listened to their experiences and pain points. We then presented our workflow and received constructive feedback, new ideas, and support for our project! After the meeting, we synthesized the Germany, Austin, and San Francisco, and San Jose design studio pain points, and iterated on our designed workflow.
After aligning across design studios on the high-level workflow, we had a workshop with development and offering management leaders for feedback and input on our designed workflow. During this multi-discipline workshop, we needed to emphasize that the purpose of our designed workflow was not to force teams to to follow a similar process, but rather provide a starting point for teams to work off of and tailor to their team/product needs. Developers and offering managers freely discussed their pain points collaborating with designers and provided feedback on our workflow. We collaboratively ideated new activities that could be incorporated into our workflow.
Step 5: Final Design and Outcome:
We purposefully designed our final graphic of the workflow to be very high-level and use "non-design" terminology. This would make it easier for non-design teams to quickly understand, brainstorm around, and give feedback on our first iteration of the workflow. Additionally, we used a gantt chart design so non-design teams could quickly make adjustments to the structure of the workflow.
This product development process will be shared at future project kick-off meetings the SF Design team will participate in. Designers, developers, and product managers on the analytics team will use this workflow as a starting point to discuss pain points, expectations, and define collaboration/"come-together" points during the project cycle.