Pactio is a seed round financial technology startup that is building a SaaS workflow productivity tool for private equity transactions. The focus for the initial MVP is to displace the existing use of spreadsheets (e.g. MS excel) to model and orchestrate complex investment transactions. The initial strategy being to create switching value through a wide set of efficiency and control improvements that would address a host of known deal team pain points.
Project scope
At Pactio I was the solo product designer working with a team of three full-stack engineers. We were tasked by the founders to get the software into a releasable alpha state by the end of Q1 2022. Working with the founders and based on discovery work with a group of three private equity firms who has signed up as design partners, we identified 3 functional gaps that would require design & implementation before our alpha would be ready:
1. The platform would need to support deals that included multiple currency flows;
2. A set of interactions would be needed to allow users to interrogate calculated values;
3. To avoid the inefficient and error prone manual data input we would need to method to bulk import data from a spreadsheet source file.
Visual & interaction design
The team were also aware based on early demo feedback from design partners that an important aspect of the product would be how data was presented both from a formatting and content hierarchy perspective. Early software builds were crude in that respect, where efforts had been focused on raw functionality, with minimal consideration for visual style or interaction design.
As a result my project scope was extended to additionally consider this. Where deliverables were to be a set of design concepts and associated component styles. My output here could then be used to gauge design partner support for the UI direction, as well as feed into decision making on how much engineering resource to commit to UI improvements.
Multi-currency support
For European private equity firms, deals comprising multiple currencies are commonplace. From research interviews carried out with our design partners we established three core functional use cases that we would need to accommodate in our MVP:
1. There is typically a single on-structure FX conversion within a deal (although multiple are possible) where multiple custom rates may be used. These rates are also used for "display conversions" in order to show the entire deal in a dual currency view;
2. On-structure conversions are typically in the 10s or 100s of millions of currency. In volatile markets it is necessary to get protection for the conversion by arranging a forward contract with an intermediary in return for a fee. This is known as hedging;
3. Multi-currency transactions involve numerous types of expenses to advisors and other beneficiaries. It is common for these to be invoiced in a currency other than that of the paying structural entity. In such cases the amounts are comparatively small and deal teams just use the prevailing spot-rates offered by the bank that executes the payment.
Our research interviews also discovered a range of pain points that our design partners were struggling within their current solution:
Early designs
My first step on the design front, given the wide set of implications, was to consider what the multi currency touch points would be across the software.
Multi-currency touch points across the software views
This exercise gave both design and engineering an initial sense of the volume of work involved and informed where further investigation would be required.
Within design specifically we settled on an approach where I would do rapid low-fidelity prototypes in conjunction with regular design partner workshops for validation purposes. At this stage as we were primarily focused on functional capability and flow the team felt the speed of lo-fis were preferred over high-fidelity mocks.
To keep design work constrained and rapid, I focused my prototyping on a representative user journey that would take our design partners through our proposed solution to the three core use cases.
Next followed a series of rapidly created lo-fi frames that were initially stress tested with the founders before being workshopped with the design partners. These partner sessions in turn allowing us to get fast feedback cycles of less than a week - in some cases same day.
The approach with the lo-fi frames was to use realistic representations of client data and show the kind of interaction fidelity typically reserved for hi-fi mocks. The goal being to achieve a deep level of partner engagement and feedback, while staying rapid and more focused on functionality over style.
First internal sketch for multi-currency
First client facing lo-fi for multi currency
First round feedback
Through workshopping the above lo-fi with our design partners we received a wide range of both positive & constructive feedback. Which included:
Positive
- Liked the wizard config, especially the ability to punch in placeholders and plugs;
- Thought the layout and content hierarchy of sources & uses was clearer than current build;
- Appreciated the use of icon buttons rather than hiding actions behind menus;
- Liked the ability to create entities graphically;
- Liked the use of calculation evidence sidebar to explain blended rate derivation.
Constructive
- Didn't like seeing multiple currencies in the same table column;
- Thought the inclusion of rates and hedges sections on page made the view too complex
- Said that there was too much flexibility around currency assignment which only increased the complexity - better to keep it even more simple.
Constrained choice & tech feasibility
It was clear from our partner sessions that our initial pursuit of an unconstrained and generic approach to multi-currency was leading to a complex experience. We also had work to do on the layout and position of data in the information architecture.
However the CTO (who was playing the role of product manager) had concerns about the technical feasibility of introducing various constraints and business rules within the user journey.
Initially we thought to draw up a set of proposed rules that we would then use together with the engineers to assess implementation feasibility. Examples of these proposed constraints included:
1. Mandatory assignment of a single currency for each entity;
2. Projects can only contain two main currencies;
3. Projects can only contain one main conversion;
We also had further complexity in that the three aspects of a data relation (origin/ destination/value) could be inputted by the user in any order. To try to unwrapped the potential business rule implications here I carried our some user journey permutation analysis:
Sample of user flow permutations analysis
Design compromise
This work was followed by an internal collaborative session, in which as a inter-disciplinary team we discussed the question of where and how to constrain user choice. From this session it was clear that while the proposed constraints would simplify the experience they would also be expensive to implement if done on the server-side or be brittle if done in the front-end.
The group decision here was to compromise by only requiring entities to have a single declared currency and to shape the UI to prevent the user from selecting more than two primary currencies within a project.
Design iteration & prototype
With confirmation on the feasibility and the feedback from initial designs in hand, I created two further sets of proposed designs with further partner feedback between them.
In addition to sharing multi-artboard canvases with design partners I also wired up a set of clickable Figma prototypes using my increasingly more detailed lo-fidelity frames. These allowed me to go deeper into the interaction design in order to directly inform the high-fidelity work that would follow later.
Partially wired lo-fi prototype
Implementation deliverables
At this point feedback was positive enough for the team to have confidence the approach was valid and that the experience would deliver a solid MVP for the target core use cases.
The team also agreed that given the time pressure for the alpha release it would be best to dispense with the formation of a more detailed hi-fi design spec. Instead focusing on the functional capability by using a base set of component styles already in use via the open source MUI design system.
To assist the engineers with navigating the assembled artefacts I first presented the journey end-to-end with the full team. I followed this up with repackaging my designs into a dev-notes format to better assist with asynchronous implementation work. As implementation work got underway I would field questions, review commits and make spot adjustments in collaboration with the engineers.
Multi-currency implementation & interaction notes
Calculated value evidence
The second feature I needed to design was significantly smaller in scope compared to multi-currency. As mentioned previously the product was intending to displace MS Excel as both a data store and a calculator.
In order to make our target users willing to make the switch it was imperative that we could from alpha give them the confidence that all forms of calculation being performed by the software are correct. We also wanted to make the experience of auditing calculations significantly richer, more intuitive and easier to use than within Excel.
This is not an easy task as Excel has had many years to perfect their method, as well as offering an extensive plugin ecosystem.
The use cases and pain points here were again established via design partner interviews:
We understood that the ability to trace dependents gave perhaps the most value-add over existing tools. However in order to focus on speed of design and implementation we needed to keep the scope tight.
The scope we settled on for MVP build was:
1. Text styling to distinguish value types;
2. Icon buttons adjacent to values to trigger calculation interrogation layer;
3. Use of a right-hand-side overlay sidebar to act as inspector for tracing precedents and dependents.
Low fidelity designs
For this feature we had a limited window to do design work. With only 4 days between first consideration and start of implementation I only had time to do a very quick review of native excel capabilities, presence of conventions in respect to value handling and 3rd party excel plugins - such as those provided by CapitalIQ.
This was followed by rapid creation of another series of lo-fi frames. As with multi-currency, we used our regular design partner sessions to validate. In this case the response was positive across the board. With just a few minor suggestions, mostly in the vein of scope reduction. For example removing on hover summary of calculation, limiting drill down in the sidebar and having options to collapse/show all precedents.
It was also interesting to hear differences in opinion around whether the inspector sidebar should be shown on-click or on-hover.
Complex calculation inspection using sidebar
In this case as we approached implementation the engineers and I felt it would be helpful to define a narrow set of element styles that could be used for both main page value treatment as well as sidebar content.
This was by no means an exhaustive accounting of styles and did not consider layout. Rather was just the minimum necessary to give the engineers what they needed to implement as rapidly as possible.
Simplified element styles for calculation evidence
Bulk import
The third feature for this phase of design work specifically focused on software usage productivity. Within the existing way of working among intended users it was typical for the company being acquired to provide a set of accounts data to the buyout fund in spreadsheet form. Such data can be easily appended to a larger excel workbook as a separate worksheet tab. Cells within these worksheets can then be directly referenced as required.
By contrast within the software we were building this same feature set would not be possible natively - short of attempting to rebuild excel, which was not the point.
Instead our software needed an easy mechanism by which a user could bulk add data in spreadsheet form and ensure that new data was correctly represented within our data model.
De-scoped from alpha
While this feature set was acknowledged to be a key piece of functionality required for use of our software in a production setting, it was also acknowledged that although onerous the software could achieve our replication milestone for the alpha without it.
Given the approaching alpha release deadline, the team made the tough decision to delay implementation of this feature set in order to instead deliver on security enhancements that would be necessary to allow our design partners to input confidential data into our software without concern.
A new plan was made that would see this feature being 1st on the list following the alpha release. For this reason and given the engineering team's short term focus on security, we felt that it still made sense for me to carry out an initial round of discovery and design work for the feature.
Design scope
As with the multi-currency and calculation evidence features, I approached this feature in a like manner. Starting with an initial set of discovery conversations both with the founders and our design partners.
What I quickly discovered is that while various forms of data can be brought into master spreadsheets en masse, by far the most onerous data type concerned managers of target co. Who either held equity or would be recipients of bonuses as part of the deal. With these same managers also potentially electing to roll their stakes and/or bonuses into the new co. that would be formed as part of the transaction. It was also not uncommon to have upwards of 50 separate managers.
From this starting point it was fairly straightforward to extract a new set of use cases and pain points for design consideration.
Within our solution design we first needed to settle on a method to accept new data in bulk. The options available to us where:
1. User uploads original excel file (.xslx);
2. User prepares CSV file, then uploads this file (.csv);
3. User copies a data range from the source file and pastes it in our UI.
We quickly dismissed option 1 as the source files are typically very complex so knowing which data to pay attention to would be exceptionally difficult. Option 2 felt like a significant effort barrier to create a new file and also introduces the possibility of human error during creation. Option 3 (copy/paste) was most attractive as it stayed close to the source of truth while allowing the user to tell us which data to pay attention to.
Target user journey
Before starting work on the UI, I first needed to lock down the user journey that would be sufficiently representative of the entire solution. We wanted to get a validation signal from our design partners as quickly as possible rather than doing a complete workup of all the possible journey permutations.
Based on our interviews we knew that manager stakes were typically the first kind of manager data received. This was often followed by transaction bonuses. With rollover data sometimes coming individually and not needing bulk import. This suggested to me that a sensible journey to base the designs on was the following:
To assist my design work I also needed to do some analysis to confirm the data schema for our software and then combine this with user relatable field names. As we were going to need the user to perform some data mapping, we had to make sure our representation of the data would match our user's metal model.
Target data schema for manager import
Lo-fi prototype
The strategy to pursue validation of the proposed UX/UI would be the same as the previous two features. We had had good feedback from the design partners around the use of lo-fi artefacts and felt they could work well here also.
For inspiration here I looked to a tool that I had previous experience of when looking after an early adopter community while at Interactive Investor. The tool in question was Mailchimp's data import feature which also included support for copy/paste.
I worked their approach into our journey and added various additional controls to support the increased complexity of our data model.
Frames from 1st manager import prototype
Feedback from design partners workshops for this approach to manager data import was very positive. All agreed that copy/paste was the best approach. There was also a lot of support for the concepts and flow for amend/merge as well as the idea of breaking the link to evidence if a manual edit is done later.
Constructive feedback included preferring to see imported manager stakes data arranged as a wide table with manager name driving as opposed to share class. It was also acknowledged that we would need a way to handle typos in names.
On the last point, this did come up in early design discussions to which our idea was to use NLP machine learning tools to alert the user if a new manager had a very similar name to an existing manager. However rather obviously this was descoped from our MVP.
Visual & interaction design
One of the benefits of doing lo-fi designs with more fidelity than might be typical is that we had already gathered a range of design partner input to inform a hi-fi design direction.
That being said we also knew that front office deal teams for the most part came from investment banking backgrounds. Where there is typically high levels of obsession with low-level details around formatting and data presentation.
At this point the UI in our staging environment was fairly basic with a leaning toward use of a series of nested cards to display tabular data.
Example of previous UI
Concept design
We knew that it would be a few weeks until the engineering team would be free to start implementing new UI. We also wanted to make sure our direction was valid and well suited to the data power users we were targeting. For this reason I felt it would be good investment to create a fairly wide ranging design concept to showcase various pattern usage as well as visual hierarchy for data that I had in mind.
This concept could then be showcased to design partner to allow refinement and subsequent preparation of design specs for our engineers.
To build the concept I leveraged the MUI design system for Figma as this was already heavy engrained in the current build. My goal was to stay as close as possible to base MUI components in order to minimise the work required to do the re-skin. The other two key plans I had were to:
1. Lean into data tables proper and move away from cards;
2. Strip down the UI as much as possible to removed unwanted distractions.
Design concept for UI refresh
Concept feedback
Through showcasing my concept design frames to our design partners we gathered a wide array of feedback. Examples of positive and constructive feedback included:
Positive
- Felt the overall impression was much cleaner and modern with a focus on the data;
- Could more easily follow the hierarchy of data such as sub-totals and nested sub-items;
- Liked moving to top tool bar for main nav - as this would allow for more table columns within the more complicated views;
- Appreciated having table level controls with choices being mirrored to other tables;
- Sub-item mobility would be a big time-saver;
- Described the dual concepts of value level comment threads & audit log as a "game changer".
Constructive
- Felt the sub totals should be more connected to the tables that produce them;
- Always need the decimal points to line up no matter what, so don't use larger font for sub totals;
- Wanted the ability to add columns in addition to hide/re-order (specifically relative comparators);
- With sub-item mobility wanted to be able to move selections between tables as well.
Design specs
Following further refinements of the concept design my last step on the project was to put together hi-fi specs that the engineers could use to implement the new UI designs.
Given that the UI build was already using MUI it was not necessary for me to fully define all component styles. Instead the deliverables comprised a set of page template designs (similar to concept design frames above with additional developer notes) and select component specs for more critical parts of the build. A good example of this was our data tables:
Example of basic component design spec
