Contractbook is a software business enabling organisations to manage their contract lifecycle. Users can create draft contracts, share and sign them via digital signatures. This enables users to streamline workflows, avoid errors and scale legal operations.
This project's intention was to build knowledge of the existing product offering. The focus should be on product initiatives that 'get value to the customer as quickly as possible'.
Aim to identify existing issues and prioritising possible features that offer immediate value. This aim means our product delivers tangible value to users from the start. This will help to drive customer acquisition.
I employed the Double Diamond model to structure my work for this project. I began my discovery process by looking at existing product data. I observed quantitative data captured via Metabase and Pendo showing product performance statistics.
I explored recent usability testing sessions via the company's Jiminny library. By doing this I wanted to form user empathy and identify friction points and issues for evaluation. I watched an extensive series of user interviews to inform my understanding of the current product.
In this process I found an interview with a new customer whom on-boarded the product in the past 6 months. The interviewer begins the session by explaining a concept to help the workflow of customers called contract life-cycle management.
This process is where the user: 1. begins the process by creating a contract from a template, 2. conduct negotiations via a draft contract, 3. stakeholders sign the agreement that becomes the contract.
The user's test task was to create a draft agreement using a template from scratch. They populate the template with contract data ready for sharing with the necessary stakeholders.
The test task results found highlighted a collection of key user insights when observed.
These insights highlighted how this specific user felt about their experience of the product. Improvements made will help save them time. It will also significantly increase the overall quality of their experience.
The below diagram shows the pattern the test user followed within their workflow. In the usability test, this user kept moving from their created draft back to the homepage to restart the creation process.
From here the Navigation bar and the 'Create New' button link to different template pages.
The user became confused by these different options when trying to restart their process.
I returned to how the interviewer had described the contract life-cycle management concept. I reflected how this is easy to understand in principle. This introduces a logical workflow idea to any users new to contract agreement procedures.
In the current product this process isn't manifested within the software. It is not evident or clear to users where to begin their process. Or where to restart when trying to complete different tasks.
I highlighted this as a 'design problem' for deeper investigation. This framed a potential opportunity to incorporate within new design interventions.
To define the issues highlighted from my research, I explored the product in more depth. I focused on gaining more understanding about the current 'Create New' button.
In the fore-mentioned interview, the user had repeatedly selected this button. They assumed this was where they can restart their template creation process if required.
The 'Create New' button is a key component that is positioned in the top right of key product pages. As example, this blue coloured button has the same position and appearance in all three of the first navigation pages.
However, the button's dropdown options listed are different. The user hadn't seen this information when working quickly within their usability test.
I analysed each button to form more understanding of the available options. I compared each to gain a holistic view of their functionality and descriptions.
In the user test, the goal was to quickly find and create a new template. Working under time pressure, the user didn't read the long descriptions in each dropdown. Instead they vocalised a need to quickly find specific options.
I analysed the existing language of the three button dropdown descriptions. Below shows the frequency of how keywords apply across each dropdown.
Here I questioned if this would benefit from simplification of language and UX writing.
I found how currently 'Documents' are one of the key button names. It would be important to define what kind of contract qualifies as a document. Also, 'Documents' aren't included as a description within the contract life-cycle management concept.
I would look at possible renaming to this description. This would aligned the description to what this exactly is within the process.
I analysed the functionality and where each dropdown link currently navigated. I found duplication within some of the options. I was curious to explore if this could streamline to give more simplicity. I questioned if options located in the navigation might be remove from this button.
One idea to explore was if the homepage might also be a better location for presenting specific workflow options to the user.
Using the found insights and research, my intention was making the existing functionality clearer for the user. This way users can get quicker value from key starting points.
I began moving to the solution space and ideating with initial sketches. The intention was to keep labels explicit about their functionality.
This way each variant of the components would evolve to simplify the naming of key options.
I saw value in making the contract life-cycle management concept more explicit in the software. I began to explore how to make this idea more prominent in the homepage layout. This could be in the information hierarchy and features positioned within the navigation bar.
I critiqued my initial wireframe sketches with my design partner on the project. This helped validate my thinking process before further developing the wireframe designs.
This was vital for gaining feedback and for reviewing potential viable solutions.
One design intervention would be to position contract life-cycle management options within the navigation. Here a clear distinction exists between this process and associated actions and tools.
I combined these layout and navigation concepts within a mid-fidelity prototype. This positions existing contract developments chronologically with the newest placed top to bottom. Actions are present within the navigation placed in order from left to right.
A project goal was to bring more direct value with quicker starting point workflows. I took a cue from the existing /create-template page buttons and designed new components.
The components have large affordances and intend to quickly state their purpose. They position on the homepage for easy appearance and actionability.
I combined the different new designed elements within a high-fidelity prototype. This includes the iterative design of both the navigation bar and the 'quick value' buttons.
As this is a significant change to the homepage, it would be critical to test and collect feedback. I setup the new design as a Maze.co prototype.
I shared this with internal product implementation teams for gathering feedback and usage data.
An important piece of feedback was about measuring the new 'quick value' buttons. "Would these new buttons be accessed more than the existing 'Create New' button by users?"
This insight would need more testing to validate the findings and iterate the design accordingly.
After developing my ideas for the homepage, I returned to focusing on the 'Create New' button. My intention was creating a new component 'layering' variants of options available using microinteractions.
By making the component this way more than one option could be presented for a specific step. Using the hover state could give users more options for a given contract stage, such as Templates or Drafts.
I developed sketches to visualise how each state would change and reset on hover. This I shared with my design partner to review and refine. Following this I built a first collection of different component versions within Figma.
I continued to refer to the research and analysis I had gathered. This ensured I would consider how to more accurately label each state and component variant.
The initial prototype below shows the new button. This is now labelled 'My contracts'. This represents a consistent home position for the three key contract kinds available.
This is a quick, MVP prototype intended to work out the user flow and dropdown destinations. It helps to make design judgements about accessibility, UI considerations and appearance.
On selection the dropdown now divides into three sections, named 'Templates', 'Drafts' and 'Contracts'.
The design now has a single holistic dropdown. This embraces the contract life-cycle management concept and workflow.
Labels have much shorter descriptions, concisely indicating why to use this feature. The user hovers each of the three sections, displaying two actionable options in each instance.
Now the user is directly linked to a new blank template or draft. This removes the duplicated page from the existing flow.
This was where confusion existed for the user within my research. I would now install the new button across each of the three main feature pages.
This means the user doesn't need to go back to the homepage to find the 'new template' option as they do currently. This removes friction with all starting point options accessible in one consistent place.
To validate my designs, I tested the new button and dropdown in practice. I ran A/B tests for two prototypes setup using Maze.co. The new component was positioned in A. the current homepage, and B. my new designed layout.
The test participants shared a range of rewarding comments and ideas for review. Feedback indicated how each user begins the contract creation from different starting points. An opportunity might be if usage data could manifest into specific 'tailored' use cases. This way the new 'quick value' buttons would customise to present each user's 'go-to' workflows. This reinforced I would next need to deeper understand more use cases and build extensive user journey mapping.
This would help to understand where users enter the software in a specific stage of the contract negotiation process. As an example, when a user is a recipient to a shared draft contract for review.
This project concluded with a presentation to the design team and head of product. This product initiative would receive scoping for implementation viability. My proposed designs would next be assesses and aligned with the business roadmap and product strategy.
In review, I found concrete user-focused problems within the existing software. This came from extensive research looking into qualitative data. I explored and identified different viable solutions from user evidence. I reiterated my design ideas in response to feedback, using prototyping and analysis of captured data.
I am happy to have developed viable ideas for how to create and get 'quick value to customers'.
