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.
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).