Multi-Matter/Single-Matter Client Dashboard
Disclaimer: I cannot show aspects of this project because it contained sensitive information. I have redacted out sensitive information in my examples below.
The Problem
Attorneys were spending a lot of their workday on the phone with clients answering questions the clients could have looked up themselves if they had access to the correct information.
Strained the attorney-client relationship.
Answering these calls meant less billable hours, and less money generated for the firm.
1.
2.
3.
Dave
Department Head
The Team
The team I worked on operated as a start-up company within an AMLAW 100 Law Firm. We operated with the budget of a large company and flexibility of a startup. Our team used an iterative design process with start-up meetings every morning. When it came to brainstorming ideas for building mockups and prototypes, everyone was involved. We operated in a start-up manor where everyone wore a lot of hats and everyone’s opinion was valued.
Ed
Product Development Lead
The head of our department was a partner in the law firm. His role was to budget our team, network us with people across the law firm, help us navigate the business processes within the law firm, and helped us with brainstorming project ideas since he was familiar with the intricate details of the law firm, and legal issues that were not common knowledge for us. Our team often joked that he was our "idea" man.
Ali/Alex
Front End Developers
Our front-end developers were CS majors that worked with me most days. We would brainstorm ideas for our projects front-end design, and figure out how to make it work.
My team's direct manager was a serial entrepreneur that had taken multiple companies from start up to IPO. He knew how to build products, build a team, and run a project effectively. He is great at taking projects from ideation to ready-for-market.
Rachel
Legal Technology
Our legal consultant worked as the project manager of the team. She kept us on task in meetings, took notes, and kept us on deadlines.
Me
UX Designer
I worked as the UX Designer on the team. All the designs used in prototyping, and the final product were made by me. I also made personas and scenarios for the project. I presented our project with my manager to the attorneys that we worked with to build this product.
Drew
Legal Tech & Service Delivery
Paralegal who helped the team with anything we needed. Since my manager and department head were so busy all the time it was hard to ask them everyday questions about projects. Our paralegal was able to fill in those gaps. He had worked at the law firm for a while, so he knew his way around the law firm and had plenty of relationships we used to accomplish projects.
Disclaimer* I was working part time at this law firm through my senior year. In my final term, I was working Tuesdays and Thursdays. I went into work Tuesday for a normal day and the next day I was given notice that I was not permitted back into the office building due to COVID-19. So, I do not have access to any of the drawings, personas, scenarios, notes, or ideas for any of my projects at this law firm. I will be retelling the product's story and recreating prototypes as best I can from memory.
The Process
Phase 1 - Identifying the Problem
This project started because we were talking to the head of our department and he was complaining about the constant calls from his clients about “pointless” information they could have found if they just had access to it themselves. My manager mentioned creating a dashboard for all this information that clients and attorneys had access to. This continued for a while, with my manager and department head throwing out ideas. I would draw quick wire frames on paper of how it could look and how the functions could work together. Everyone in the meeting was contributing ideas from dashboards they had used in the past. We eventually had a long list of functions, and a lot of wireframes to use. This gave my team a great starting position to move forward with the project.
My team then started researching how we would build this dashboard. Originally, we looked into building a website that would host all of this information under the law firm's servers. This proved to be entirely too expensive. My team at the time was not equipped to handle a project that large without help. Hiring enough people to build that software and the maintenance cost was out of our price range.
So, we started looking into alternative options.
That is how we came across HighQ; it is a website like Wix but is specifically designed for law firms and accounting firms. All we had to do was come up with the idea and build it. This ended up being a cheaper and quicker option for our project. So, we bought a subscription and started building.
_logo_svg.png){kind=logo}
First set of Requirements
Access to Documents
All documents pertaining to the case in one place
Message board to post and answer questions
How should this information be displayed?
What information should be displayed?
How should access be granted to view this information?
Should their be a way to communicate on this dashboard?
With these early requirements we started brainstorming and designing our first prototype. Which ended up looking like this.
Questions
It was considerably basic, looked bad, and was not intuitive for beginning users. Also, the documents were not yet connected to the site because that was a months-long nightmare to get working properly. So, for now we uploaded the documents ourselves just to make it look and feel as intended.
We showed this to our department head, and he loved the early work and idea. He started shopping it around to some of the other attorneys across the law firm. Soon we had a few attorneys from different departments willing to work with us and be early adopters if the project continued.
Phase 2 - Working with Potential Users
We set up meetings with attorneys across the law firm to present our early design and ideas. Depending on how serious the meeting was I would present the project, but if it was a managing attorney or anyone higher within the company my manager would present. Then I would ask them questions to learn what ideas they had, what were deal breaker aspects of the project, and general thoughts.
These meetings helped by giving us an idea of a fleshed out final product with more defined requirements. It also expanded our project to a degree. This is the stage of the product life cycle that scope creep became a huge issue. Since we were defining our requirements as we went it was hard to draw a line in the sand on functionality. Generally we would try to implement every idea given to us. From there we would scrap the idea if it was going to be to hard to implement, cause work flow problems, or just wasn't an important function.
Second Set of Requirements
Create Multi-Matter Dashboards that have access to single matter dashboards
After talking with a few attorneys that had companies as clients we realized that we would need to build levels of dashboards. We decided to start creating dashboards with a multiple matters aggregated into one dashboard, with the ability to drill down into specific matters.
We met with a few managing attorneys that wanted to use this dashboard to check up on attorneys and paralegals billable hours. They wanted to have access to that data in one place and preferably in graphs.
In one of our meetings an attorney mentioned that his clients often bothered him about dates for court or the end of phases of the case. This gave us the idea to implement calendars and a “death clock” feature that counts down to important dates/events for each matter.
Questions, Conversations, & Revelations
Link the Firm database to the site to display data and graphs
Create a calendar with important dates pertaining to each matter
This whole process of meeting with attorneys and showing them our current prototype took a couple months. Each meeting with an attorney we would try to have as many new functions built into the prototype as possible so we could get feedback on it.
Phase 3 - Finishing Up
At this point in the project, we got the database connected, and we had the document network connected. We were able to start creating individualized prototypes for attorneys and their clients.
This is when attorneys started showing off these prototypes to some of their clients and asking for their feedback. We ended up getting some good ideas from this that we implemented. This is the point in the project that I started working on the usability and aesthetics of the site a lot. Since we were showing these to actual clients it needed to look good and work intuitively.
Ideas that came from the client test cases
One idea that came from a client was a "diversity tracker." This client had a clause in their contract requiring a diverse set of attorneys and paralegals to work on each case. We added in a diversity tracker for the company to check. They were able to look at significant data and graphs showing the diversity of billable hours put into their matters.
Another client had the idea to add in their social media feeds. This was more useful for certain clients than others but clients with large properties often had crimes take place on their properties. And the attorney could log in and quickly see what new cases would need to be addressed.
Final product: Ready for Market
The final product ended up having options for attorneys to choose what each client page will contain. We built a document with the options available so each attorney could order a page for each client, then we would build the site. Some attorneys wanted their clients to see billable hours, fees due, etc... Other Attorneys did not want their clients to have access to any of that information at all.
I finally made a HighQ website that operated as a “help site” detailing exactly how to make the websites and add in certain features. A lot of the final product used custom CSS/HTML/Javascript we wrote to work properly. A lot of other features used the HighQ creation tools in “hacky” ways to get the site to look the way we wanted. I made this site just so we had all of this in one location and because the product was ready to be scaled up across the firm.
Solutions & Results
Shown below is the main page of the Multi-Matter Client Dashboard. Displayed on this page is the macro data across all open cases (matters) of the client with the law firm. It also displays the client’s social media feeds in order to give attorneys easy visibility of client/company matters in real time. This page also serves a billing purpose by allowing the client to quickly see their billings and allows the attorneys to see how many hours they have billed, and which attorneys have billed those hours.
Main Page For a Company/Client
Single-Matter Dashboard
Shown below is a single case (matter). From the Multi-Matter dashboard clients and attorneys can drill down into individual cases (matters). This Dashboard shows a lot of the similar data points as the Multi-Matter Dashboard except only data specific to single cases (matters). This Dashboard also shows documents, important upcoming dates, key contacts, the team working on this matter, and a to-do list.
What I Learned
MMD/SMD was the first project I was involved with where a team collaborated, communicated, and worked with members across multiple departments to bring a product to market that made all parties happy. I learned how important team structure and culture is to building effective projects in efficient time frames. Prior to this all of my UX experiences were solo projects.
Through this project I learned how to read a company’s infrastructure and work together with people who do not always have a common goal.
On this project we were making a product for attorneys across a large firm who all had different ideas about how the product should work. We also needed to work with departments that felt like the creation of my team was stepping on the toes of their responsibilities. I learned to recognize leverages you have, finding the wants and needs of other parties, be willing to sacrifice positions/ground when necessary and using all these effectively to move the project forward.
When working and a law firm, you must realize they are all about their billable hours. That is how they are judged across the firm and chosen for promotions. Getting an attorney to take time out of their day to test a product designed for them is almost impossible, especially when they are billing +$200 an hour. You are asking them to give up a lot of money for little to no gain in their eyes. So, I quickly found that research was going to be near impossible to conduct on any of the projects. That was a challenge I had to work around at the firm. My solution was to learn as much as possible in meetings and use that to build basic designs that focused more on functionality than usability and aesthetic . Once we were able to nail the functionality of the project I moved onto usability.
I learned how to work with the resources you have or lack thereof.
What I Would do Differently
I wasted a lot of time in early meetings giving people prototypes that looked great and focused on usability ideas I had learned through class and readings. It quickly became apparent to me that the people I built this project for did not care about how it looked or that it had great usability. Their main requirement for the project was that it did the things they wanted. In the future I would discuss the requirements with parties involved and get a better ranking of importance for the requirements. This way I don't waste time in meetings discovering information I could have already learned.