An Onboarding Experience For The Legal Space

Nicole So
Nicole So
Jul 19 · 25 min read

NLP (Natural Language Processing) Technology — the first hurdle me and my team face embarking our 2 week design sprint, what is it, what does it entail in regards to this project and what the UX does it have anything to do with the legal space? Hold on to your briefcases because this is going to be an illegally drawn out journey.

Let’s rewind a bit — So, we are hired on as an external design team:

Luke Jenkins — Lead Interviewer/Research, Michael Reiss — Account Manager/Research, Me — Scrum Master/Research

For a legal technology start up company (undisclosed for confidentiality request by party) that’s building a piece of software implementing NLP technology — still in development, designed to help lawyers and related professionals in the legal field with their pain points of finding the right technology/software solutions for the right problems. We are also given a brief that has all of the necessary details for the project as well.

Now, this is our first official client facing project and none of the members of my team knows anything about legal matters so it’s almost like a double dose of the ambiguity that’s served to us — the ambiguity of the field and the dynamics of stakeholder involvement.

But eventually we remind ourselves that it’s the same UX process, just another design challenge and ambiguities are inevitable that come with the territory. With that in mind, we decide to research as much as we can about what we do know according to the brief which is that this potential product uses NLP technology and that we should learn more about what it is.

We also compile a discussion guide for our stakeholders since it is essentially an interview to learn more about them, the product in development and company.

Day 1: The Case Of The New Brief

The very next day we have our initial meeting with the stakeholders and it’s an eventful one as they provide us with a Keynote presentation of who they are, what their company is about including target audiences and what the problem space they want to solve for is.

About Stakeholders:

One is a former lawyer and the other has multiple disciplinary backgrounds including Software Engineering and UX (very fortunate but probably not common for stakeholders to have a background in UX).

Company values:

“Technical but not techy”

“Data is important to us” — data driven services

“Add value without disrupting work flows.”

“Systems should be simple, intuitive and free from jargon.”

“Focuses highly on maintaining and fostering relationships with clients — doesn’t want to “memorialize” people like another legal document. No two legal agreements are the same and neither are people”

Target Audience Archetypes:

Flashy Firms — Doesn’t feel the pain points unlike the younger legal groups. Has money to spend on research.

Busy Boutique — Spends more time not doing the task — doesn’t get to do more work because solutions are not being sought out to make work efficient

Indifferent In-House —Avoids tech as much as possible

Indy In-house — Doesn’t have time to “seek out new tech”

Problem Space they are trying to solve with new product:

“Free legal teams from menial tasks”

“Ability to provide users credible solutions, thus gaining trust from users that they are seeking from a credible source, and discovery of new technology to aid them” (not 50 recommendations at a time but 2 or 3 viable options)

“People in the legal world just don’t have a lot of time to find solutions for problems and even if they do try they usually get like 50 different recommendations and gets overwhelmed with the entire process.”

“Lawyers are not seeking solutions”

After establishing all of this new information, they inform us that they will be diverging away from the original brief slightly and decide to show us an existing product which they’ve already developed and tested out on users. They also mention that showing us their existing product will serve more as a reference in learning the whole story of their problem space and company journey thus far.

About their existing product:

“A passion project of a tech-enthusiast lawyer and a law-enthusiast technologist — Law meets Tech”

  • Essentially an experiment website used to gather data about what is the best tech solution for any given pain points an attorney or anyone in the legal field might have — aka a type of software recommendation site.
  • Lawyers would go and get an assessment of their software needs in survey format that takes no longer than 10 minutes with 6 different departments to choose from — File Management, Document Drafting, Email Management, Legal Documents, Marketing, Billing & Timing.
  • At the end of the assessment, they would enter in their email. Currently, the stakeholders themselves would reply back to the incoming emails with a curated solution and suggested software advice that would best suit their legal needs.
  • What success looks like with this product: A user finishes the form, enters in their email, gets the solution and in return the stakeholders foster their CRM database with emails submitted.
  • Currently it is “broken”. Out of the 50 people they have tested this website out on, only 11 made it to the questionnaire page and only 1 out of that group completed it to the end to enter in their email.

Now with this all of this in mind they explain that they want us to design a completely separate product, possibly with a different name and not tied to survey formats, from what we will gather from the new research since their existing product is “broken”.

So, to reiterate, they wanted a new product with a different approach to better gather information about how law professionals make decisions on legal software adoption and collect emails for CRM database.


We inform the stakeholders during the meeting and the Statement of Work, that we compile afterwards, that we will need to investigate their existing “broken” product to design a product more accurate to users’ pain points without chances of revisiting similar design pain points — even if it is a completely separate product.

We stress that this will inform and give us more clarity moving forth. The stakeholder that has the UX background understands exactly why this needs to be done but the other stakeholder does not share this viewpoint and is a bit wary of us going back to explore a product that is “broken” when we should be conducting new research for the new product.

We do take the time to explain why this needs to be done (using the double diamond process as our anchor point) and that we are currently at the first half of the double diamond which is the research portion, qualifying exploration of any existing product to be valid. We also reassure our stakeholders that this is the usual process in the world of UX, to investigate the WHY’s, ensuring proper data-backed designs. Eventually both stakeholders meet us on the same page.


We take this initial meeting as a learning opportunity that there will be hiccups and changes within a start up company during product development. We also remind ourselves that nothing is set in stone until proper data is uncovered and becoming flexible with possible changes regarding the project scope would be the most ideal, given that it doesn’t contradict with data findings later on.

We discuss that our new design assignment is essentially a re-design since we are now working with an existing product as opposed to before with the old brief when we were under the impression that there was no existing product to research off of.

Moving forward we decide that it is prudent to set up our presentations and findings in a way where the UX process is clear and universally understood by all (showing the double diamond diagram in relation to different stages of design) and using data as our universal language to justify any design/process decisions.

Week 1: Immersing Ourselves In The World Of Law

After day 1, we decide it is best to make a spreadsheet, time-boxing every task since this is a 2 week sprint. We are also informed that one of our stakeholders is to be away for almost half of the sprint and we wanted to make sure we get both of our stakeholders in the design studio session if possible so time-boxing was very crucial in our early stages of our design sprint.

We are also given a list of contacts to interview by our stakeholders but since they are working legal professionals we are encouraged to find our own contacts to interview as well just incase. While we are waiting for replies from interviewees we reached out to we re-establish what we are solving for, in our own words, what our stakeholders have stated was the problem according to the research they have already done with their existing product.

We also perform a competitive analysis of currently popular software recommendation tools being used by legal professionals. Before diving into it, we each drew out how we imagine the information would be organized.

Michael’s sketch (the layout we decide to go with)
Left: Luke’s sketch, Right: My sketch

Everyone generally has similar views on how it should be executed but we do end up going with Michael’s rendition of the potential layout since it was very extensive and well thought out.

We decided to evaluate 3 legal and 2 non-legal websites that offer product recommendation. We then took it digitally and compiled our findings after research.

After researching on all of this and getting to know more about various legal professionals via phone interviews we find out a lot about the world of law and the pain points that they deal with on a day to day basis.

Week 1.5: A Legal PIVOT — Designing for the right people is an important thing.

After looking over all of the data we compiled, we learn that we are solving for the wrong audience.

According to our interviews, lawyers are not the ones who care about software recommendations, they even tell us that they are not even the ones making the call for implementing the software changes. It is the knowledge management, supervisors or councils making these calls. They are not our audience and it also explains why our stakeholders have an existing product that is “broken”.

It is a product that our stakeholders have thought would be useful for lawyers but all the data points to the fact that they are simply not the ones looking for solutions.

With our newfound revelation of uncovering the WHY of our stakeholders’ existing product not working, we found it very obvious that a pivot needs to happen. So we decide to make an executive decision to include our pivot and present it to our stakeholders on the day of the Design Studio meeting.

Week 2: Design Studio With The Stakeholders

We present our findings to our stakeholders the day of our in person design studio meeting using the double diamond as our backbone for the presentation.

We explain our need to pivot and follow our data into our newfound path geared more towards lawyers. We support our case by telling them the story of the $300,000,000 button phenomenon where users would drop off right before purchasing and how it is solved simply by taking away the registration button. It is uncovered that people really appreciate the option of registering later, so much so that sales rose 45%. We mention this as an example to highlight the power of the UX design process, what it can uncover and how powerful of a tool it is to act upon data findings.

Since time is of the essence regarding our project scope within the 2 week sprint and we have already used up the majority of the first week, we realize we can’t afford to embark on an entirely new research path focusing on people actually looking for software recommendations like Knowledge Management (meaning a different set of contacts provided by our stakeholders whom we have to reach out to, in order to continue trying to make a product for the right audience).

We make a proposal to our stakeholders saying that we will continue solving for the user group that the data says we can use which is the lawyers.

Our stakeholders appreciate that we uncover the data that we do and respect us following the data to the on-boarding direction that we chose to explore because it not only reveals why their existing product is “broken” but our findings also point to the crucial data of solving for the right audience which isn’t lawyers like they originally assume with their software recommendation route.

“You saved us three weeks of work.”


We proceed with our Design Studio meeting and present our persona, Mark, who we make from our user data synthesis shortly after our pivot, and his journey map through the commonly experienced scenario and task by legal professionals.

We present our brand new and revised problem statement to cater towards our newfound direction! It’s definitely official now.

From there we explain how we went about satisfying our new problem statement by presenting our greatest opportunity area for improvement in our persona Mark’s journey to our points of rationale that ties in with that.

We then explain the insights derived from users’ pain points on how it correlates to the potential features we would implement in our initial prototype and the commonly used best UX practices we would reference and incorporate into our design as well.

We finally get to the main attraction of our show — DRAWING PICTURES.

We demonstrate to our stakeholders a popular exercise of validating your drawing skills by warming up some simple shape doodles — courtesy of Luke for organizing these slides!

So then the 5 of us did 3 rounds — 6 bad ideas that won’t help us, 6 good ideas that will help and 1 great idea.

We are pleasantly surprised how quickly the stakeholders warm up in the design session and how both are not afraid to be open minded and silly with the sketch rounds. (I only picked out a few from each round to show below for the first two rounds and then everyone’s in the last round.)

6 ideas that won’t help: (2/5 examples shown)

My 6 ideas that won’t help! Poop emoji is my favorite!
One of the stakeholders’ sketches of bad ideas. My favorite is the bad sushi lunch!

6 Ideas that will help: (1/5 examples shown)

One of the stakeholders’ sketches of 6 good ideas — My favorite is the hair on the CEO.

1 Great idea: (5/5 examples shown)

Top two: Stakeholders’ sketches, Bottom two: Luke and Michael’s.
My sketch of the final round

Our final round really shows what some of the common trends within all of our sketches are that we can incorporate into our MVP such as the idea that there is a help center somewhere within the designs either through a question mark logo or a chatbot.

After the meeting adjourns, we quickly plan out the remainder of our design sprint via calendar, we aim to finish Paper and Mid-Fi designs and testing completely by Saturday which then we decide it’s prudent to start researching for UI like typography and color palette choices.


The next day, my team and I decide to design studio our Design Studio we had with our stakeholders and collectively combine all of the features and ideas we explored the day before.

Eventually after a couple of rounds, we decide to dot vote our choices with color markers for features we like in each others’ sketches. Everyone liked the idea of having a on/off function for a tutorial guide, an information hub/help center located in the bottom right corner for users to go back to later when they have additional questions and a confirmation system to advance to the next tip represented with CTA buttons of Yes (Y) or No (N) or thumbs up and down icons— exploring the idea of a walk through reminiscent of Google’s approach.

We bring our design together and take our final sketch to the whiteboard to lay out the screens. We appreciate Michael offering her stellar whiteboard drawing skills. I want to say most of the whiteboard pictures I have on my phone is her handiwork!

Michael drawing out our first MVP design which we would then transfer to our paper prototypes.

We make our first set of paper prototypes!

Hooray! (cue the confetti of colorful post its)— felt like a million years and a half for this creation to see the world!


Get ready to Iterate! We have two rounds of testing with our paper prototypes — 3 users for round 1 and 2 users for round 2.

We decide to include non-legal professionals in our usability testing to see if it is cohesive enough for anyone to understand which is essentially the goal you want for any product to be universal. We provided our users with a specific scenario and task to evaluate usability.

Scenario: You are a law professional. You receive an email saying your firm is switching to a new software system to help you with your daily tasks.

Task 1: You sit at your desk and open up the new software system. You have to create an account and quickly learn how to use the new tool through the guided walkthrough.

For the first round we find that we have issues with the initial welcome window.

We find that we need to refine our Lo-Fi prototypes and simplify our design as our users reveal their hesitation and confusion on what to click on first. (The idea behind this design was so that there were multiple learning options since not everyone learns in the same way/format. We do end up keeping some of the options such as the video tutorial since some users have expressed they prefer video over a walk through)

We find that this toggle function is a big pain in the design butt for us because we are so sure it would be as easily understood as any other toggle you see on products but it simply is understood as everything BUT what it is designed to be.


We decide to have two rounds of Lo-Fi testing because the feedback we were getting from our users just from the initial welcome window alone were putting some very important features into question like the toggle for the guided walk-through, which, if a user does not toggle that on it would be a very short usability testing. The walk through is basically the backbone of our concept for this on-boarding process. Another thing that we can’t afford to have users misunderstand is the overall design of the on-boarding process and the different options of learning since it is tied to the whole theory of the on-boarding process which is a major pain point we are solving for in the first place.

We refresh the problem statement legal professionals and Mark need solving in our minds and reaffirm our decisions to re-design our welcome window screens before moving on to the second iteration of testing


Paper prototypes — Final version

So we take our insights from Lo-Fi round 1 and make a re-design of our initial welcome window and only showcase the main features, minimizing the video tutorial and guided walk-through option down to buttons so it is visually consistent, concise and cohesive.

We proceed to round 2 of our Lo-Fi and get feedback on the guided walk through portion of the on-boarding more than the initial welcome window this round.

Besides the fact that the skip option is not entirely understood correctly, we speculate if the ‘Skip’ isn’t even visible (we even white out underneath the word ‘Skip’ to make the letters stand out more!) or if the Lo Fidelity of the prototype had anything to do with the visual translation. Some users simply state they did not even see the option to when asked about that after the testing.

We end up sacrificing the thumbs up icon next to ‘Got it’ to make more room to put the progress indicators within the confirmation windows. We discuss that it would be prudent to put an option to go back to the previous window in the case you don’t got it.


We’ve went ahead with our Mid-Fidelity with what we gathered from our paper prototype insights.

We separated the ‘Skip to Tool’ from the rest of the buttoned options so that it is easily accessible for those that want to skip the entire process and visually apparent that it is something different and not a learning option.

We make the option abundantly clear that users are skipping the walkthrough by putting ‘Skip Guided Walkthrough’ instead of just ‘Skip’ like before since users have expressed they are confused if they are skipping the tutorial or just to the next guided tip.

We tested out on 3 users total with same scenario and task.

Users now understand the initial welcome window screen but now an unexpected insight is gathered from one of our users wanting consistency in the placement of the guided walk through confirmation windows. It is a minor issue but we remember that it is a good rule of thumb to consider all of the users’ inputs. Since it is out of 3 users, 1 having an opinion on the flow of the walk through is significant enough to consider for investigation.


During our UI researching stage of the sprint, preparing for the Hi-Fidelity mock ups and advancing from our Mid-Fidelities, we have a long discussion about the logistics of going all the way to High Fidelity mock up. It doesn’t have anything to do with our project scope since we planned our schedule out long before when we just finished up with the Design Studio session with our stakeholders. It does however seem unnecessary to go all the way to the lamination when the print is still not solid, if that makes sense.

We make the executive decision to stop here and not progress with the Hi Fidelity mock ups because we remind ourselves that this is only an on-boarding process and “concept” that we are exploring for a piece of software that is still in the stages of development, meaning that the platform of choice is still being decided and for us to do a Hi-Fi mock up means that it isn’t a concept and very much a solid product to be sent into software engineering development.

With all of that said we all agree a higher Mid-Fidelity is more appropriate for this design sprint.

Week 2: Case Solved — The Light At The End Of The Tunnel!

We flesh out the Mid-Fi prototype more into a higher fidelity by designing a dashboard (after extensive research of best practices for designing a great dashboard) for our overlay window to nestle on top and actually be overlaying something aesthetically functional — inspired primarily by Clio, a widely used and highly rated dashboard application by legal professionals according to our research.

It would also help our users experience the dashboard concept more accurately in relation to the on-boarding process.

We also add an extra tab for Document Drafting to add more depth to our on-boarding experience and to inform the user that this is what to expect when you click into any of the tabs on the Project Dashboard.

We kept the video tutorial option for those that learn better in this format as some users have mentioned. Also, if there is anything I have learned from past group projects and usability testing is that users appreciate options to a degree whether they utilize all the options or not — there is definitely a fine line between too little and too many options (as we experienced even in this sprint with our original paper prototype) but there shouldn’t be just one route is the point.

There is now a ‘Turn on Tips’ section within the Dashboard page so that users can choose to have suggested pro tips on or off during their navigation through the dashboard. I would say this is a new and improved reincarnation of our toggle back in our initial paper sketches when it only applied to the guided walk through which we experience growing pains with due to poor translation.

We have also been meaning to have an overall help center incorporated into the entire on-boarding concept after our design studio with our stakeholders and seeing that it is a trend amongst all of our final round designs to have a help center of some sort.

It makes sense because we have always had the question mark icon as a sort of help hub in all of our fidelity versions and we have had discussions on how if a user were to press this question mark icon they wouldn’t necessarily be taken back to the initial welcome window since then it would defeat the purpose of it being a ‘welcome’ window.

We agree that this would be an appropriate thing to have that gives users even more options for further assistance. The chat with expert option would be a law professionals that would be available for legal software assistance in real time which we hope will be implemented properly in future fidelities.


We conduct our final usability test for this higher version of our Mid-Fidelities on 3 users.

We provide additional tasks surrounding our scenario to measure functionality (including our newest edition of the Document Drafting tab) and memorability using the guided walk through.

Scenario: You are a law professional. You receive an email saying your firm is switching to a new software system to help you with your daily tasks.

Task 1: You sit at your desk and open up the new software system. You have to create an account and quickly learn how to use the new tool through the guided walkthrough.

Task 2: Now you need to work on a task related to document drafting. Go to the Document Drafting tab and quickly learn how to use this feature through the guided walkthrough.

Task 3: You’ve completed your draft and now you want to check your performance metrics for today. Can you show me where you would go to find this?

For the tips notifications feature, the overall intent and function was successfully understood.

When inquiring about tips in general:

2 Users said they found tips helpful when using new software

1 User mentioned that they usually didn’t seek help unless an issue was encountered — indicating that it would be valuable thing to have maybe later down the line.

Users were quickly and easily completing the walkthrough task but they didn’t necessarily take in all of the information that they were learning from the guided walk through.

And the 2 Users who found the metrics said the walkthrough wasn’t even how they knew to find it but more so where it “might” be considering the limited clickable tabs within the prototype which only leaves one other tab that’s the home dashboard.

This is definitely a major issue as learnability is critical for this tool. So recommendations for this is to conduct more research and iterations of testing until there is an ideal walkthrough process that users will recall better while still being seamless overall.

3/3 users said text was clear and information was understandable.

1 User said it even reminded them of Google Docs on-boarding.

On the other hand 1 user had minor issues with button placement — specifically regarding the initial screens of the walk through.

As you can see here (point to screen), the previous button is not present in the initial screen but is in the following screen so when the user went to click ‘Next’ going to the following screen, they clicked previous by accident because the placement of the Next button wasn’t consistent.

Our recommendations for the future designs:

Keep button placement consistent to maintain that intuitiveness in the flow of steps. Also keeping in mind we want to make this experience to be as seamless as possible and setbacks like clicking the wrong button is playing towards our users’ pain point of being “pressed for time”

Colorful Road Ahead And Next Steps!

Before we knew we weren’t going to bring our designs up to the High Fidelity mock ups, we did do some research on colors and typography.

We expect changes would happen and that decisions for the style and colors would follow suit in the later designs but we decide to include our suggested style guide in our deliverables to the stakeholders to aid future concepts of where we originally envisioned with the colors and typography.


We conclude our design sprint with a series of next steps lined up. By this point our stakeholders have learned the value of the UX process and the power of user data. Most of our suggested next steps outline a lot more of the iterative design process to further render out their eventual product. We mention that it will help the process along if they finalize the details of the chosen platform and that if they decide to continue with our rendition of the dashboard route modeled off of what we imagine to be a desktop app then we have the research we did on dashboard best practices readily accessible to them via our deliverables folder in the shared Google drive.

What we learned after 2 weeks of legal matters!

The Day Of Our Final Presentation to the Stakeholders! From Left to Right: Luke Jenkins, Me, Michael Reiss

Never doubt the UX process! This was by far the most ambiguous experience — I felt fully immersed in the unknown. Dealing with a subject that my team and I had no idea about, to learning how to deal with stakeholders and changes with the initial project scope to the eventual pivot because our data was pointing us to the audience we didn’t expect — all in all we grew a lot from this on-boarding experience.

Also, it has to be said that there was low key a lot of pivots that happened in the span of 2 weeks that were not all properly acknowledged. My team and I feel stronger both physically and mentally after this experience (maybe a lot more mentally than physically)

Data also proves time and time again that it’s always there to save the day. This entire experience has also gave us a great simulation of how the stakeholder/client relationship works, the ups and downs of communicating clearly and how justifying our UX process to them in a universal context is crucial to get a mutual understanding — double diamond is your best friend when you are dealing with stakeholders! Finally, this 2 week sprint, though short in retrospect, taught us so many things such as how to make an iterative process out of exercising executive decisions in the name of data and the users.

To see our clickable prototype → HERE

To see more of my projects and related pivots → www.nicoleso.com

Nicole So

Written by

Nicole So

A professional doodler, foodie and UX/UI designer.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade