A daring digital tool for a traditionally analog audience
The company I work for develops a virtual data room software called Drooms which caters to a very niche audience: Lawyers. A data room is a secure virtual space used for housing confidential data for different purposes, in the case of Drooms, our main focus is due diligence processes for Real Estate.
In previous years these type of legal transactions used to be done in a physical data room, which was basically a “physically secure continually monitored room, normally in the vendor’s offices (or those of their lawyers), which the bidders and their advisers will visit in order to inspect and report on the various documents and other data made available... Teams involved in large due diligence processes will typically have to be flown in from many regions or countries and remain available throughout the process. Such teams often comprise a number of experts in different fields and so the overall cost of keeping such groups on call near to the data room is often extremely high.” — Wikipedia, data room. Nowadays, this process has been digitized and due diligence transactions are being made online, through secure software such as Drooms NXG.
My design team is not big so each project is usually assigned to a designer who works together with a product manager to define and solve a feature. Last year I got the task to create a new feature for Drooms NXG, the Findings Manager, a tool that can perform complex searches within a data base of documents in order to find sensible pieces of information that require extra attention. This pieces of sensible information are called Findings. Droom’s aggregated value was that our software would learn from the user’s searching behaviour and it would suggest relevant findings without the user having to actively perform the search, therefore saving copious amounts of time. This sensible pieces of information though, live in the combination of theory and experience within each lawyers mind and in a majority of cases, extracting them is a task performed in a rudimentary matter: either by hand or using very long excel sheets. Not only the tool was complex to grasp but also, from the UX point of view, I had to earn our user’s digital trust.
Doing the research
In order to understand how the lawyers worked within the due diligence process, we invited some of them to do a workshop at Droom’s offices where our guests shared with us their working pipeline. I wanted to find out where and how did the findings came into play.
We pasted a big piece of paper in the wall and guided them into drawing their user journey, separate it in stages, pined down their iteration cycles and the requirements to consider this cycle closed, their team structure (which varies from Law firm to Law firm and in international deals, you can imagine the fun!) and the team dependencies. Turned out digging the Findings out of the data room was only one component of a pipeline that included hierarchical team work, collaborative creation of reports (drafts and finals) creation and sharing of content based on each team member expertise (findings), revisions and approvals, most of this work usually done analogically. From the point of view of our stakeholders, real value on the market meant digitizing the whole pipeline, which of course is our ultimate goal, but from the development point of view, we had to start somewhere smaller.
Given the rudimentary pipeline that our guests described, I understood that there was no tool in the market that unified all of this pipeline, and therefore it would be time consuming and risky to develop a feature to cover all of it at once. It became clear to me that the first version of our product should be a smaller version and not only deliver real value to our users within our technical and time restrictions but it also needed to be scalable into a more complex pipeline very soon after receiving the first feedback wave. What was a good, feasible MVP? How to ensure we were maximizing our design efforts into creating a solid base for expanding it later?
Devising the Information Architecture using Object Oriented UX
At the beginning I defined some user flows and managed to define three spaces in which all of the information should flow through: Templates, Findings and Dashboard. However, I felt that I didn’t have the full picture on how all elements related to each other to make sure I was not creating wrong dependencies or silos of information.
I knew I was dealing with an ecosystem of interlinked dynamic elements which would be displayed or not depending on the user’s hierarchy and role. Not too long before starting this project, I read about Sophia Voychehovski’s Object Oriented UX, which helped her structure CNN.com user experience around the election night, so I decided to apply her method and try to bring some light into my ecosystem.
Extracting the objects
I wrote down all the details that the FM was supposed to do in its ideal state and to extract from there the Objects of my system
I placed the objects of my system in Blue post-its and placed them without hierarchy one next to the other.
Defining each Object’s content
Now I would get to flesh out my objects, what were they? Only text? Some meta data? exclusive content or recurrent content coming from some other place?. Every piece of content that was exclusive to that object I noted down into yellow post-its and any metadata I wrote into orange ones.
At this point of the process not only I had a better idea of how all objects where linked but it also gave me room to better question my previous user journeys.
Nested objects
The next step was to uncover the existing relationships between the already laid down objects, this step was crucial for me in order to understand how my ecosystem lived, the real hierarchy of my objects and what was possible to do within it. Following OOUX I placed blue stickies whenever an object contained another one as part of their structure. This not only allowed me to see the dependencies between objects but also allowed me to establish possible entry points for different users depending on object relevancy for a given role. For example, for the Lawyer users it is important to dig right away into their task without losing focus, time is money after all, which is why the Findings and Suggested Findings objects would be important for this role. On the other hand, for the leader of the lawyer team it is important to see the overall task list and details on how the lawyers were progressing through all of the documents as well as starting to assemble the relevant reports, therefore the Task object and the Report object became relevant for this role.
I had a visual map from where I could define layers of information to be shown to our users depending on their role and which other pieces of information were linked to them. With this map I could discuss with the heads of departments which objects and interactions would form a good first product launch and not only that but they could see which information is linked to which object, making discussions about technical feasibility way more productive and bringing everyone into one page. By the end of it we decided to focus the first launch on the support of search and creation of Findings (findings, categories and suggested findings), leaving for a later release the collaborative part of the process (teams, tasks and reporting).
Shaping the tool
With the goals clearer for the team, I set up a user flow graph to determine how the user should move from object to object.
And, since we already have components in place for the front end of our software, I played with different arrangements of the elements.
At this point I started to worry about how to introduce so many new elements to our users, the words category and facts (back then that’s how suggested findings were called) meant nothing for them, the team was so used to think on this terms that other suggestions would sound silly and the way we used keywords to perform the search somehow felt detached of the way the lawyers searched through the documents. Overall there was an overload of information that hid the true value of the tool. I decided to step back and put myself on the shoes of our lawyers. They would look at our tool with disbelieve at first, the fact that we were already suggesting “findings” could be misinterpreted as pretentious instead of helpful. We had to be as seamless as possible to their way of working in order to present our solution as something they would feel non threatening and comfortable to handle. I noticed we were putting all of our attention into the Findings Manager’s dashboard, where all the fancy functionality would happen, and I thought, if I was a lawyer, I would start looking the traditional way, through the documents, not through a complex dashboard. So I decided to focus more on the first contact point of our tool, the Index. I translated the findings’ empty form to be available from the index and designed a tip based system of progressive learning as an onboarding for the creation of the first finding, that would serve both as content sample and a guiding hand towards the dashboard.
Following the same idea of tying the new flows and elements as much as possible to their manual pipeline, our list of categories shaped up as their literal, pen and paper written, list of subjects that they usually have to check through the data room in order to fill the report. Because they usually have to look for more or less the same subjects on each transaction, we would ensure that, having one finding created as a content sample and a list of known subjects as categories, we would have created a less alienating dashboard. From there onward I would use our tip based system of progressive learning to show how the tool worked and highlight the advantages of using it.
Testing our assumptions
No UX work is complete without testing. We managed to arrange a date with our lawyers for a testing session, which consisted of a prototype I created and these simple rules:
Speak up your mind, there is no right or wrong answer, think out loud! Everything you say is valuable for us to understand how you perceive the tool and for us to improve it. However, before each click, please tell me:
1. What do you see
2. What do you think it is for
3. What do you expect will happen once you click it
I recorded the testing sessions, gathered the feedback in a written document and later discussed the results with the team. Overall the feedback from the lawyers was very positive. As I thought, they felt puzzled when entering the dashboard first without having the Index as first reference, so they re-started the process through the Index and were able to follow all the way through the Dashboard. Some of the onboarding text was misleading so it needed fixing and we noticed that our preset categories would work for Real Estate German market but it was not a good base for other types of transactions such as M&A, which later fed the decision of selling the first release of the findings manager as an enterprise tool only to Real Estate German deals to start with.
Conclusion
The Findings Manager was released late last year and we are now receiving the first wave of feedback about it. Funnily enough some customers have already thought of other use cases outside of due diligence process! Re-purposing of design! :) A big take away for the team was that we lost a good amount of time talking but not listening to each other. For some reason at some point I realized each one had in their head a version of what the Findings Manager should be. It was not until I mapped the tool into objects that we could all talk on the same terms and we were able to understand each other and set realistic expectations. Of course Object Oriented UX was only a IA methodology that allowed this conversation to happen, but we are working now on implementing better kickoff meetings where everyone involved commits to invest their time and share their view with everyone else so that we all start (more or less) on the same page from the beginning. For this purpose I am reading Sprint by Jake Knapp. I will come back to you with my findings on that front ;).
For more information on the software, visit drooms.com
Comments and questions are welcome!
