Part of a series where I document the behind-the-scenes of exploring ways to unlock operational excellence and quality as a lean design team.

You are a designer working on your current design requirement, and a Slack notification pops up asking you to review the dev build for design you delivered last sprint. You open the URL and immediately know things aren’t looking and feeling like how you had thought.

A thorough design QA sprint can span multiple rounds, involving verifying the flagged fixes, and looking for any new anomalies. For a team still maturing its design system sync between Figma and codebase, the surface area of things that can drift between design intent and implementation is even larger. All this costs time — time a designer could have used to explore more ideas and validate designs with customers. But it’s not optional either. Done poorly, it reflects in the end customer experience, which is also a designer’s responsibility.

This article runs down the rabbit hole of that thought: can we reimagine design QA that saves designers time for high judgement work?

This article explores the world where Figma-to-dev handoff is still the reality — and how the loop it creates is still expensive. Designers writing code and raising PRs comes with its own set of challenges, which I’ll talk about in a different article.

What’s the expensive part in the process today?

Browse through states. Take screenshots. Move to Figma, place the annotator, reference the design frame, translate what you see into something a developer can act on. Repeat across every anomaly, every screen, every state. Inform the QA.

That’s how the traditional workflow has been. We looked at each part carefully to see where the true opportunity lies.

Screenshoting isn’t the bottleneck

You spot the gap, you take the screenshot — barely a click once you know what you’re looking at. The problem starts when you take those frames back to Figma. You recollect the gap, find the right frame for comparison across potentially a dozen states, and translate design judgment into annotation language precise enough to act on without further back-and-forth. This translation is high-skill work being spent on a high-frequency, low-glamour task. Done poorly, it increases effort on the developer side — they manually figure out the specifics, leaving room for error.

Figma is not the surface to track lifecycle of fixes

Depending on the practice followed in an organisation, you may fall into one of these:

Your designer just handed off the annotated section to QA and dev — the design tool becomes a living QA document, and the friction of that mismatch compounds with every build drop. Unresolved annotations pile up in red. New findings go in on top. The frame becomes archaeological. The designer holds all the state in their head and their annotation history.

Or your designer creates Jira tickets for every issue identified — more taxing upfront, but it makes issue-tracking easier. The designer would still need to annotate the screenshot to highlight the gap, and would probably need to link the parallel Figma frame for reference. The ticket exists, but the translation work doesn’t disappear.

Either way, the designer is the one manually bridging design intent to developer action on every cycle. The tracking method changes. The underlying cost doesn’t.

The instincts that look like solutions in AI-first world but aren’t

Can’t QA teams write automated scripts to flag UI issues? QA teams already uses playwright, Cypress, visual regression tools like Percy or Chromatic. These catch functional breakage and pixel-level regression against a previous build snapshot. What they don’t catch is drift from design intent. A component can render correctly, pass every test, and still use the wrong token, wrong spacing, wrong variant. The script has no reference for what the design meant — only what the build was. It tells you something changed. It can’t tell you whether it was right to begin with.

Can’t Figma-mcp dev connector flag differences? Sounds like it collapses the gap entirely. But it assumes the two sides are already in meaningful sync. When the design system on the code side is still maturing, the noise-to-signal ratio on those callouts would be high. You’d spend as much time dismissing false positives as fixing real issues.

What a probable solution can look like

If the two root problems are the translation loop and the fix lifecycle, the ideal solution targets both directly — not by adding a better container for the same work, but by removing chunks of that work entirely.

Capture stays separate from annotation. A designer browsing the build across states collects screens in one click — no stopping, no annotating mid-flow. One collection per requirement, open until closed, like adding to a Pinterest board while you browse. The cognitive mode of capturing and the cognitive mode of reviewing are kept separate, because mixing them is where continuity breaks.

The comparison happens automatically. You paste a Figma section URL once for the collection. The tool pulls all frames from that section via API. You pick the matching frame from a thumbnail grid — seconds per screenshot, not minutes of tab-hunting. A vision model then compares the matched pair: not pixel diff, which falls apart on rendering and scale differences between Figma and a live build, but semantic comparison that can reason about spacing, colour, component variant, and layout the way a designer would.

The designer reviews, not generates. The output of that comparison is a flagged list. The designer’s job is to keep what’s real and dismiss what’s noise. The judgment stays human. The hunting moves to the machine. That’s a meaningfully different cognitive load from starting with a blank screen.

The handoff artefact is a living URL, not a frame. One link per requirement collection. The developer opens it, sees every finding with its current status. When the next build drops, the designer updates the same session — findings move from open to fixed to verified. No re-annotation ritual, no red-on-red archaeology, no state living only in someone’s memory.

Where the constraints are and what’s next?

We haven’t built this. We mapped it, stress-tested the logic, and validated that the building blocks exist — Figma’s API can export frames programmatically, and vision models can reason about UI discrepancies at a level pixel diff can’t. But we haven’t run it against our actual screens to know how well it holds up on dense SaaS interfaces where differences are token-level rather than structural. That validation is still ahead of us.

There’s also an open question the industry hasn’t clearly answered: how accurately can a vision model catch what a trained designer would catch? At what fidelity does the first-pass diff actually reduce designer effort rather than just shifting it? I haven’t seen teams openly document having solved this end-to-end — not at the level of design intent matching, not for production SaaS UI.

If you’ve seen it done well somewhere, that’s exactly the kind of signal we’re looking for and I would love to hear about it.

Part of a series where we document the behind-the-scenes of unlocking operational excellence and quality across design requirements as a lean team at Powerplay.

You’ve seen this as Visual Designer. AI made it possible for anyone to generate a deck in minutes — your sales lead, your marketing team, pulling together a deck right before a call/campaign. They prompt, they get something, they ship it.

It uses something that vaguely looks like your brand colours. The font is close, maybe. The logo is squashed into a corner or stretched across the title slide. The hierarchy is off in ways non-designers can’t articulate but definitely feel. The pattern it uses comes from the base template of the tool, and with different tools at their disposal, each new deck looks like it came from a slightly different company than the last one. Most of the on-brand tutorials were made by non-designers and were limited to “extract some tokens and embed a logo”

In the last few months I was directly involved in shaping the foundations for our sales enablement decks and investor materials alongside our Visual Designer. That work built up a strong repository of patterns in Figma. With teams already moving to Claude for deck generation, it felt like the right moment to encode those principles into a skill — so anyone could generate a reasonably structured deck for non-mission-critical requirements while still honouring the design language.

This is about how we went about building that skill, and the dos and don’ts we picked up along the way. A lot of it will feel familiar if you’ve ever built a good design system.

Step 1: Start with skill purpose and then go beyond the basic style sheet

The best thing about Claude is that you tell it the purpose of the skill you’re building, who will use it, what the use cases are, how to render the end output, etc. It auto-suggests how the overall thing should be packaged. That part was a few minutes of conversation, not a planning exercise.

The real groundwork (and worth investing) was getting our tokens and layout basics into the skill.

We didn’t have a dedicated design system for decks then, so I used Figma AI’s analysis on a few selected artboards to quickly extract typography, colours and margin definitions. Claude then flagged the variances before we added the detailed stylesheet into the skill.

We embedded the custom typography (Clash Grotesk for display, IBM Plex Sans for body) as base64 because the rendering environment doesn’t have network access to load fonts from a CDN. Similarly with assets like brand logo to ensure the output wouldn’t break on anyone’s machine.

Tokens are necessary but they’re not the thing that makes a deck feel on-brand. Training the skill on patterns is where the real empowerment happens — where the design contribution into each output can be made truly minimal without the quality dropping.

Step 2 — think in components, not in templates

This is the one I want to emphasise, because it’s where most attempts to do this kind of thing fail.

When we started, the obvious instinct was to look at the decks our sales team needed most often and build templates for each one — a testimonial slide template, a case study template, a logo grid template, a graph template, a product mockup template. We had a clear list: Testimonials, Customer case studies, Graphs and data slides, Tiles with imagery, Timelines, Product mockups in laptop or mobile frames, etc.

If we’d built templates for each, we’d have a skill that worked exactly until someone needed a testimonial slide that also had a logo grid below it. Or a case study slide with three cards on top and a quote box at the bottom. The combinatorial explosion would have killed it within months.

So we made a different call. Each of these wouldn’t be a template. They’d be a set of components — token-aware primitives like cards, chart variants, pills, badges, connectors, flow nodes, logo cells, device frames (the most used scenarios) — and the skill’s job would be to compose them on the fly based on the content.

The mockup pattern is the clearest example. A “product mockup slide” isn’t a slide layout in our skill. It’s a device_laptop() and a device_mobile() component that can be placed inside any layout — alone as a hero, side by side, inside a card, paired with bullet text, as part of a comparison. The same component shows up in a sales hero slide and a feature-spotlight slide, because the component is the unit of reuse, not the slide.

The skill became a stylising layer on top of Claude’s intrinsic ability to make compositional judgments. We didn’t try to teach it layout. We taught it style, and let it bring the layout.

This is the choice that made the skill scalable. When the sales team asks for something that doesn’t quite match anything we anticipated, the skill doesn’t get stuck. It picks the closest set of components, composes them, and renders something that still looks on-brand because every primitive is built from the same token foundation.

Step 3 — Add constraints to make the skill usable by someone who doesn’t speak design

We knew we were building this for a non-designer persona. A sales lead preparing a deck two hours before a client call wouldn’t know that headings come from a Title/XL token, or that body copy uses content/secondary. That judgment has to be encoded in the skill itself — and the skill needs to be adaptive enough to take a non-semantic input and figure out what the user is actually intending.

These are the constraints we encoded — the kind of things a non-designer would never have realised were the problem in the first place:

• Visual hierarchy — Adaptive title sizing, automatic emphasis colours (pink for the core claim, navy for context), generous margins, no crowded slides. Hierarchy is a property of the skill, not the user.
• Semantic over visual — card--accent means "this is a risk or problem," not "this is pink." The skill maps narrative signals (problem, friction, pain point) to the variant — not the other way around.
• Images never scale or stretch — Natural size, alignment-only override, enforced in CSS, in Python, and in the skill’s instructions simultaneously.
• Logo grids and tables use single-stroke borders — so stacked cells never produce double lines.
• Title slides auto-resize their font — (XL → L → M) based on character count so nothing wraps awkwardly.
• Auto-highlight certain keywords in slide title — Seeing an output would lead user to do custom override keyword where accent is applied if needed

The loop that keeps it honest

We built a small feedback system alongside the skill. After each session it writes observations to a learnings.md file — things it had to approximate, layouts that didn't quite fit, visual judgments that got corrected. A patterns-needed.md file tracks the gaps and doubles as the next roadmap. Nothing auto-updates the skill's canonical rules; I review the pending list periodically and promote what's worth promoting.

The sales and marketing teams has been using this for a few weeks now. They’re already filing the right kind of feedback — places where the skill’s instinct was off, patterns it doesn’t have yet, layouts they’d like to see. The signal coming back is at the level of capability and judgment, not bugs and broken rendering. That’s how I know the abstraction is in the right place.

This initiative was one action towards a thesis we’ve come back to a few times: in a lean team in the age of AI, designers shouldn’t be doing the high-frequency, low-judgment output work themselves. They should be building the layer that lets the rest of the team do that work without losing quality.

More posts coming in this series.

If you’re thinking about building something similar for your team and would find it useful to talk through the structure or see the skill setup, feel free to reach out.

The behind-the-scenes of making the brand reflect what we stand for today, and making it ready for what is to come.

Powerplay builds software for the Indian construction industry. Construction here is one of the least organized industries there is. As companies grow, managing multiple locations, people, workflows, and parties becomes impossible across scattered WhatsApp groups and out-of-sync Excel sheets. These emerging businesses, with little exposure to proven practice, the kind that comes from doing the work and not from a book, end up setting up systems that do not stick, picking platforms their teams cannot adapt to, and still leaking margins because there is no visibility and no predictability.

Meanwhile, Powerplay had quietly become more than software. It now ran the full life of a project: from winning the work, to planning the budgets and schedules, to execution on site, to the loop between the two. The reasons customers stayed were no longer “it tracks our work.” They stayed for one connected system, and for best practice that arrived built in instead of something they had to assemble themselves.

Almost none of this was visible to prospects as we moved upmarket. The public content was years out of date, and nothing a customer could see said otherwise. That was the brief. Not a redesign. A brand that had to catch up to a business that had already changed.

What followed ran on two fronts, the foundation and the surface, both in service of one thing: showing what we had become, and where we believed construction was headed.

Fixing the foundation before the surface

As the offering expanded, the surfaces did not keep up. Buyers started to feel it. The site, the sales conversation, and the product were out of sync, each carrying a different version of the same suite.

To fix this, we ran a cross-functional grouping exercise. Sales, account management, marketing, design, and founders each organized the suite the way they believed a construction operator actually understands value. The teams did not agree. Sales grouped by how a deal opens. The people closest to onboarding grouped by where customers struggle. We then set this against our market and competitive research to arrive at the final structure.

The outcome was not just sorted groups. It was groups with a name. Names that match how a customer reasons on a sales call, and that now carry through to the product and the website navigation.

Blueprint to Reality

The same shift produced the visual language. The answer came from the product, not a moodboard.

We had gone end-to-end, and that life has two ends with two different truths.

Planning is structured. It lives in drawings, measurements, and schedules. It used to happen on chart paper and now happens in CAD. As a design team, we went down the rabbit hole to find inspiration in the rich evolution of construction over the years. From annotated drawings, blueprint papers, floor plans, to digital enhanced renders, we explored it all.

We picked the CAD route over the original paper artefacts, because digital carried precision, speed, and a sense of the future, which is what we set out to transform the industry with.

Execution, on the other hand, is tactile. The site supervisor and the project manager work amid sand, cement, steel, and the machinery that brings a drawing to life. The execution side of the language carries those textures, concrete and butter paper among them, because that is the world the user physically stands in while using the product.

Blueprint to Reality is the name for that arc. It is not just a metaphor we liked. It is a description of what the product does, made visible. Construction has barely seen brand used to make one company feel different from another. Strip the hard hats and the backgrounds out of any competitor and there is no brand left. The one thing we owned that no one else did was blue, chosen early for trust, and it had ended just there. The arc gave blue a reason to exist. The same logic then set the iconography and the illustration system, so the language scales instead of living only on the homepage.

The principles we held on every surface

These are the foundational learnings turned into working principles, the ones that shaped the visual and content design and fed straight into our sales motion, so the site reinforces what a sales rep is already saying in the room.

Our customers carry the claim, not us

The first thing you see is customer logos: real contractors, developers, and MEP businesses, on real projects across India. Every value group opens with a sentence a customer said, not one we wrote. This industry runs on credibility. People trust what they have seen work for someone like them, in their world, far more than anything a vendor says about itself. A mid-market buyer is not asking whether it works. They are asking whether it works for someone like them, near them. The proof had to be built around that question, not around our adjectives.

We made enterprise readiness visible, not assumed

Larger teams decide on scale, flexibility, control over their data, and the quality of support, which matters more in this industry than most. So we distributed that signal deliberately across the site, in the offering stack, in how we talk about adoption, in the detail down to the ISO certification, rather than claiming “enterprise ready” once and hoping it stuck.

We treated AI as a direction, not a tile

AI is not a feature we bolted on. It runs across the construction lifecycle, and the design had to say that. So it is not a badge on a card. It is woven into the narration, shown in motion, in the intro film, and through the value pages, doing real work rather than announcing itself.

We led with outcome but kept the depth for decision makers

Leading with the outcome was a foundational content choice, held across every marketing surface. But it did not come at the cost of the detail teams use to decide. The feature lists and the persona-led value framework stayed on purpose, so the depth exists for the quieter reader and to harden the claims made in conversation. Buying here is a multi-person decision, and each person needs to find their own reason to say yes.

We stopped using words where words kept failing

Visibility from a live site back to the office, with the time, the location, and a photo attached, is what every owner wants and almost none can describe. So we stopped describing it. We showed it in motion, the product doing the actual work, because that was the only honest way to make the abstraction concrete.

These decisions now run through the marketing site, the sales collateral, the content, and the product itself. We are still maturing many of them. The point was never the website. It was bringing everything-in-sync with where we stand today.

Our product had outgrown our brand. The redesign was the smallest part was originally published in Powerplay on Medium, where people are continuing the conversation by highlighting and responding to this story.

Towards my final months at Jupiter (a neobank startup based in India), I was given the opportunity to work on growth initiatives within a newly formed group of talented folks from across teams. While the focus was on moving business metrics, identifying scalable levers and incentive strategies, this experience fundamentally shifted how I think about product design, especially its potential to influence behaviour. A lot of experiments we eventually shipped were deeply informed by behavioural science, e.g. how users make decisions, what draws attention, and how perceived value gets shaped.

Though my work was centred around the first 7 days of user experience, aimed at helping users reach their “aha” moments faster, these learnings have continued to guide my approach across product contexts, from feature discovery and habit loops to early retention.

Start with observation, not assumption

For growth initiatives to work, having a nuanced understanding of the customer’s stage, mindset, and motivation is crucial. That clarity can only come through observation. Before anything else, we spent time meeting new users, watching how they behaved, what they ignored, and where they paused. Pure, unfiltered observation gave us the raw inputs.

From there, we followed a simple rhythm: observations → insights → tighter hypotheses → focused experiments, prioritised using the NICE framework and a bit of gut instinct.

This framework was one of the earliest things we aligned on as a group, and it gave our efforts the direction they needed.

Think about emotions, not just the user’s goal

Product and design often focus on reducing steps and speeding up flows — automating inputs, skipping less critical steps, and so on. But we often miss thinking about what will keep user’s momentum. Do they know what they’ll get in return for the effort we’re asking of them?

Jupiter’s onboarding took about 10 minutes — reasonable for opening a bank account, but still a commitment. We observed users getting lost in the process, disconnected from why they started. There was little emotional reinforcement or sense of progress.

Our team then translated this into changes like setting clear expectations, visible progress markers, social proof, and cues reinforcing value. These small additions helped increase account creation by 1.5x

Choose what to emphasize. Then be ruthless about it

For a user who just got on a new app, it’s natural for them to explore the app on their own. Each tab on the app back then showed all the features and services available, but users were still leaving the app without doing anything. Why? When we observed such users in person, they quickly skimmed through a crowded set of features but couldn’t identify where to begin — payments, investments, financial management. A clear anchor was missing.

This was a powerful observation. We questioned “what’s the one action we want a new user to take” for each value and designed around that. Not necessarily by hiding everything else, but by creating intentional focus: a single message, a single prompt, a single reward loop to activate. (Of course, we decided what to show based on what we knew about the user who just got onboarded.)

Use visual contrast and strategic copy to signal importance

Saying that users scan UI top to bottom or left to right is an oversimplification. Anything that stands out, looks different from product’s core UI, or has motion in an otherwise mostly static page will draw eyes. This was our approach too while designing experience for our growth initiatives.

A lot of our experiments deliberately stepped outside system conventions intentionally, even though they didn’t feel ideal from a pure UX lens. A big banner that sits on top of the app’s homepage, a modal that obstructed user’s flow, or copy like “Limited time offer”, “Expires Today”, “Only for you”, all were meant to signal “this won’t be here forever” or “this deserves your attention now”.

A banner at the top of the homepage drove 60%+ CTR, outperforming the ~40% we saw when it sat at the bottom — without hurting engagement or retention. Not something I would’ve agreed to as a designer earlier.

Keep the story, from hook to completion

Imagine seeing an offer outside a shop — “Clearance sale: Flat 10% off on all items.” You walk in, but inside, no price tag mentions it, and no salesperson acknowledges it. You start to wonder: Did I misread that? Was it just bait? That break in continuity decays trust and leaves you feeling misled.

Digital products work the same way. A good campaign or growth experiment need to hook the users, and carries it through the journey thru copy and visuals. In our case, we created a payment reward experiment for one of our hypothesis on an insight. Hook on the banner “₹50 off on your first UPI payment” carried thru the entire payment journey and ended with an acknowledgment on success screen. This ensured that users were confident and invested no matter how many number of steps there were.

As we build more products and flows, it gets easier for us to imagine user journeys. But moving from 80% to 95% impact requires a deeper sensitivity to the subtle cues that influence human behaviour. This experience taught me just how powerful small shifts , a single line of copy, a well-placed visual, etc. can be in driving large-scale movement. Growth-focused design at its finest.

Shape Behaviour, Not Just UX: Applying a Growth Lens to Product Design was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every new year, many people sign up for gym memberships with the dream of getting fitter. Brochures promise toned bodies and healthier lives.

New gym members often walk in, excited by the possibilities. But without a plan, guidance, or meaningful interpretation of progress, motivation fades.

It’s the same with digital products. Users try a product — hoping to realize the dream they were sold. But if the product doesn’t reflect that vision, or help users visualize how today’s actions lead to their goal, even the smoothest workflows won’t sustain their momentum.

I came across the “Value Realization” framework in my current role at Powerplay. Earlier, account managers manually synthesized data to show value to decision-makers during renewals or pilot conversions. We realized the product needed to self-serve these insights, allowing users to naturally experience the promised value.

This article brings together the learning of applying this principle in practice

Start with a Purposeful Onboarding

There’s no question why sign-up or login screens highlight the outcomes an app enables. But the story shouldn’t end there. Especially in self-serve products with longer onboarding journeys, constant nudges about what lies ahead — beyond just progress bars — are critical to keeping users motivated.

Make Promised Value Easy to Find

Users arrive with certain expectations — often shaped by what they were promised externally (Maybe your marketing website, value you heard your peer liking). But once inside, can they immediately recognize those values? Can they find the outcomes they were sold on? Do the labels, sections, and flows inside the product reinforce the same language and aspirations?

Keeping a consistent narrative between marketing touchpoints and your product makes it easier for users to find and act on the value they signed up for.

Know How Your Users Visualize Their End Goal

Understanding how users picture their goal shapes how you design information and flows.

Back to the gym example — goals can visualize differently: “Lose 2kg,” “5% body fat reduction,” or “42% target completed.” Each requires different ways to measure and reflect progress.

In the construction industry, owners seek real-time, structured visibility into their project’s progress and finances. Earlier, someone from the team would manually reconcile scattered data from site engineers, purchase managers, and accountants into Excel sheets — a tedious and error-prone process

At Powerplay, we focus on helping owners and their teams go beyond tables, creating meaningful visualizations that aid faster decision-making and daily work. We kept owner’s and other team member’s JTBDs in-check to create the logical visualisation that aids consumptions and their day-to-day work

Give a Hint of the Visualization Before Users Input Data

Even if you optimize effort in UX, users — especially during exploration — need a reason to invest effort. Zero states are powerful here. Use creative storytelling (through illustrations, dummy data, sample reports) to hint at the end value.

At Powerplay, we provided sample project reports tailored to different industry types (infrastructure, commercial, residential) so users could see how their data would be transformed — not just in sales calls, but also inside the product itself.

Sprinkle Nudges to Help Users get more benefits

Depending on how structured an organization’s processes and roles are, teams use the product at varying levels of depth. While we optimize for early success regardless of process maturity, it’s equally important to help users realize what deeper value they might be missing.

Many organizations using Powerplay for progress tracking don’t have all the necessary data when they start. Through subtle nudges — like adding task dates to identify delays or creating task dependencies to estimate projected end dates — we help users gradually unlock richer insights.

These prompts aren’t just feature suggestions — they expand user understanding of what’s possible, improving engagement and long-term retention.

The whole framework, in essence, is about designing backward from the user’s end goal.

At Powerplay, we’re integrating this philosophy into our roadmap — constantly prioritizing features that help users self-realize the value our platform can deliver, making bandwidth for account managers or trainers.

Help Users realize the value your Product promises was originally published in Powerplay on Medium, where people are continuing the conversation by highlighting and responding to this story.

I took on the role of leading a design function for the first time in my career at Powerplay last year (read more about my decision here). Unlike onboarding in my previous junior or senior roles, I knew this wasn’t just about setting myself up as an individual contributor.

To add to the challenge, two designers had recently moved on, leaving no one to review the designs that were about to be handed over for development. Several major product initiatives were lined up for the upcoming quarter — each requiring a deep understanding of complex systems, interconnected workflows, and multi-layered user journeys. Clearly, my “first day” had to start unofficially, well before my actual joining date.

In this article, I reflect on the things I did before my first day to prepare for the expanded responsibilities in this new role. While the basics remain the same — getting to know your team members and key stakeholders, understanding the users and the product, and familiarizing yourself with current processes and practices — there were a few lessons that helped me hit the ground running.

Using user research artefacts to synthesys the information dump

First things first — I had to develop a strong understanding of the domain, the system (both product and service), and the users. Besides insights from product and business stakeholders, I had access to sales, training, and customer feedback calls. (My founder even suggested I join these calls personally and use the product myself to form an unbiased opinion.)

When you have too many sources, without a clear structure or defined outcomes, it’s easy to fall into the rabbit hole — getting overwhelmed by interconnected, overlapping information.

To stay focused, I created a simple research template on FigJam. This template outlined the key information I wanted to uncover: Domain, Product and business vision, User personas, their Workflows and relevant product and business metrics

I took this board to the meetings with stakeholders. It helped me have clear takeaways from each conversation and identify actionable items for both myself and the stakeholders (helping me fill the gap if ever comes a situation).

The filled FigJam board eventually became a guide for my first hire in the design team, helping them make sense of the complex system and get up to speed with ongoing work quickly

Early involvement in ongoing work

This one goes without saying. Even though I didn’t have full context of the entire product yet, I carved out an hour or two each day to join planning meetings and design critique sessions. This helped me:

• Assess the strengths and areas for improvement of the existing design work, while getting a feel for collaboration dynamics, processes, and quality standards.
• Prepare myself to contribute as an individual contributor from day one, without feeling like I was starting from scratch

Understanding design challenges from other leaders

Beyond understanding the product and processes, I used my meetings with other leaders to gain insight into how they perceived design and what challenges they were facing.

From Support/Training team : “There’s a big backlog of small issues (heuristic/comprehension-related) raised by customers, but we’re struggling to get them prioritized.”

From tech team : “Design hand-offs are incomplete. A lot of back-and-forth during sprints leaves less time for developers to polish the final product.”

From Founder : “Less tech-savvy users find it hard to transition to Powerplay because of usability challenges. We want to help decision-makers realize the platform’s value sooner, but such UX initiatives haven’t been prioritized recently.”

you get the gist…

I consolidated all these insights and discussed them with the founders. We agreed to make small, quick-win improvements in every sprint while also allocating extra bandwidth for UX enhancements based on key design themes identified in our 6-month product roadmap

Shift my mindset on scope of impact

In my previous role as an individual contributor, I focused on implementing best design practices, aligning stakeholders, validating my designs, and measuring success. But this new role demanded a broader perspective — both short-term and long-term — on how design thinks and contributes to business goals.

Drawing from others’ experiences and reflecting on what I’d observed from my past managers, a few things stood out:

• You’ll need to drive cultural shifts (think getting people to care about the little details or encouraging teams to use better research frameworks in product workflows). Spot the gaps, align with the founders, and tackle them one by one
• Learn about the business goals and how design initiatives can tie to meet them
• Look beyond product design. I realized early on that the power of visual storytelling could be just as effective in marketing initiatives
• It’s not just you, but your team as whole. Notice the unique strengths each team member brings and help them showcase the skills that benefits others too. (E.g. Sharing design documentation as resources for tech and product team to reference later)

I hope this story resonates with those who’ve recently stepped into new responsibilities. If you’re looking for a product design opportunity or have a similar experience to share, I’d love to hear from you!

Designing India’s Most Loved Financial App — Part 1/6

Bank balances. Investments. Credit limit. Monthly expenses. Each of these numbers makes us feel something — proud, anxious, confused, or confident. And how we feel about these numbers changes as the month progresses.

At Jupiter, numbers are at the heart of everything we do. That’s why while redesigning the app, we paid special attention to how users see and interact with the numbers that represent their financial wellness. It had to be in a way that gives confidence, builds trust, and inspires action.

In this article, we delve into the choices and changes we made to let numbers take centre stage.

Hero the numbers that users care about

Most often, users open the Jupiter app multiple times a day to either pay someone quickly, check their account balances, track their spends, or how their investments are performing.

In the newly redesigned Jupiter, these numbers are front and center, and are super easy to just scan and track. We achieved this by employing strong contrasts in size and selecting a contemporary typeface that ensures numbers remain the focal point on the screen.

We extended this philosophy to any page/flow in the app where the hero number sets the stage for what follows, whether it’s on the investment holdings, showing you the eligible credit limit for loan or category transaction list pages.

Giving numbers a distinct identity

While we had picked a new and distinct font for the rest of the app, we realized using that same typeface for hero numbers did not quite achieve the effect we wanted — they were still easy to miss and lacked personality.

So we went back to the drawing board and after countless iterations, we landed on a typeface with a bold personality that didn’t compromise on function. The result is evident in our selective use of this typeface for only the two largest sizes in our design system.

Ensuring Reliability and Trustworthiness

People entrust their hard-earned money to us and rightfully expect transparency, reliability, and factual accuracy from our platform. At Jupiter, we’ve been steadfast in meeting this expectation, carefully crafting our experience to maintain reliability and trustworthiness. These practices extend to our new user experience as well.

Transparency in Numbers

On opening the app, important data such as account balances, current investment value, and transaction history is instantly refreshed across the app. In case of weak internet or an issue getting the latest data, we provide cached data along with a timestamp mentioning when the data was last refreshed.

Privacy for Personal Finances

Any details about your money are extremely personal to you. To keep your account balance, net worth, and investment value private, Jupiter hides the number when you first open the app. Doing this protects your privacy from onlookers in public places. You can tap the hidden number to see it anytime you want.

Don’t forget the brilliant basics

Our goal with the redesign was to enhance the user experience beyond our users’ basic expectations. Therefore, we kept certain practices in check which users except as the base requirement

Easy Understanding of Investment Returns

Many times a day, all you want is just want a glance at how your investments are performing. With a consistent pattern showing returns (positive in green with a + symbol and negative in red with a — symbol), you can quickly check your Mutual Fund, Digital Gold, and Fixed Deposit performance.

Adaptability to the scenario

Is a one-size-fits-all approach right for the use of typography inside a money app? We wanted to make numbers front and centre but we couldn’t use the same size for typography for balances ₹100, ₹1000, ₹1,00,000, ₹10,00,000, and ₹1,00,00,000. We also didn’t want to write ₹11,34,832 as ₹11.34 lakhs because it is against our principle of transparency. We decided to create a larger font for values up to 9,99,999 and a smaller font for numbers 10,00,000 or above. This approach keeps the number front and centre, without sacrificing readability

Showing decimal values

Accuracy in data adds to users’ trust. Hence, people can see their accurate account balance, up to 2 decimal digits.

This article is co-written by Akshay kumawat and Naveen Panwar.
Read about more of our principles on the following blog.

Design Principles at Jupiter

❤️ See how the design team at Jupiter is helping millions of Indians improve their financial wellness. Find us on Instagram and Twitter

Put Numbers in the Spotlight was originally published in life-at-jupiter on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this blog, I have tried to walk you through the process I followed while working on an assignment during my job hunt. The assignment was to be evaluated on the basis of how deeply I explored the problem space, and how I translated identified objectives into a meaningful solution.

The Challenge

Create a solution for people visiting an unfamiliar city to visit areas of local interest and shop for gifts to take back home(souvenirs, delicacies, etc.). The product is supposed to get live within 3 months, Plan out the first launch clarifying your business and product understanding.

The decision regarding whether to move forward with web or mobile app-based product or how the product or business will work was left for me to think upon.

The Approach

The first step was to understand the problem statement. For this, I started by asking a lot of questions. Here’s a list of some basic questions that one should consider asking at the start of the project:

1. What are we trying to achieve?
2. Who are we designing solutions for?
3. Why do they need it?
4. What are the constraints?

I then created a design process that helped me get answers to the above questions.

Identify goals

At this stage, I tried to develop clarity on the purpose of the product by writing down the Product vision. I also set the direction for the research stage by writing down the questions that should be answered from my research. Getting clarity in initial stage ensured that I cover enough so that I can start designing solutions with proper context considering the time constraints.

Product Vision

Product vision helped in understanding the context of the existence of an idea. Based on the challenge, I formulated the vision as

“To simplify and redefine the experience of the way people get access to the culture and traditions of cities in our country.”

What did I want to know from research?

1. Tourism ecosystem/Market opportunities
2. How revenue will be generated(business standpoint)
3. Target customers
4. Constraints

Research

Understanding ecosystem

I started by exploring the tourism industry to identify the people involved in it and thus, identify relevant business opportunities. So, I asked myself a basic question “Why do people travel?”. People want to do activities different from their daily routine to create memories. Captured photos or purchased souvenir helps them recall their experiences. Thus, tourism in itself plays an important role in the generation of employment by enabling local people to earn money by showing culture and customs to people who came from far-off places.

Knowing the core reason, I then divided the city shops influenced by tourism into 4 categories. Taking examples of shops from Jaipur(popular travel destination in India) ensured that I wasn’t missing any edge cases.

Takeaway from this classification:
1. Most recognized shops will be willing to gain demographic information to modify their inventory on the demand bases

2. Shops located outside the center of the city often lose potential customers as these shops are less likely to go under notice. They need visitors to know about their shop

Identify Target user

I categorized the buyer on these shops into Local people and visitors. It is evident that the city’s culture and local items will excite a visitor/tourist more than a local and thus “Visitors” are target customers for my product.

User Interviews

In order to understand the needs and existing way of doing things, I asked both visitor and local shopkeeper through user interviews. The questions were framed in order to cover up the issues related to the entire process starting from open-ended questions to the more specific ones aligning to the challenge.

Then I talked to the owner of a local handicrafts item located far from the city hotspots, as knowing the viewpoint can lay the foundation of my business strategy as they are the ones who get very less visitor because of their location.

With an understanding of my user and the ecosystem, I was able to answer the question I wrote in Identify goal stage.

1. Market opportunities
   A Local shopkeeper wants visitors to know about their shops and eventually more customers. The product can help provide them a platform to showcase their catalog of souvenir items.
2. Revenue
   In order to show their catalog, shop owners will have to pay the money. But a local shopkeeper would want to see if their investment is actually helping them grow their business. Popular shops, on the other hand, would like to learn on the demographics. A separate app would be needed to help them track footfall, purchases made due to marketing on the platform.

Understanding the competition

With a basic understanding of how my product will work from a business standpoint, I studied major competitors in both fields(showcasing local market online and assisting users in roaming around the city’s local hotspots).

Define

At this stage, I tried to make use of the information gathered in research stage to draw meaningful insights.

User Persona

I started off by creating a persona of my target user “traveller”. This includes basic information like name, occupation, age, a brief intro that relates to the challenge.

Creating scenarios

I created scenarios to find out the use cases of the product. This helped in visualizing how my product can fit in as a solution to the problems they encounter. In order to cover possible issues from the beginning, I created a user journey.

Every identified pain point is an opportunity to improve

1. Ankur wants to plan a trip with his friends and starts searching for different places to visit and about the city
   Pain point: Most of the information related to a place is distributed over different websites. Participants need a discussion before making a decision. A common way to do this by creating WhatsApp or FB groups.
2. A group of friends reaches a city and have few local hotspots in mind which they have searched already, but now they have to plan their days for the trip
   Pain point: Being unaware of how the hotspots are scattered in the city, their group need to put a lot of time in planning out the days.
3. Akshat went to one of the souvenir shops but has limited money left to buy 1 item at max
   Pain point: Tourist is usually unaware of the souvenir or special items in the city. Knowing about the importance of an item can help them make a choice.
4. One of the friends want to buy a unique item, but their group is in a hurry and thus he needs to find a shop nearby
   Pain point: There is no specific way to search for a shop based on an item and thus has to ask local people.

Using constraints

Since the time span for launch is 3 months, it’s not possible to meet every need and requirement of the users. To prioritize on features, I used a 2x2 Matrix approach. This helped me in understanding which features are important from the business and user perspective. Only those features lying in the 1st quadrant are considered for creating the first product.

Creating assumptions for a possible solution

In order to create and support a solution to the problem identified, I made some assumptions.

1. In order to increase footfall and user onboarding, the company will provide users some discount on making in-app purchases through “Save deal” feature.
2. Most of the shopkeepers are not that tech-friendly and thus simply saying that my platform can get them more customers will not help. They need validation, and thus an in-app purchase is important.

In order to execute the in-app transfer, the user will first save a deal he likes. Then on his personal visit to the shop, show the QR code generated at the time of saving the deal to process the transaction.

This solution can also remove doubts about the quality of the product and its price. An actual visit to the shop is also something that someone who came with the intent to know about the city will do.

Design Objective

This was the final stage before exploring out IA and wireframe of the product. It consisted of a set of small objectives that were crafted on the basis of whatever done before to help achieve the vision created in the first stage. These objectives would be visible in the solutions that we will design.

1. Provide an in-app platform for participants on a trip to share relevant location to visit or shops to explore in a city. Help them show their opinions
2. Create a concept to help those who haven’t planned a trip but still wants to explore the city
3. Make the discovery of souvenirs or special items easy for users
4. Create a flow that supports in-app purchases of the souvenir items from shops showcased on the platform.

The solutions reflecting these design objectives will be explained in detail in another blog. Thanks for reading this so far. If you like this article, please hit the 👏 button and let others know about this too. If you have any feedback on the process or have any doubts, do comment below.

Happy to hear from you! Follow me on twitter, dribbble for more design related shares.

I am a final year student at Indian Institute of Technology, Roorkee. Passionate about creating digital products that can make life of the users easier. You can look at my design portfolios on Behance and dribbble here.

I have interned at Olacabs Consumer Product design team in summer 2018, who believes in creating a valuable experience for every interaction with a simple working methodology. Put yourself in the shoes of your user, i.e. what are there concerns and expectation and then approach accordingly. I find myself inquisitive enough to explore the depths in the field of design, aided with a great appetite to learn more.
You can learn more about how I make my way to the products that keep in mind the end users by reading the following blogs, or visiting my design portfolio on Behance too. I hope you all will give at least a single look at my blog. Every single suggestion will make a count for me.

• How Appetizer ‘digitized’ Mess management system at IITR
• This App will help you bunk classes, MORE INTELLIGENTLY

Let’s Connect!

Interested in having a conversation, or got something on which we can work together? feel free to connect me at aks.kumawat1@gmail.com

You can follow me on Behance and dribbble, if you like my work.

The Problem

Quite often it so happens that our tummies and the menu of our hostel mess have a conflict of interest. As a result, we either opt for the canteen to fill our bellies or make plans for treats. But the mess administration is quite unaware of this, and the quantity of food prepared for a meal is still on the assumption that most of the students consume the food provided at the mess. This situation might seem admissible on the weekdays, as the number of such students is less, but it costs a significant amount of food wastage in the weekends and holidays. Also, students are still paying for the food which they are not even eating.

In the era when digitalization is making every other field efficient, why keep the mess system away from it. We, as students decided to tackle this issue and tried to come up with a digital solution which not only addresses it, but remains as authentic as possible, giving the administration the power to control in order to ease out the mess management system in IIT Roorkee. It was my job to give this project a design vision to let it stand out of all campus applications.

Product’s Vision

In Product Vision, we define the ultimate goal of the product

Since the goal was to create an overall management system, we were supposed to address every issue related to mess, be it the menu for the day, feedback or notices, reducing the food wastage, or giving something in return to the students who are not attending the meal. Clearly, to bring these features to the ground, it was important for the administration to hold the power to update and fiddle with the application.

Design Vision

Design vision defines the direction for user experience and user interface

We knew since the beginning that attending a meal in the mess is a daily routine of students living in a hostel, and thus the app had to be designed in a way that it can resemble the activities and experiences of students in the mess, from marking attendance to getting a meal, etc.

Product features

After a number of meetings with the college administration, we were finally able to come down to the following features:

1. Displaying the mess menu.

2. A self-contained system for feedback and suggestions.

3. Leave the meal feature to let students leave the meal they are not interested in, or cannot attend which will then be notified to mess manager before the meal is cooked.

4. An on-demand notifications system and meal reminders.

5. A dashboard for mess managers, and concerned authorities for posting, updating the mess menus, attendance tracking, monitoring daily leaves and feedback and pushing notifications directly to the students.

App Design

Login Procedure

Since the administration already had the credentials of all the students based on their enrollment number, we decided to choose enrollment number and password as credentials to enter the app. Here the illustration used in the login screen was inspired by the biometric attendance system in our mess.

The Home Screen

Broadly, the purpose of the home screen is to show detailed mess menu of the day, allowing students to leave the upcoming meals and provide feedback on the meals that already happened. The user can also get an overall glimpse of the week’s menu by switching to Week view. The Week view was designed in accordance with the menu shared on mess forum so that people feel a similarity between both. Since Leave was an important feature of the application, I decided to use a Floating Action Button(FAB) to allow the user to directly check out from the app, if they are not attending the future meals.

A lot of designers argue against the use of hamburger menu, as it makes features undiscoverable. But in the present context, not keeping it would mean hiding the content which is important for the users to see without scrolling. Also,

Since everything about the primary screen is to let the users leave the upcoming meal, and give feedback on them, using this menu keeps the users focused on the task.

In the initial sketches and mid-fidelity wireframes, I decided to let a special meal from each day to be highlighted on the top, showing the current day on the upper right corner and the day selector named by days as “MON”, “TUES”, “WED”, etc. But this convention was leading to confusion in case user tried to look for a meal in last week, as there was no indicator to show current week, and not every day had a special item. Also, even if it did, it would increase the work from administration side to specify special meal item every day without adding anything valuable to the experience. So I rejected it and came up with a different layout, including both day and date to let the users easily identify the current week.

Process of designing the meal card

In beginning, we decided to show “leave” and “feedback” icon to let the user leave an upcoming meal or provide feedback for a meal that he/she attended respectively. Initial prototypes helped us in identifying the points where the users were struggling:

1. Users were thinking “feedback” icon was meant to edit the content of the card, not to write feedback.

2. “Leave” as an icon was creating a confusion among the users, it was important under this condition to trigger either a Toast or Snackbar to show that their response was received.

So, I decided to resolve these two issues by:

1. Placing a different icon for feedback to better reflect its purpose.

2. Placing a switch instead of the icon to perform the Leave action. With switch ON means you are attending the meal, and OFF you are not.

The Leaves Section

Users can leave the meals they are not going to attend in future. One of the ways was by switching OFF the meal card. In case they wanted to leave more than one meal in sequence, clicking on every single card was definitely not the solution, so we came up with two possible methods:

1. Ask for duration of leaves

2. Check-in and Check-out

Both of the ways have their own pros and cons, some of them are :

1. There is a very high possibility of users forgetting to check-in back into the app when they come back from vacations or break.

2. Users generally have an idea of when they will be coming back to their hostel, so asking for start and end meals seemed plausible, but it required extra inputs from the user.

“In the end, everything falls at how can you get things done in minimum steps without taking control from the user’s hands.”

Thus we decided to go with Check-in Check-out method as it allowed the user to leave all the future meals with a single click and was easier to implement from a technical perspective. It was possible to confront the issue with the help of a notification system.

To improve accessibility of this feature, I decided to give a FAB on the home screen. Whenever the user checks out from the app, an indicator appears on the home screen and all the future meal cards get disabled. On clicking it, the user will be transferred to Leave section where the user can check-in back or access other options.

In the section itself, users can see the remaining count of meals they are allowed to skip in given semester, a list of upcoming recent leaves, which they can cancel if they wish to. Since students were getting the rebate for the meals they leave, it was important to give them a history of meals they left in the past.

Since the number of meals a student can leave in any semester is quite significant, so I decided to classify meals so that they need not to scroll unnecessarily to see a skipped meal long ago. I decided to place a filter for ease of access. For all those meals which were skipped in sequence, it was better to show a condensed view showing counts of leaves along with meal details.

Because of the rebate feature, there was a huge risk of students leaving the meal intentionally from the app, and then attend the same meal in the mess. To avoid this, it was important to make biometric attendance compulsory in mess. Also, every time a user leaves a meal, that meal card will show a tag indicating meal has been skipped from their side. The meal tag will update to “left” only when it is matched with the biometric.

Feedback Feature

Next feature was to give a self-sustained system for feedback not only on food but on a variety of other mess related issues. Users were allowed to create a new feedback related to any particular meal which they have attended in two ways :

1. By clicking on feedback icon on meal card

2. Through feedback section itself

This system also includes an “Inbox” section to maintain a list of feedback on which users have received the response and a “Submitted” section for all those queries which weren’t addressed yet. I allowed the user to get access to recent three feedback in both of these categories without getting into their sections.

Conclusion

The response received from the users was overwhelming. The illustrations and UI of the app were relatable to the actual activities in the mess and this kept the users engaged and led them to explore more. On analyzing the statistics of the app usage we found that the difference between the students leaving the meal using the app and students not attending the mess was low. This indicated that the number of daily active users remained high and steady. Also we felt that the usage of the app led to discipline in the mess and students felt the need to use the biometric attendance. The wastage of food was reduced to great extent.

Big thanks to Kush Taneja, Chirag Maheshwari, Harjot Singh Oberai, Aniket Singh, Rohan Bhatia, Vishwas Mittal to bring this idea to reality, and Anant Shandilya for helping me out with the illustration design for this project.

You can See the full Project and Other Screen on Behance

This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.