While working in the Legal products portfolio, I was asssigned to lead a project which allowed users to integrate our tools with a third party DMS. This would become an access point for users of any of our legal products to integrate their third party document management tools into our products, allowing access to their document repositories within our tools. It was a greenfield product and we were designing it from scratch.
The challenge deepened when we considered the end product to which users might integrate, as this could determine major changes per product integration. Our first TR product to be integrated was also a brand new product called Clause Bank that would allow users access to specific clauses within those stored documents. As such, there were many unknowns and we had number of discoveries along the way to a solution.
This case study illustrates design process I used while at TR. We began by defining the problems before work began and terms of success.
To the right, you see an example of that documentation which would help guide the project and be used afterward to reflect on its success.
To the left, you see an example of a workflow that we discovered as a user would step through adding a new document management system to the integration hub. This is a very basic flow a user must step through to begin working with the product. Because of the complexity of this project we defined at various levels of granularity the workflows of our users. This granularity helped to maintain focus on a particular problem at hand, and also allowed us to deliver easily understandable designs to the development group.
While this was a large project with many moving parts, it was important to keep the deliverables small to avoid confusion for our product and development teams. To the right you see an example of a small secion of screens that were separated from the whole to match a user story. We found that breaking out small pieces of work kept the flow for the development team easy.
Discovering the entire user journey from receiving an email invitation to adding clauses to documents was imperative for success on this project. Many iterations of flows were attempted along the way to finding the correct user journey.
These flows were built as part of a larger clickable protetype designed in Figma. A robust library of components was available to select from that helped build out the screens with appropriate functionality.
As we discovered the full user journey for our new products it was important to document them in an accessible manner.
This full journey was continually built on as we learned more and the new functionality was added to a clickable prototype that would be used to demonstrate new functionality to stakeholders and upper management to illustrate the improvements.
To the right, is a view of a user journey for one integration flow. In addition to the aforementioned small deliverables, this partially functional prototype was also used to explain to the development team how certain features would work and the interconnectedness of all the pieces.
As a matter of course, all the deliverables would be accompanied by responsive designs. This This would allow our front end development team to undertand how the designs would break down as users viewed the product on different screen types.
To the left, you see a series of mobile screens designed as part of this project.
This is a good overview of the process I used and the type of projects I worked on while at Thomson Reuters. I worked on a variety of projects while at Thomson Reuters some in the Legal space and others in Tax & Accounting. This is just one of many, but it serves as a good example.
The working methodology changed slightly between the various projects depending on the ability and tenure of teams with which I worked. Some teams were very helpful making insightful suggestions to improve designs and while other teams needed more design help and required more effort and research.