Typically, payments is the last hurdle of any purchase journey. Now, imagine being a user, going through ALL the hassle of finding the right service or product, eventually abandoning the purchase - only because of a poor and seemingly unreliable payment experience. Worse, imagine happening that to your business - all that hard work to provide the best service goes down the drain because of a sketchy lifeless payment experience - which wasn't even your forte as a business. And mind you, poor experiences stick in people's minds far longer than good ones, be it online or offline.

Looking from the outside, it felt like a straightforward need - Businesses need a payment experience that blends with their brand on all platforms, show payment options that cater to their users, and boost conversions. So what's the problem, let's offer them one. How much can this "need" vary from one business to another? We can have one system engineered to do all of that with 4-5 design templates. Merchants could join, provide their designs and preferred payment methods, and our developers would handle the integration. This was our system when we had fewer than 35 merchants.

Turns out, we were too focused on building a system without fully understanding its essential foundations. We designed it for our developers, undermining the needs of the real target users.
‍
We knew we should've dug deeper, but better late than never. We talked to developers, designers, and PMs involved in the process of designing and integrating the payment experience. As a business, you need the ability to create customised payment experiences, when templates don't seem to suffice. You require the control to show relevant payment options and cater to the users across regions. Additionally, you should be able to ship, test, and maintain this experience across mobile and web without navigating multiple Mails/Slack/WhatsApp/ Dashboard channels with Juspay. And importantly, we accepted this is always gonna be an ongoing process that unfolds over days, involving multiple stakeholders from both - business and Juspay teams.

After attending to 50+ merchant calls, endless dev QAs of Payment Pages that went live across brands - we coined two core problems that needed attention.

#1, it was clear to us that our Payment Page framework was not built to cater to a lot of basic design requests, let alone complex ones. Need multiple fonts here, need a pill tag beside this, need the selection to be a radio icon, need to redo the theme, etc. etc. Additionally, the resource spent on some of the requests was redundant and unjustifiably too much, with a poor TAT.

#2, we realised that repeat merchants needed relatively more control over the features and payment flows, than on design. Need to reorder payment options for this region, need only these UPI apps to displayed, need one-click checkouts, need only debit cards, need to display downtimes, etc. etc. All of this had to be done manually at integration level every time. And tweaking integrations frequently meant - multiple releases, involving multiple Juspay and merchant's developers, longer TAT, eventually a pissed off merchant.

A second order effect to solving both these core problems was we wanted teams to move on to better things than just hacking to solve the same problem every 2 weeks. We would never be able to innovate or go 10x if we never optimise. So, we dived head first to solve both these problems. You'd be surprised how much design direction is required in refactoring of codebases!

To solve for more robust customisations design wise (solving problem #1), we initiated a branch track called Componentisation or Lego-ing components. Here's a snapshot of how we iterated heavily on close to 12+ components so we don't miss out on any variation while understanding where to leave room for creativity.

Interestingly, this was not the design side of components we were talking about. There were functional behaviours that had to be engrained for the interface to be of payments and not just any UI. For instance, a back navigation cannot be placed just anywhere. It can only take you back and do nothing else. A Pay button can only initiate the transaction and do nothing else. An amount bar can only show the real amount and nothing else. But how to position or style these items can be totally upto the user.

The fundamental principle we all agreed was - to put no limitation to styles at all. We starting breaking down the components: defined the Atoms (building blocks/legos), and gave a character concept to each component using Trigger (interaction point: Button, Entire layout, etc), Behaviour (invoke next screen, go back, expand accordion, etc) and States (clicked, pressed, disabled, etc). Sometimes being a niche helps!

Some early on explorations of how we tried to convert the above fundamentals into a meaningful and usable interface to design anything inside a payment page.

To solve for a better management of controls (solving problem #2), we went all brute into the Yaml and central codebase, jumped into excels and maintained a heavy documentation to understand what all the 300+ keys actually did. Fortunately, we had the developers sit with us all the time to help us to build a better organisation - that can further be morphed into refactoring of code as well.

Every Aggregator and Gateway is providing a checkout page, how can an Orchestrator like Juspay play this offering to their advantage? We decided to play confidently in our niche and provide a WYSIWYG tool. Integrate once and control everything visually after that.

We figured, there was a clear segmentation of users: New users (Designers, PMs) who focused more on the design part of payment page. Repeat users (mostly PMs) who focused on optimising, controlling, and monitoring the checkout. But Juspay cannot stop operating and just wait for 10x product jumps to happen. We had to keep delivering something as a company to the merchants while achieving the ideal. Late to market was a risky chance we didn't want to take. We did manage to bring down the go live TAT of merchants from 2 weeks to 2-3 days - but we had to optimise a lot on the ways we achieve that.  

Btw, have a look at the evolution of Studio over 3 years.

As a Designer, I did feel a strong urge to give things a beautiful overhaul even for the new users. But deep into the reality, a strategy to focus on retention first made more sense. We had to prioritise the pains of repeat users - the users who've invested in us right now instead of the ones we may acquire in future. Hence, we solved the problem #2 first, divided teams to focus on short and long term goals - and fortunately a designer gets to hop on both the ships.

Convincing the leadership to invest in an impactful tool like this alone took us 1.5 years. We had to constantly be in and around, showing MVPs and talking about the results that this investment can yield. But oh boy after convincing the leadership, keeping the team motivated was (is) by far the hardest challenge for me as a designer. Unless until you bring something for everyone on the table, it is going to be thrice as hard to convince them about the larger vision.

To tackle this challenge, we had to be unconventional. The biggest hurdle was bridging the gap between the two creative forces - design and dev. How could developers build for designers if they never experience the design world? And how could designers create functional shit if they only lived in static pixels? Nothing good comes from a team that lacks conviction and transparency. We had to tear down those walls and open up to unite behind a common purpose. So much so forth that the lines between design and dev discussions get blurred!

Find one of the instances of us designing unusual things and questioning the framework below.

When working in the B2B2C model, you've gotta be thinking simultaneously for two types of users - your client (merchants) and their clients (consumers). In short, we were designing a system that our users will use to design for their end users. Kinda like inception of users?

Quoting the Obsidian's philosophy: "It should be intuitive for beginners but have infinite depth for advanced users. Like going to the beach. You start in the shallow waters, and can stay there as long as you like, or keep swimming out into the ocean." On similar lines were the principles of Design at Juspay:
‍
- Design for yourself, but become a user first.
- Master the art of attention, nail the aesthetics.
- Evaluate without thinking, prioritise intuitiveness.

Since it was mostly me who was anchoring the project on the design front, I made a little system of my own to gather quality feedback as swiftly as possible. Fortunately, we had a tight loop running with PMs and developers, so I could diverge first, bring everyone's ideas on the table, and converge to a fruity solution iteratively. We used Confluence to document all the design decisions so people can refer back to it as a knowledge bank. For vision or flow level decisions, we generally do peer sessions where we don't nerd around aesthetics right away but talk about broader ideas. Mostly happens on whiteboards, and then leads to figma.

As for presentation/handoffs, I like to use loom/screenstudio for walkthrus and collecting feedback for two reasons: Its time boxed, so I don't end up wasting people's time any more than 5 mins. Plus, it avoids unnecessary feedback branches, what you show is what you get feedback upon. I also like to share Figmas early on, so as to let PMs breathe in peace. I have developed a thick skin for feedback and I'm at a point where multicursors don't bother me :p. This was more on the product side ideas.

For absolute tastes, I often cross referenced PS5 interface, rambled through Mobbin, Layers, Godly, Design details. Or have a critique/roast session with fellow designers. If nothing helped and my taste would still suck, I'd just tune some old Hindi jams, go for a run, and try to start fresh again.

Well, to be honest, I was the one person in room who wasn't keen on incorporating AI into Studio upfront. I've always felt AI should be omnipresent in the core product to optimise the mundane, and help users move on to better things. AI cannot make the product smarter if the foundations of product itself are weak. If I have to ask AI to do the things, is it even optimising the work? Do the optimisations and let me just review it. Having said that, AI was a lot more useful in optimising the development and analysing data without having to make assumptions. Yet to be convinced where AI can help our users in the design side of things. Ending quite controversially? Haha, because why not.