Increasing Productivity by 25%
In this case study, I outline the process and methods I used for designing a software integration tool that boosted the productivity of the largest department in my organisation by over 25%.
The Problem
One of the departments in my organization had multiple development teams working from three countries. Each team specialized in building specific software components and these components had to be integrated and tested regularly. Due to the size and spread of the team, collaborating with each other was a huge challenge.
Initially, the department tried to look for products that are already available in the market to help them collaborate and integrate their components. However, none of the existing products addressed all their needs. Therefore, they contacted the design team to build a custom-made product.
My Role
I was the UX lead for this project. I was responsible for leading the user research, UI design and usability testing phases of this project. Along with me, a UI designer and a front end developer also worked on this project.
User Research - Using Pictures to Overcome the Communication Barrier
The goal of my research was to understand the following.
-
How do developers collaborate with each other for integrating software components?
-
What information gets exchanged between them?
-
What problems do they face?
For this purpose, I had scheduled 1 on 1 semi-structured interview sessions with developers playing various roles in the department. During the pilot interviews, I realized there was a communication gap between me and the developers because they used a lot of technical terms, abbreviations and jargons when speaking. This made it extremely hard for me to follow the conversations.
In order to overcome this, I created a tool to help me with the interviews. This tool consisted of cards representing various roles in the department and the participants were asked to use these cards and narrate a story of how they work together to integrate software components. There were also some cards representing objects like servers and packages that the developers could use to represent jargons and technical terms. These cards helped the developers to break the ice and share more candid details about their processes and pains. In addition to this, having the process mapped out helped me comprehend their story better to ask follow-up questions.
Analysis
After understanding the process, pains and needs of each developer role individually, I brought them all together using the matrix shown below. This matrix displays the dependencies, issues and information required by each developer during every stage of the integration process.
Design
Using the information on the matrix I approached the design of the dashboard in the following phases. ​
-
First, I used low fidelity sketches to create concepts for visualizing the information required by each developer at every stage. These sketches were shared with the stakeholders and some key development team members to get their initial feedback.
.png)
-
Following this, I designed the information architecture of the tool and used this to organize the visualizations into screens that can be navigated through. These screens were prototyped into high fidelity wireframes and presented to the stakeholders for feedback.
.png)
-
Following the stakeholder feedback, these wireframes were updated and used to create the visual design which was prototyped and used to get feedback from the users through user testing.
Some Examples of How This Design Influenced the Increase in Productivity
A key finding from the research was, teams lost a lot of time in identifying components that were integrated between 2 versions of a build. This was because each team had its own way of keeping a record of their components being integrated into multiple products. To resolve this, I implemented an interactive timeline in the UI that expands on click to display all the changes done between every build. This timeline also shows the result of every previous build.
Another finding from the research was when a build fails, the developers had to skim through hundreds of lines of a log file to identify the causes of the failure before beginning to fix it. In order to make this easier, I implemented a table in the UI that lists all the errors that caused a build to fail. This table has a 'investigate' button for each error. Clicking on this will expand the table to display the section of the log file that triggered this error. Below this log file, the UI displays the description of the error and a probable solution using data extracted from an internal crowdsourced database.
.png)
Features like this helped the developers save a lot of time that was otherwise getting lost in collaborating and troubleshooting. This resulted in an increase in the number of components successfully integrated every month. This boosted the productivity of the department by over 25%.
Results
Initially, this tool was designed only to be used by one department. The tool slowly started becoming popular among other departments through word of mouth because of its features. Eventually, many other departments began using this tool without being mandated or advertised by the organization.
