Work /

Developing A Global Trade Platform To Scale With Kountable

The Story
Kountable was pursuing a solution to a $1.3 trillion trade gap by transforming the procurement and trade space in emerging markets, bringing access to resources like never before. They began by creating a series of makeshift products to support an ever-changing service offering. As the offering began to fortify itself, the company wanted to build a digital product to automate the service offering, a lynch pin to scaling. This is the story of doing just that.
The Team
Considering the scope, our team was small but mighty. We consisted of a chief architect, product manager, front-end, back-end, native android, and three full-stack engineers and myself as the lead designer. Partway into this project, a product designer and a marketing designer joined the band. I managed the additional designers in their execution of the product design and its post-release marketing.
This cast changed over time, but the following projects were in progress from August 2017 to March 2019.
My Contribution
As a member of this team, I wore multiple hats, leveraging a varied skill set to meet and exceed our goals.
  • Supported project management team in strategizing the discovery and execution of the project
  • Led research planning and execution together with our mobile developer and trade generation teams in Rwanda and Kenya
  • Led Design System team towards experimental/visual consistency
  • Collaborated with our mobile team to get working prototypes ready for user testing
  • Led a team of designers in implementing new features and product marketing for releases
  • Helped document and QA releases with our development team
Working end-to-end on a platform of this magnitude proved a difficult, yet very rewarding challenge.
The Outcome
Spoiler alert! As a result of this project, Kountable received greater quantity, higher quality project submissions. We also implemented a new feature, the Deal Calculator, that received such positive feedback that it is now featured as a benefit in our company offerings to customers.
Alright, alright... now get to the story!
Digital commerce has become a global standard, but not everyone can participate. Small businesses make up over 90% of entities involved in global trade, but are often unable to participate due to a lack of systems of record to move, score, and govern the capital flows needed to sustainably integrate with the global economy. Digitally connected, resourceful entrepreneurs can’t do business visibly and efficiently enough to unlock the opportunities they see in their own markets while enterprise companies can’t serve or integrate with them. It was our job at Kountable to build a platform that would cross this digital divide to reshape the way everyone conducts business.
Building for Relationships
At Kountable, we believe we can only accomplish this lofty goal at the intersection of local knowledge and global resources. Kountable is building a never-before-seen system of financial, identity, transactional, and behavioral information for global trade cycles to ensure the resources get to the right people at the right time. The Kountable Platform is a relationship business. Humans come together to network, exchange goods, skills, information, and capital. Technology increases the productivity and connectivity of these arrangements while design bridges the gap between technology and human relationships. The global trade gap is a $1.3 trillion market that has the potential to raise economies out of poverty and increase global prosperity. At Kountable, we are reimagining how the world of trade works together and it’s important that we get it right.

Photos by Tristan Brand.

Unlike most Silicon Valley start-ups, Kountable got its start providing a service without a digital platform to assist in the execution of this procurement. Our objective was big—turn the service-product offering into a digital one that would capture data, scale the service offering, and return transparent, clear, and efficient workflows to our partners.
Understanding a Service Offering to Translate a Digital System of Record
In order to translate the service our team provided to platform users, we first had to fully understand the service being conducted. Through a series of in-depth interviews, we discovered each business unit (BU) was executing business in a very isolated silo, creating rippling effects to the experience of our users.

Together with my PM, I led a series of interviews with individual BUs and eventually with representatives from each BU as a whole to identify and define the front and backstage service experience we were offering our users.
By exposing the surface-to-core business experiences, we began to better understand the holistic journey of our users. This panoramic process also provided a never-before-established continuity in the overall team understanding of what a Kountable user experiences. This holistic view allowed us to easily identify areas of friction and opportunity company wide. Each BU had new objectives as an outcome of this exercise.

As a product team, we uncovered two major takeaways:
Takeaway One
Preceding this project’s undertaking, BU’s created their own makeshift applications through which they conducted some portion of their business until eventually we had four web applications, each serving a different audience, and two native mobile applications mirroring an associated web product.

Takeaway one, of greatest magnitude, was creating consistency for all Kountable users by depreciating user-based applications in favor of developing “one app to rule them all” with significant role-based permissions.
Takeaway Two
A huge portion of what Kountable does is procurement project execution. Much like applying for a mortgage, entrepreneurs in emerging markets, or resellers as we call them, submit procurement contracts they have won to the Kountable platform in hopes that we can help with financing, logistics, and execution against that contract.

Our second largest takeaway was that the beginning of a project submission with Kountable is the most time-consuming and sets the stage for the rest of the experience. Based on the current submission process, if a project doesn’t meet the basic Kountable standards, both Kountable and the reseller have lost valuable time, sometimes amounting to a month of back-and-forth evaluation of the contract and its execution plan.
Solving for Takeaway One
We dove in head first to the mucky water of our pre-existing applications. In an ideal world, we would have blown the ship up and started again from a single plank. But our company and users were moving fast and they needed the boat to sail while being rebuilt. When adrift at sea, a crappy boat is better than no boat.
Our chief architect defined functional areas, the flow of those areas as it pertained to the state of a project, and the structure by which the functional data would be accessed. The development team rewrote products to assure all were written in the same language. The data team defined the data model. Leading the design team, I began identifying the components and interactions consistent across all user interfaces to began developing a design system.
⏸ Let’s Talk More About That “Design System” Thing
Over the course of time, we had four different web applications, each with different interactions, interfaces, and overall experiences. In addition to morphing all applications into one to deliver a single, seamless experience, we also needed to make this transition to achieve scalability.

Our product roadmap was stuffed. We needed to execute a lot and quickly. While we were beginning the process of hiring new team members, having more contributors taking on more projects and delivering high-quality work at a faster pace wasn’t going to cut it as our sole means of meeting demand over time.
Not only did our design team not know which button styling to use, but by the time the design went to code, it often didn’t matter which we chose because our development team would use whichever previously developed button looked close enough for implementation. We were all trying to do what was best and most efficient but losing intention in the product along the way. By connecting everyone to one consistent design system, we would ensure that our user experience would remain consistent as we continued to grow.

A few years ago, my husband and I merged households and we had to go through all of our things to consolidate. We not only had to get rid of the excess we’d each accumulated over the years (ie. “Why do you have a suitcase of wigs?! But also try them all on right now!”) but we also had to decide by what means we were going to accomplish things moving forward. For example, he’s a sound engineer and was very unimpressed with the speaker system I contributed for our home office. His need for a more robust system won and my simple system found a new home.

Similarly, we needed to first understand the current state of our design and development ecosystem in order to understand what was excess and where we had inefficiencies.

We found countless shades of blues and greys, 100+ type styles, 5+ primary button styles, and many more disparities. No wonder we were all lost!

Early on in building this system, we created a basic color palette, but overtime the designs demanded new colors and our naming convention wasn’t going to scale for a growing, changing design system. Small changes were going to create massive workloads for our development team and we had to find a new way to build our system.I learned a lot from working with our development team to build this system. To assure the longevity of our design and its code we had to be strategic. Following Brad Frost’s theory of Atomic Design, we started small and built up, making sure every atom could scale as our product did. For example, we took heed from the wise UX Pin and their implementation of color in their design system while abiding by WCAG compliance. By building our color scheme based on an HSL scale and naming it accordingly, if ever the need arose for an additional lightness or darkness of a base color we were prepared. We followed this same method to implement all atomic components establishing a main list of used items while offering scalability as the product grew.
Remember that whole, rebuild the boat while sailing it bit? We designed and nearly immediately implemented components one by one with our development team. Testing in design first and then implementing in staging to discover where these components would break the system, iterating as we went. Users began to experience incremental improvements and often shared their progressive delight.
"This is a significant improvement! Really."
— Said a real user. Really.
Over time we moved from atoms to molecules, organisms to templates and found ourselves making sweeping page changes live in our application. As new features arose, we found ourselves designing faster than ever. That’s the beauty of building a design system: by creating rules for components, you free up your entire product team to focus on solving actual user problems. We created a robust design system library in Sketch. With a growing design team, this library immediately enabled our team to work at high levels of productivity.
“I’ve never been a part of a start-up that had this much organization around their design this early. You’ve created such a robust, easy-to-use setup that makes designing clear and quick.”
— Said our new design hire
Before this project, we didn’t have one centralized place to reference which elements existed and what rules surrounded their implementation. Our product team was trying their best to make thoughtful decisions about which component to use, but by using an already faulty product as the baseline for decisions, our design debt grew exponentially.

Now our design team doesn’t have to worry about the scalability or interaction of a component, but spends their time solving the problems of our users. And our development team doesn’t need to worry about writing custom code, but spends their time building.

Need a button? We got that. Modal? No problem. Anything else? We've got you covered.
Also as a part of this effort to put systems in place to diminish any doubt of variation, we solved a lack of clarity around terminology displayed per user role. In the same way that I call my mother mom, but to others she is grandma, daughter, wife, or sister but we’re all referencing the same person, we needed to be sure multiple field names mapped to the same data point, no matter what terminology was used by the particular role. Through numerous conversations with our trade teams, I compiled a spreadsheet annotating the various naming conventions and worked with our backend developers and data scientists to assure all data mapped accurately.
▶️ Back to The Main Event
While making incremental improvements to fix our first takeaway to Create One App To Rule Them All, we began churning on takeaway two: Improve The Project Onboarding Experience
approve the project to receive funding. The process can be painful and getting users to understand why we need to collect a dubious number of documents is often the beginning of many long back-and-forth conversations.

Our goals for this project were:
  1. Increase conversion rates of project submissions while decreasing human hand-holding throughout the process
  2. Decrease the overall time from a project’s submission, through evaluation, to approval
  3. Better familiarize our resellers with “The Kountable Way” as a result of their having gone through the onboarding process
In order to approve a project, Kountable must guarantee a 20% return rate to the reseller. In working with our data science team, we found that Kountable rejected over 20% of project submissions due solely to the low rate of return. If we could inform a user on this Kountable policy and give instantaneous feedback on the data they were entering, we could inform them that their project falls short of these minimums before taking the project any further, thus decreasing the work of our trade team and, in effect, increasing their time on executable projects, all while informing the reseller about how Kountable works.

Together with the trade finance team and chief architect, we set out to determine which data points were necessary to make this immediate calculation. The engineers began coding and I began sketching.
Taking inspiration from the Turbo Tax, Mortgage Calculator, and Oscar insurance onboarding experiences, I began dreaming up a choose-your-own-adventure conditional flow in which the user is experienced or novice, affording for different levels of hand-holding and contextual support in the submission process. I created low-fidelity prototypes and began reviewing with stakeholders.

Together with our mobile developer, we created a low-fidelity version of the project submission now internally given the code name “Deal Calculator”. With a trip already planned to Kigali and Nairobi, this was the perfect time to test the submission flow with our users.
Our users are typically on Android devices and often are using operating systems that are at least 4 iterations behind due to phone capacity, so it was imperative that we test our designs with our users. While every designer wants to create the most beautiful, innovative design, what mattered most was the usability of the Deal Calculator. 

Rwandans are notoriously nice. They told us the Deal Calculator was “great” and “simple to use”, but their actions during usability testing told us otherwise. In UX design, it’s imperative to understand what a user needs before they even realize it. It‘s not a user’s job to explain WHY, it’s the job of a designer to understand WHY.
 
We took our user’s questions regarding specific words used in the flow and expectations made evident in their using the application as an indicator that more work needed to be done. When the day of testing was done, we iteratively solved the issues we discovered during our conversations and before the next set of testers came into the office the next day, we had a new iteration ready to test. Over the course of three days, we had three iterations of the flow and by the fourth day, we could tell significant improvements in the usability and overall understanding of the Deal Calculator.

Using our new and shiny design system, we returned to the States and began working on a high-fidelity implementation of the Deal Calculator, scaling it across all properties to which it applied.
The Outcome
If you recall, we had three goals for this project. We don’t have empirical data that directly correlates to this one initiative, but what I can tell you is that the number of project submissions between year-end 2018 and at Q2 end 2019 increased by 11.12%. According to our trade team the submitted deals were of much greater quality and farther along in the funnel than projects received prior to the Deal Calculator’s implementation. And we built a living design system to manage the consistency of it all without even setting out to do so from the get-go! 

Overall, the response to the Deal Calculator was positive. So much so, it’s now featured as a product benefit in our company offerings. Resellers are often in the dark when it comes to their profit margin on any given contract—not any more. With Kountable, let there be light.

Next Project