Compare for Excel

Overview

Compare for Excel was the result of a carefully run research project that investigated the need for a spreadsheet comparison application in the industry and how it would drive future innovation for all desktop application at Workshare.

My role was to lead a team of designers to research and design Compare for Excel as well as coordinating with development teams to turn our vision into a fully functional product.

Along the journey, I established a refreshed design language which struck a balance between consistency and flexibility, worked with a developer to establish a series of reusable components that are now used across all desktop applications and developed a series of new design concept that are now patented.

Research

To kickoff the project, I organised a workshop with key stakeholders at Workshare to define our goals for the product and our success metrics. We brainstormed what our users may want to achieve and detailed the design process for the project following the Double Diamond methodology. 

User interviews

User interviews were run with users from various law firms across the United States, Australia and the United Kingdom. These interviews focused on understanding the needs and wants of our users and how spreadsheets are used as part of their job.

All of the information we collected led us to develop a deep understanding of our users and to gather crucial insights into how a spreadsheet comparison application could improve their daily workflow.

Personas

Our interview notes were combined into several hundred post-it notes that were then sorted into categories. We quickly identified three primary personas:

• The finance user

• The business user

• The technical IT user

From here, we could then begin to make statements about each persona we identified. These evolved into single page posters that were then shared across the team. These posters would remain hanging throughout the course of the project.

Beginning conceptual designs

During the initial design stage, there were dozens of different ideas of how the application could behave and what it could look like. These concepts started with simple sketches on paper and focused mainly on user flows. Very little work was done on the visuals in the beginning as the goal was to get the simple behaviours done right before even thinking about how to style the application.

Mapping out different workflows for different parts of the application allowed me to conceptualise rapidly. I would start with one workflow, sketch out a concept, introduce another workflow, test to see if the concept supported that new flow and make adjustments where necessary. 

Over time and a good amount of testing, a first version of a prototype of Compare for Excel was ready. This prototype was made interactive using InVision and ran through more internal testing with our sales, finance and customer support teams. This prototype evolved five more times, resulting in prototype six, which was used for the first round of external user testing.

Innovating upon the current suite of desktop applications

Workshare's suite of applications are some of the best and most popular applications in the legal industry. This makes it challenging when attempting to deliver a brand new application that needs to stand along side them. 

We needed to stay true to ourselves and acknowledge the years of experience our other applications have, but also have the freedom to innovate and push Compare for Excel forward. Our team was fortunate enough to be given the opportunity to test the boundaries and experiment with new technologies, design patterns and ultimately a new design language.

Over the years, our support and customer teams have collected an enormous amount of feedback from our users. This feedback was used in understanding what some of the key pain-points are in our existing applications so that we would try not make the same mistakes again. 

We also, for the first time, looked to establish a range of fully designed and documented components into a desktop application. This would ultimately speed up development, reduce bugs and improve consistency across the application.

First round of user testing

A final interactive prototype was created that would be used as part of a series of user tests with real world customers, most of them involved in earlier interviews. These tests revealed to us that the design decisions we took were leading us down the right path where much of the prototype would be brought into the final designs.

Some crucial feedback we received included making it clearer to the user what our colour codes represented, the inclusion of a formula bar at the top of the screen, improved copy in some areas, certain configurations that should be set by default and the ability to export the comparison.

Establishing the project

Once our user testing was complete, we moved to establish the team and project. I worked closely with Matt, our fearless product manager to begin breaking down our concepts into high level features that would ultimately become epics and to set initial priorities based on the outcomes of user testing.

We also defined the scope for the first version of the application. We wanted to keep focus on the key areas that were identified during the research stage in order to achieve the goals of Compare for Excel, but also to add the features and polish that we learned our users desired.

A team was established with highly experienced developers, designers and testers and we worked together to get an understanding of how we were going to deliver the application. We chose to approach the project following a modified Scrum methodology of two-week sprints over a period of around five months. The design team would work on features during a sprint and the development team would pick up the work the following sprint. This proved successful as design rarely blocked a development story. It allowed the team to develop rapidly as there was a reduced bottleneck from the design team. This also allowed the designers to focus on their particular story without the pressure of developers requiring designs, thus improving the quality of work.

Tools and platforms used

Jira
Our main project management tool, Jira was always open on our browser and was used to track the progress of our stories.

Confluence
Our primary area for documentation. The design team would work during a sprint to document the behaviour, styling and interaction of a feature which would then be referenced by both the developers and testers.

Slack
We sat together but still used Slack constantly.

Sketch
Our go to tool for design.

InVision
InVision was used in many cases, both for rapidly testing a workflow and to help explain a complex interaction. We would often build out an interaction in InVision and then screen record to form part of our documentation. This proved highly effective in helping developers and testing understand how the feature should behave.

Team dynamics

The design team for this project consisted of myself and two other incredible designs, Rahman and Isabel. For me, this was the first "official" time I would be taking lead on a project that also involved mentoring other designers. Working closely with the Head of Design and other senior colleagues, I worked to develop and improve my leadership skills by having weekly one-on-one sessions that would focus on areas I could improve and how to approach situations from the week before in an alternative way.

This proved to be highly effective for my own personal development as i was able to identify quirks that I could refine and set goals to continue developing my leadership skills into the future.

Working with others

This project would involve not only working with the design team, but also developers, product managers, QA, sales and other stakeholders within the organisation. 

The Compare for Excel squad was made up of seven core members with others coming in and out depending on the particular sprint and number of resources available.

In order for the team to be highly effective, communication was key. The team mostly sat together, with daily stand-ups, constant communication over Slack and detailed design documentation. There were always conversations happening in our little corner of the office between all members of the team. We were fortunate that our designers could sit right next to the developers and work together to discuss the feasibility of a feature or a way to improve the behaviour of a component.

It really was an excellent squad to be a part of and we all pulled together to achieve what many thought was impossible in such a short period of time.