Making Contracts Simple with Robin AI

As one of the first hires at the company and the sole designer, it was my responsibility to:

• Work with the founders to translate hypotheses into product and research goals
• Identify areas of disruption through user interviews and workshops
• Design, test and execute products that would look to solve user needs
• Clearly and effectively communicate those insights and visions to internal and external stakeholders
• Position Robin AI as product leaders in their sector

Leaning on the experts

It’s easy to fall into the trap of personal bias when designing products, but one way to mitigate that risk is by entering an industry in which you have very little knowledge. This made research and understanding the forefront of the design process and allowed us to firmly focus on the user in user-centred design.

Robin AI comprises SaaS and a Contract Review Service by legally trained individuals. This in-house expertise provided a solid basis for workshops and gaining an understanding of the problems faced by legal professionals.

Due to the complex nature of contract reviewing, we determined that we needed to create a database of interview candidates with their responsibilities and experience noted. By continually iterating on this process we were able to start cherry-picking the right candidates to interview and subsequently add more value to our research results.

Understanding existing systems

Before my arrival, an internal tool was created using a freelance designer. I spent time with the engineering team to understand what they enjoyed about the process, what they wish had gone better and together proposed a new way of working that would work more effectively for both teams.

This process allowed us to have complete transparency over what stages projects were at and when we were blocking each other. It also allowed us to loop them in earlier in the design process by giving them access to research, demos and presentations that were being proposed to the rest of the business.

Creating design systems

Creating a new product from scratch meant that we had a blank canvas to do everything to meet best practices. What that meant for me was to effectively communicate to the business the value of scalable design libraries and systems.

The pitch focused on where we wanted to be in a year from now, and the importance of setting standards that are competing with giants of their industry. We had one advantage, we would move fast. This teamed with the promise that we could build the next products off the back of the UI from the first and that we could generate high-fidelity prototypes at rapid speeds was enough to win them over.

With that in mind, I redesigned the MVP of the product using atomic components and worked alongside a front-end contractor. The design section was built using Figma’s library functionality and we landed on building the front-end using Storybook as our approval platform.

Facilitating discussion

It didn’t take me long to realise that Lawyers enjoy a healthy ‘discussion’. Knowing that, I set about creating a workshop to better understand where the default tool of choice was excelling and where it was lacking.

It was set up in the format of a debate whereby two teams would be advocates of Microsoft Word and how they couldn’t live without it and the other team provided criticism of its failings.

Once the feedback was collated from that discussion and there was fair discourse about what their needs were, it paved the way to get each person to write down the things that would make their lives easier in their current workflow.

The results were subsequently consolidated and discussed. Between the two data collection tasks, we had what they can’t live without, what they want improving and things that they would like help with in the future.

Problems not features

We all have things we want in life, but rarely does that align with what we need. It is my job to reframe what might be perceived as a want and understand where the problem sits in the wider context of things.

To better understand those situations, I would organise time on a 1-1 basis with lawyers and talk through what their process is to build up a user journey map. This allowed us to learn insights along that journey, identify pain points and ultimately uncover opportunities that we hadn’t thought of up until that point.

These tasks would then be repeated across a targeted selection of Lawyers and eventually, patterns would begin to unfold. By investing time this early in the process, it creates a solid foundation for the rest of the design process.

How to replicate the success

Creating a successful model when you have a small, well-organised team is within your own control, but when you want to grow the team and maintain those standards, you have to start documenting the things that come naturally to you.

This is what inspired the birth of the ‘Design Methodology’. Our design methodology is an ever-evolving approach to design problems that we face as a company.

• We begin by gaining a thorough understanding of what the problem is so that we can appropriately qualify the urgency and necessity of a task.
• We then look to define and focus our effort through evaluating the previously conducted research. This is done by defining specific contexts and desired outcomes of potential solutions.
• The third phase is about generating a broad range of ideas quickly while meeting the aforementioned happy path.
• The next steps are to turn those initial ideas into something that reflects the look and feel of the product so that we can use it as a platform to prototype and test.
• Prototypes are a great way of thinking about the individual steps of user interaction. This also provides the foundation for the usability testing to follow.
• Before handing across designs to the engineering team, it’s important to validate the concepts with the people who will be using the product and we can do that through usability testing.
• Once we have poured through the results of the testing we can make any appropriate changes, test again if necessary, and then complete a checklist to ensure that the engineering team have everything they need to get started.

Sharing insights

Part of the methodology includes regularly sharing insights and knowledge with the rest of the team. Operating transparently gives the organisation the opportunity to be informed and also have the chance to critique decisions. Some of our best features have come from being challenged and rising to that challenge.

Equally as important is how we work with Engineering and the rest of Product. We have created templates in our Notion workspace that ensure that each phase of the methodology is written out in a way that is easy for the company to read and is linked to the rest of the resources used in the designs.

Communicating designs

We then look to take things one step further and have created processes within our Figma designs that contain ‘narration cards’. Narration cards are explainers of what is happening along the journey. It is broken down into general notes, notes for Product Managers, notes for Engineers and also things that we want to track. This has been particularly helpful for the front-end team as they work through the design journeys to understand what is happening and the expected interactions and feedback.

One of the most recent initiatives is a big push on documentation. Designers haven’t traditionally been known for their documentation, but that might be down to how we determine what documentation is. Design documentation at Robin is a form of sense-checking the components that are being used, testing accessibility, creating cheat sheet copy and paste components and even explaining how to use the components themselves.

Working within Product

The product team consists of product managers, designers, and researchers. Each stakeholder has the opportunity to play their part in the product process.

The project is usually initiated by a problem or piece of insight that is gathered through sales, customer success, or user interviews. These insights are then weighted and rolled up in order to help us prioritise what to work on to help us maintain product market fit.

To help maintain alignment and transparency, we have established a centralised project roadmap database that contains the following:

• Research project database
• Conducted interviews database
• Interview candidate database
• Personas database
• Synthesis templates
• Discussion guide templates
• Processes documentation

Working with Engineering

The design contingent of the team will work with the engineering team throughout the lifetime of the project, from demoing concepts to ensuring the quality of the final builds.

However, bringing in the teams who are ultimately going to build the solution earlier in the process allows us the following opportunities:

• To understand the technical constraints of the task
• To encourage us to push the limits of what's possible
• To allow the team to plan engineering capacity in advance
• To provide context in advance of starting the work

Alignment with Marketing

Creating a product that people love to use and getting it into their hands are two very different things.

By working in tandem with the product marketing team, we enable a level of synergy that allows us to:

• Align on release dates for the team to work backwards from
• Collaborate on the go-to-market strategy
• Gain an understanding of our targeted marketing channels
• Plan for in-product promotions that we need to accommodate

Stakeholder Buy-in

Due to the hybrid nature of the company, stakeholders could be based anywhere in the world at any given time, so we've worked hard on creating an asynchronous feedback loop.

This is largely dependent on us designing for the stakeholders in the same way that we do for our customers. We take a lot of the heavy lifting and thinking out of it and we provide them with what they need to know in digestible bites. We do this via:

• One pagers
• Pre-recorded demos or prototype videos
• Design sign-off meetings for work prepped for release
• Go to market strategy summaries

New user experience

It's very easy to hide a product behind the safe onboarding process of a sales-driven organisation, but if you want to be product and data-driven, you have to have people using it.

To start gathering more authentic user data and take the steps towards a true SaaS tool, we made a free tier of our product available for anyone to sign up for and use.

As uncomfortable as that was, it allowed us to really dial in on what that new user experience was like and resulted in:

• A self-serve sign-up flow
• The integration of an onboarding tool that was designed and curated to show off the value of the product
• A review of the way that we track and capture data
• A more robust cookie policy.
• Being the first contract review tool that people could sign up for and start using
• An influx of new sales leads

Existing user experience

The beauty of a web-based product is that changes can be made without the user having to update their software.

This, however, presents an interesting opportunity for how we communicate those changes in a way that enhances and doesn't disrupt the existing user experience.

Here's how we did it:

• We created new in-app alerts that encouraged users to interact with the new functionality
• We promoted video tutorials of the functionality in use through social channels
• We worked with existing users to help them adopt these newly requested features
• We documented a series of help articles aimed at offering support when users reached an impasse

Growing responsibilities

As the number of products scales, so does the amount of work. We made the decision to put together a short-term recruitment plan to increase the headcount of the team to support another product with the view to scaling drastically post-fundraising.

The introduction of the new designer allowed me my first formal managerial role, but also allowed us to test the scalability of our design methodology. Throughout my time managing the team and the discipline I was able to:

• Create a Product Design Skills ladder
• Formalise 1-1s
• Represent design to the other stakeholders in the business
• Ensure that product, design and engineering are working together effectively
• Create frameworks for members of the legal team to conduct and assist with research tasks
• Creating a measurable link between the work the product team does and the company's objectives

Robin AI wants to be the leading legal tech company. To make that happen we are embarking on a period of sustained growth to support and improve the suite of products, while finding new and interesting ways to ‘make contracts simple’.

My aim is to support those ambitions through continuing to push the importance of research and design in business, while attempting to make Robin a design destination.