Kachi joined Paystack in 2017. Funny story, his interview day was also his first day of work there. He arrived before Ope (Head of Design) and waited for him to get to the office. When Ope got in, he asked Kachi if he had come with his laptop, introduced him to everybody at the office, and assigned him his first tasks—no contract, no interview, just straight to work.
Today, 7 years later Kachi is now a Product Design Lead at Paystack where he has contributed to and built
Paystack Checkout - including redesigning it to include payment channels like Pay with Kuda, Pay with Transfer and Pay with USSD
Paystack Music - which started off as a Slack bot he built to compile music shared on Slack into a monthly playlist and turned into a full-on web experience that they still use today
More recently, he’s been focused on building new products like:
Terminals (Paystack’s POS product)
Virtual Terminals
Direct Debit
Zap, a new customer-focused app that he's currently working on. (Shhh, we can’t really talk about this yet)
In this post, I share Kachi’s responses to my many questions on his experience as a leader designing these new products in a company serving millions of customers across the globe.
How are high-level goals determined on the New Product team at Paystack?
When we start off a new initiative, there’s usually a lot of meetings, alignment, and document writing to get everybody on the same page. We write Vision docs for every active initiative. This document explains what the project is, why we’re doing it, what milestones we’re setting for ourselves, and how we’re measuring success over the next 6 months. The team is responsible for writing and updating this document and we check on it every quarter to measure how we’re doing in comparison to the goals we set.
What’s the hardest thing about designing a new product inside Paystack?
I really underestimated how difficult it is to bring new things into existence. When I joined Paystack, I was the 2nd designer and 11th person on the team. We had already built the main products that customers were using, and a lot of the work we were doing was adding new features and fixing bugs to make sure everything worked fine. As a result, we were able to get things done very quickly and relatively easily. If we need a new channel; next week, it’s done.
I wasn’t there before YC when we didn’t know whether people would use the product or not so I don’t think I internalised how difficult it must have been to get everything going. I think that's the hardest thing, that underestimation. You build, build, build, and then you get to 90%. But then getting that last 90% can feel almost as hard as the first 10%. There are also the added restrictions of trying to build quickly in a regulated, high-risk, high-impact environment where everything has to go through the right processes and sign-offs to avoid any downsides on the rest of the business.
How does the team approach new product ideas?
A lot of new ideas usually start with someone asking “Is there a world where…?”, and then everybody joins in with possible ways that we can achieve the ideal solution. We approach them with a lot of curiosity, excitement, and questions.
We try to figure out:
How things currently work?
How they should work?
How do other people interact with those things?
And what could be better with the way people interact with them?
What are the guiding principles for how Paystack products are designed from ground 0?
Last year, the design team came together to codify what we care about as a team and how we want to work together. The principles we came up with are service, collaboration, quality, clarity, connectedness, and delight.
Listing out words doesn't always translate perfectly into how people behave but we genuinely try to embody them in our work. We always try to look at problems, come up with the best possible solution, and then add extra.
What does the start of the design process look like?
Most design projects start with the designer writing a Design Note. Here’s a template I prepared. In this note, we provide all the context for the project from the design perspective:
What is this?
Why are we doing it?
What do we hope to achieve by doing it?
What are the things that absolutely need to be part of our solution?
How will we measure success?
This document can also contain any assets that will help everybody working on the project clearly understand what we’re trying to do and how we’re proposing we go about it. These assets can be sketches, screenshots, wireframes, screen recordings, etc.
At this stage, we're not working out every single screen or detail about how everything is connected. We just want to communicate the broad idea for what the solution would look like.
Having this culture of design notes means that:
We can focus on answering all the foundational questions first before going deep into designing the interface
All the context and references for the project are in one document that everyone has access to in case someone else has to pick up that project or if they’re just curious and want to learn about it
What is the non-negotiable in your design process?
In my opinion, a lot of digital design work is very fickle. You work on something today, 2 years down the line, you probably can't recognise that thing because keeps it changing and getting better or it just doesn’t exist anymore. So for me, the only non-negotiable is to make sure that we can all enjoy the work while we're doing it and try to produce the best work that we possibly can.
I don't like how flowery that sounds, but really the work itself will disappear. Obviously, it has to achieve what we want it to, but in the end, there aren’t that many things that are life or death. I suspect that this answer will change in the future as I do more things. But for now, that's how I feel about it.
When iterating, how do you define when it’s time to stop?
A lot of it comes down to the designer and how confident they are in the work they’ve done. I don’t think there are any hard rules to knowing when work is done. It’s a mixture of personal standards and what’s generally deemed as acceptable work within the team.
To make sure that we have the same standards as a team, when new designers join, we pair them with more experienced designers for their first few projects, so that they can get a feel for what is expected from them through practice.
As a team, we also keep each other accountable. When people share their work, we give feedback when we see things that can be improved. This is how we teach that idea of “how do I know it’s done?” Ultimately, the trick is to work with other people that kind of know when it's done. That way you have a clear idea of general quality and what is acceptable.
Another strong way to help people understand the quality bar is to create systems that help them do things the right way quickly so they can be creative on things that matter and not repeat things that have already been done. This is the part we’ve currently made the least progress with but are actively working on.
Speed vs Quality: How does the team decide what to optimize for?
I think the newer the idea, the more biased towards speed you should be. My new principle for this is: if something breaks and I can go somewhere and say “@everybody I'm sorry. We've broken this thing”, then speed is the answer. When things are early, customers have a lot more forgiveness in their hearts, especially when you can fix those issues quickly.
How does the design team go about insight gathering and doing that often?
We usually test ideas with small groups of people to validate them and learn before launching them publicly. A lot of times, this group is internal and people within the company are also the target audience so it’s a lot easier to talk to them in-person or online to get feedback. Other times, we have to intentionally find people who match the profile we’re building for, and talk to them directly. We reach out to our merchants to ask if they’ll be interested in testing new products and giving us feedback.
For customer-facing products, sometimes we put out public forms for people to opt-in to test products for us or recruit testers via referrals from people within the company or in our immediate network. We rely a lot on user interviews and product analytics using tools like Metabase, Amplitude, and Google Analytics.
“Feedback is helpful when you know what you want” How have you been able to come to this conclusion?
I've seen people present work and be like “Here are 16 options for what we're trying to do.” That's usually not helpful. Leaving it up to everybody else to figure it out is just fertile ground for an unproductive conversation and everybody starts talking about how they feel about the work.
Design is subjective so everybody can have an opinion and be correct.
The right way to approach this is to ask more questions and understand the problems you’re trying to solve so you can cultivate an informed opinion on what direction works best and then present that.
What is your contrarian opinion on design tools?
It’s crazy to me that design is so disconnected from the end-product and we have to hand over our work to other people to make it real. You spend all your energy making pixel-perfect designs and then someone else has to spend an equal amount of energy coding the designs so it works.
This duplication of work stresses me out, especially when I’m the one who’s both designing and coding. I can’t wait for it NOT to be a thing anymore.
It feels so obvious to me that Figma should be solving this problem but for some reason, they aren’t. We use it every day, they have all our designs, and it's already on the web. The closest we have to this at the moment is Framer.
Closing notes
Kachi also watches a lot of tv shows and listens to amapiano. You might want to follow him on linkedIn and twitter
If you made it this far, I hope you walk away with actionable lessons.
My name is Lota, I started BTS as my little way of telling stories behind making - how people design and ship to the rest of the world. I wrote more about this vision in this letter addressed to makers.
So this is to all Makers. To making Something small. Something silly. Something great.
- ©️ 2024 Lota Anidi
