Dealstack
Role: Principal Product Designer

Client: LeaderAmp
Duration: 6 months
Role: Product Designer

Client: LeaderAmp
Duration: 6 months
Role: Product Designer

CAP Table module – product design

Redesigning an enterprise leadership coaching application

Redesigning an enterprise leadership coaching application

Dealstack is a B2B SAAS product that provides a single place where private equity (PE) deals live. It enables the process of creating (entry), managing (holding) and closing (exit) a deal. This lifecycle of a deal can typically last between 3-10 years. During this period a lot of parties can be involved and there is often a lot of flux in the individual's 'capacity' that they remain involved in.

The parties involved can be lawyers, deal managers (from the PE firm) and investors (institutional and individuals investing in an investment programme) all of whom are Dealstack users. The Dealstack customer though, usually is a PE firm.

LeaderAmp is an enterprise software that aims to enhance the performance of leadership teams in large organisations. It was founded by organisational psychologist Dr Matt Barney PhD based on academic work and experience of training leaders with an Olympic-style results-driven coaching approach.

LeaderAmp is an enterprise software that aims to enhance the performance of leadership teams in large organisations. It was founded by organisational psychologist Dr Matt Barney PhD based on academic work and experience of training leaders with an Olympic-style results-driven coaching approach.

CAP table

The Environment

The Environment

Capitalisation is the provision of capital (in this case ‘funding’) for a company.

A capitalisation table ('cap table') is a document, like a spreadsheet, table or chart, that details how a company is funded. A cap table also typically deals with related concerns such as ownership and control.

LeaderAmp was an existing app and a few years old. It had been built through a technology partnership with Dataphi Labs and had grown organically in response to ad hoc client needs. Dataphi recognised the need for a design-driven solution to organise the platform.

LeaderAmp was an existing app and a few years old. It had been built through a technology partnership with Dataphi Labs and had grown organically in response to ad hoc client needs. Dataphi recognised the need for a design-driven solution to organise the platform.

Cap tables in private equity

The Existing App Journey

The Existing App Journey

Within Private Equity, cap tables fundamentally address the same concerns as those that lie within 'venture finance' - funding, ownership and control.

Venture finance typically provides early-stage finance and so the funding picture is relatively simple - a limited number of parties exchanging a limited set of securities.

Private equity typically invests in larger, more established businesses, over a longer time horizon, so the sums of money are generally larger; the structures required to manage the interests of the various providers of that money are generally more complex.

At the point of ‘deal entry' it is common for a hierarchy or ‘stack’ of companies to be established to provide for tax-efficient flows of money into and out of the deal. Many of these companies are not 'operating companies’ - they do not have employees, they have limited access to cash - they are simply there to provide appropriate controls to some party who has funded the deal.

Hence where the capitalisation model for early stage funding (venture finance) is relatively simple - a single table, the capitalisation model for deals involving larger more mature businesses, via private equity, is relatively complex - effectively a hierarchy of related tables:

The app journey required selected employees of a company to first take an assessment, which told them their strengths and weaknesses (scales). Having identified their coaching needs, the app supported them to achieve and track progress. After a period of time they reassess their goals and generate a report to review progress. Users could then choose additional scales to focus on and repeat the cycle.

The app journey required selected employees of a company to first take an assessment, which told them their strengths and weaknesses (scales). Having identified their coaching needs, the app supported them to achieve and track progress. After a period of time they reassess their goals and generate a report to review progress. Users could then choose additional scales to focus on and repeat the cycle.

Users

The Existing App Journey

The Existing App Journey

The users of the Dealstack cap table include any party who is seeking to understand the funding, ownership or control of the target (aka the portfolio company, operating company or ‘OpCo'), or of any of the other parties within the associated deal structure (the 'stack’). These may include:

• Junior Partner (Legal Firm)
• Deal Associate (Legal Firm)
• Deal Captain (PE Firm)
• Contracts Specialist (PE Firm)
• Fund Finance Director (PE Firm)

It is also possible that some parties may have a view of a limited part of the structure, e.g:

• CEO (Target)
• CFO (Target)
• Board Member (Target)

The app journey required selected employees of a company to first take an assessment, which told them their strengths and weaknesses (scales). Having identified their coaching needs, the app supported them to achieve and track progress. After a period of time they reassess their goals and generate a report to review progress. Users could then choose additional scales to focus on and repeat the cycle.

The app journey required selected employees of a company to first take an assessment, which told them their strengths and weaknesses (scales). Having identified their coaching needs, the app supported them to achieve and track progress. After a period of time they reassess their goals and generate a report to review progress. Users could then choose additional scales to focus on and repeat the cycle.

Drivers (User Needs)

The UX Umbrella (Framework) for the app

The UX Umbrella (Framework) for the app

The user needs to be addressed by the Dealstack cap table module:

• Understand deal participants (any legal or natural person who is capitalised within the deal, or is providing capital to the deal)
  • Understand the participant in sufficient detail to be able to identify, and manage any necessary interactions with, that participant.
  • Understand the funding of each deal participant - what securities have been issued?
  • Understand the ownership of each deal participant - who owns issued securities, and what did they cost
  • Understand the control of each deal participant - who can vote on company matters, and in what proportion?
• Understand deal summary status (at the current point in time)
  • Understand the funding/ownership/control relationships across the whole deal structure.
• Understand deal history (summary status at a defined point in deal history)

Although the different pieces identified had their own challenges, to work apps need to be founded on an overarching UX framework (UX Umbrella). This allows users to move through the app on individual journeys, ensuring consistency of design and experience.

The UX umbrella needs to meet specific business needs and requirements. LeaderAmp needed their product to be flexible enough to accommodate additional features or to remove some (for some customers), without compromising reaching the goal of any flow.

Although the different pieces identified had their own challenges, to work apps need to be founded on an overarching UX framework (UX Umbrella). This allows users to move through the app on individual journeys, ensuring consistency of design and experience.

The UX umbrella needs to meet specific business needs and requirements. LeaderAmp needed their product to be flexible enough to accommodate additional features or to remove some (for some customers), without compromising reaching the goal of any flow.

User Journeys (High Level)

The Existing App Journey

The Existing App Journey

There are typically three types of engagement with the Cap Table

1. Creation - a focussed, more extensive, exercise in establishing a baseline of data regarding the structure of the deal. Happens once only, during deal setup/entry, typically led by a ‘Deal Associate’.
2. Update - an ad-hoc, less extensive, exercise in adding to or otherwise updating the existing set of data regarding the structure of the deal. This may be done following some meaningful change to the details of the funding, ownership or control of any entity within the scope of the deal. Happens periodically during the holding phase of the deal, again typically managed by a 'Deal Associate'.
3. Review - an ad-hoc check of the cap table data, to answer some questions or meet some other external requirement. Could be one of several dealstack users…

The app journey required selected employees of a company to first take an assessment, which told them their strengths and weaknesses (scales). Having identified their coaching needs, the app supported them to achieve and track progress. After a period of time they reassess their goals and generate a report to review progress. Users could then choose additional scales to focus on and repeat the cycle.

The app journey required selected employees of a company to first take an assessment, which told them their strengths and weaknesses (scales). Having identified their coaching needs, the app supported them to achieve and track progress. After a period of time they reassess their goals and generate a report to review progress. Users could then choose additional scales to focus on and repeat the cycle.

Various HI-FI screens of the flow

Assessment

Assessment

Entity creation / entity details screens

Assessment

Assessment

There are many different types of entities that go into the process of 'deal-making' in PE but mainly they can be classified as either a 'natural person' or it could be an 'organisation'. The details the user adds in this section will also allow the CAP table to create 'CAP structures' by identifying 'funds', 'target companies' and other such relationships with the stack of companies.

Before the user started the assessment, they took a Likert Scale questionnaire to calibrate the app. The new calibration screen adopted the same design language as the assessment itself, to get the user accustomed to it before they began the test.

Before the user started the assessment, they took a Likert Scale questionnaire to calibrate the app. The new calibration screen adopted the same design language as the assessment itself, to get the user accustomed to it before they began the test.

Securities screens

Assessment

Assessment

The basis of extablishing a financial trading relationship between the numerious 'stack of companies' is determined upon the buying and selling of securities. There can also be a variety of different types of these secutiers, the currencies they are traded in and also the voting rights they carry (which determine ownership structure).

Before the user started the assessment, they took a Likert Scale questionnaire to calibrate the app. The new calibration screen adopted the same design language as the assessment itself, to get the user accustomed to it before they began the test.

Before the user started the assessment, they took a Likert Scale questionnaire to calibrate the app. The new calibration screen adopted the same design language as the assessment itself, to get the user accustomed to it before they began the test.

Transactions screens

Assessment

Assessment

Every security that is traded within the stack has a ledger record of this activity. The recorded activity can contain details of when a transaction took place, what value the securites were bought (or sold for) and how much of it were procured (or sold). Because trnsactions are usually recorded in bulk, it is possible to bulk upload them.

Before the user started the assessment, they took a Likert Scale questionnaire to calibrate the app. The new calibration screen adopted the same design language as the assessment itself, to get the user accustomed to it before they began the test.

Before the user started the assessment, they took a Likert Scale questionnaire to calibrate the app. The new calibration screen adopted the same design language as the assessment itself, to get the user accustomed to it before they began the test.

CAP table screens 

Assessment

Assessment

The CAP table is the main output of the 'truth'. It shows the final calculations based upon the details previously provided. The design allows for 3 different views of the table and the ability to group and manage the grouping of the entities displayed within it.

Before the user started the assessment, they took a Likert Scale questionnaire to calibrate the app. The new calibration screen adopted the same design language as the assessment itself, to get the user accustomed to it before they began the test.

Before the user started the assessment, they took a Likert Scale questionnaire to calibrate the app. The new calibration screen adopted the same design language as the assessment itself, to get the user accustomed to it before they began the test.

Holdings screens

Assessment

Assessment

The holdings table is a computed table. It is esentailly a mini-CAP table per entity. The values provided previously allows Dealstack to output the percentage ownership calculations. The holdings table is viewable only upon finishing the setup of the CAP table. However the details can alwas be edited and updated.

Before the user started the assessment, they took a Likert Scale questionnaire to calibrate the app. The new calibration screen adopted the same design language as the assessment itself, to get the user accustomed to it before they began the test.

Before the user started the assessment, they took a Likert Scale questionnaire to calibrate the app. The new calibration screen adopted the same design language as the assessment itself, to get the user accustomed to it before they began the test.

Links

Assessment

Assessment

• CAP table Figma prototype link
• Actual demo links 1, 2, 3, 4 & 5

To meet these differing requirements, the desktop app was designed using a customer view.

A folder hierarchy approach ensured that depending upon the type of logged in user, they could either see only relevant customer or individual data.

A simple traffic-light design gave an indicative health overview. To further segment the content, the navigation had a flow-in-a-flow system divided between dashboard, timeline, coaching and settings. The access would again depend on the type of user.

To meet these differing requirements, the desktop app was designed using a customer view.

A folder hierarchy approach ensured that depending upon the type of logged in user, they could either see only relevant customer or individual data.

A simple traffic-light design gave an indicative health overview. To further segment the content, the navigation had a flow-in-a-flow system divided between dashboard, timeline, coaching and settings. The access would again depend on the type of user.

Footnote: The CAP table project was designed and implemented over a period of 4 months from September - October 2023. The phases included a series of workshops, ideations, presentations (to various stakeholders and leadership teams) and revisions. Since December, it is a standalone project that now has regular feature improvments and bug fixes like other projects within Dealstack.

Footnote: LeaderAmp was designed in August 2016 and development work happened in parallel. The app went live in the Android Play Store and the Apple App Store. Some content has since been modified including LeaderAmp’s logo.

Footnote: LeaderAmp was designed in August 2016 and development work happened in parallel. The app went live in the Android Play Store and the Apple App Store. Some content has since been modified including LeaderAmp’s logo.