Tradex

Product design and business process development for fintech start-up

Background

Tradex is a fintech start-up that acts as an intermediary between small businesses in the construction industry and their customers. By managing trade accounts and billing through the Tradex platform, small business suppliers can eliminate the risk of non-payments, and customers can enjoy the convenience of one pre-approved trade account to use with all participating suppliers.

My role

  • Worked with founder to define business rules and processes
  • Suggested areas of focus for user research
  • Designed user flows to support business and user requirements
  • Designed web app interface and wrote design specification

Design process and key challenges

This client came to us with a lot of information. Reams. There were process diagrams, business models, pages of finance details about something called “invoice novation”, patent applications, as well as documents describing interfaces the app needs.

I pored over it (and did a lot of Googling), but I still didn’t understand how the product “eliminated late payments and bad debts from trade debtors”. I said to the client – tell me, how does someone use Tradex in real life?

A tradie walks into a store to buy some supplies. When he gets to the cashier, instead of putting it on his trade account, he puts it on his Tradex account – it’s like a trade account, but through Tradex. The storekeeper raises an invoice for the tradie, but on the due date, Tradex pays the store, whether or not the tradie has paid the bill. When the tradie makes the payment, it goes to Tradex – and if the tradie pays late or not at all, it’s Tradex’s problem, not the storekeeper’s.

Oooh. Sounds great!

The client went on to describe other features – you can get advances on your invoices, extensions on payment deadlines, you could even use a special credit card to pay. And all of this would be integrated with their accounting system so everything would be seamless.

I asked him to pause – this might be a good time to speak to some of your potential early adopters, and see what they think. Let’s make a list of things we need to know to decide what features are actually important for the MVP. As he interviewed more potential users, we started honing in on the core features and how they might work. We also designed some mock interfaces to see whether we could design something that didn’t look like scary confusing finance software.

It’s probably no surprise that designing a fintech product isn’t straightforward. We had a pretty good idea what users would want by now, but for the whole system to work, we also had to work with third parties like trade credit insurers, and they had their own strict rules. As we pencilled in business rules and processes, we also had to negotiate with these third parties to find best fit solutions, and then iterate those rules and processes to fit.

At the same time, we started listing out what our interface would need to be able to do to support this system. This started out as user stories, but also developed into a draft of what would be the specifications document, so that we could capture all the inner-workings that weren’t user-facing.

When the business rules and corresponding product requirements had started to settle, I started mapping out the user flow and required interfaces, before filling out all the wireframes then applying visual design elements to make the interfaces build-ready. I briefed the lead developer for the project, and we worked together to nut out any technical details that were relevant at this point to produce the design specification.

Now we’re ready for build.

If you’d like more details about this project or any others in my folio, please contact me.