Nov 9th, 2023
Conditional Controls
Design documentation
User testing
Hi there, I’m Mehak Samaiya, a Product Designer and a Scribbler. Here, I’ll talk about designing inter/intra-dependent conditional controls with one of my projects under Juspay.
Nov 9th, 2023
Conditional Controls
Design documentation
User testing
Hi there, I’m Mehak Samaiya, a Product Designer and a Scribbler. Here, I’ll talk about designing inter/intra-dependent conditional controls with one of my projects under Juspay.
Tip for readers
This writeup is divided into two sections. Starting off for general readers who are looking for a ready-to-plug-n-play solution using a Juspay example, segueing into next part for the readers who’d like to deep dive into the how of that solution.
Preface
I’ve been designing Merchant-facing or B2B tools with my team at Juspay for past 1.5 years. And incidentally, each of these tools seem to possess conditional controls in one way or other. So, it made sense to dive deep into designing the best possible experience around this. One that can be scaled across different use cases, flows, or tools.
What are "Conditional Controls"
Conditional controls are used to achieve dynamic outcomes by triggering a series of controls that in-turn depend on different conditions. Let’s think of Conditional Controls in terms of roads and destinations. There are multiple destinations (outcomes) and, each of these destinations can be accessed with multiple roads. At every road intersection (condition), you take a decision (action) to move towards the destination. Incase all the roads are blocked, you decide for an alternate destination or take a U turn (fallback).
If you’re wondering why I use an example like that instead of the if/else conditions used in code - is because I don’t mean to talk only about code. I’d like to talk about conditions in a broader scope of application - where they are controlled visually through an interface. An interface that’s user friendly, sensitive, and transparent. Where there is no guess game about the outputs - what you command is what will get executed.
Application of Conditional Controls
Products that use conditional controls generally want to:
1) Cater to multiple dynamic outcomes, and
2) Give users complete autonomy to achieve these outcomes.
A common example of conditional controls can be seen in workflow automation tools like Jira and Mailchimp. Every workflow is sensitive and affects real users and real businesses. Every single control counts. It is the onus of the system to be a guiding light to the users. Noticeably, the applications are not just limited to workflow management. These products let users exercise full flexibility over their actions at every level - from rule name to rule game! Plus, as soon as we aim “complete user autonomy,” we introduce plethora of permutations and combinations in the field. And, not all of these PnCs will be valid. The system then needs to be fool-proof and fail-safe to be able to handle all the undefined and invalid cases.
How can your product make use of it? Let’s see a modular approach.
Firstly, list down what your product has to offer in terms of output. What is the form of that output? Is it just one form of output that you support? Do you want to support multiple outputs real-time? Once you know what you offer, try to modularise the ways in which those outputs can be achieved. Observe if any two or more controls are mutually exclusive. Try to hide controls that are indirect or dependent. Make groups using relevant information and structure it in a way that user feels like she is visually setting an output directly.
Basic
Intermediate
Advanced
Conditional
On/OFF
Control Title
Control Description
💡
With tag
Control Title
Control Description
Tag eg: “International use”
💡
Basic controls can be used when the expected output is just to toggle the state of something. Eg: Display or not display surcharge message, Enable or disable offers, etc.
Education about the Control (are you still using the “i” ?)
Interactive area
Let’s take an example. Juspay is a B2B payments company. Juspay has made a Payment Page builder, called Studio. An application that helps apps/companies build a fully functional end-to-end Payment experience. But Juspay wants to give users “a no-code interface” to easily build these experiences. Following the modular approach, let’s break down what Juspay offers:
Output: A fully functional good looking Payment experience
Possible Inputs: Design related (color, font, layout, etc.), Flow related (payment options, ordering of those options, outage, retry, etc.), Other parameters (platform, amount, PIN code, etc.)
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
Other applications of Conditional Controls
You may use the skeleton to turn any tool to a No-Code interface. An extended simple application of conditional controls is search filters. Filters when broken down into a modular user friendly options help users search faster and better. Some good experiences can be seen in Notion table filter, Slack message search, Jira advanced search, Framer editing, etc.
Diving deep into the approach
You made it till this part? The writer in me feels accomplished! I’ll continue talking about the approach we took to design the conditional controls in the “Payment Page builder” or Studio product.
A brief history about the product, Studio
Juspay has an offering called Payment Page where Juspay builds end to end Payment experiences for merchants like Big Basket, Airtel, Swiggy, Zepto, Acko, etc. Naturally, each of these companies needs a Payment Page of their own with more or less similar customisations.
Never forget the fundamentals
Typically any Payment Page has the lifecycle: Design → Test → Release → Maintain. Now within Design, there are broadly two areas: Design (UI) and Control (Payments flows). We (Design, PM, Dev) used to audit the code, remove the redundancy and surface the Design customisations on the interface. We presumed that both new and repeat users will predominantly use Design more than Controls. Continued this for months, only to realise that our presumption was wrong.
In all these MVP releases and refactoring, we missed one of the most fundamental user requirement. Actually, missed is an understatement - since we were so deep into the refactor, we forgot talking to the users. Turned out users needed to control the payments options as much as they wanted to customise the designs. All of this irrespective of the type of user (new or repeat).
Users come with varying use cases in mind - they may want to test a design, or add some offer element, or some payment option, or just want to do a minor platform specific change. With this wide a spectrum of usage, weightage of any configuration cannot be determined just by the stage of user.
By the way
Isn’t it cool, designing for inception - Juspay is designing something so their users can use it to design something for their users. Tell me you get it?
Process
So, we sat with the code again. Brought the 300+ key-value pairs into an excel, understood the shit out of them. Started a documentation to record all this. We absolutely didn’t want to leave any Design Debt at all. Once we understood the key-value pairs, we tried to regroup and categorise them.
Categorisation went almost 5 levels deep so we can come up with a meaningful grouping and translate it to a usable UI. We also found certain conditions and JS expressions under the process. It was important to understand the weightage of every control to be figure out the information architecture - when is the conditional control even used? How frequently or infrequently? Can users use its full potential or do they need some guidance?
For every design iteration, we conducted critique sessions cross teams, not just with designers. We tried to have atleast 1 senior developer, 1-2 PMs, 2-3 developers in the same. This went on for about 3-4 months rigorously for us to reach a confident enough product design. Post a critique, we try to conduct short user testing sessions infrequently with the internal users on smaller parts of design; 2-4 screens at max, or one end to end flow. Testing anything more than 4 screens overwhelmed and blurred the feedback. We’ve handed off the dev specs and moved to the next part of product design. Here’s a glimpse of how we’re using Figma and Confluence as the mode of all official hand-offs, QA, and to record all iterations.
By the way
I am thankful to the team and process to help me upskill my approach towards any problem - however messy and chaotic things seem in the beginning, we’ll find a way around it. Sure, we’ll face dips on the way. Sure, it will be hard to bring everyone on the same page. But just a little bit patience and far-sightedness will help us get through. And lets accept it, heated arguments are fun! :p
Highlights for me as a designer
Having been a part of the product “Payment Page Builder” from Day 0 since 2020 as an intern, I’ve seen almost 2 lifecycles of this product. Highlights, to name a few:
Extensive Design Documentation to log daily updates, helping anyone understand the rational behind each design decision and approach. I wish we had started doing this sooner!
Design being used as an idea propagator and communicator. Design being used as the pivotal reference to refactor code. The in-sync communication of devs-designers-PMs helped us all be on the same page at all times.
Getting early feedback from users and getting more eyes on the product. You can’t be afraid of your approach or design getting cancelled. At times, listening to different perspectives can help you stay grounded and keep you out of the bubble!
Note of thanks
Thanks to Samit, Anirudh, Naman, Karun, Venky, and so many more people for being ever so involved and open in the Design process. This has been a really upskilling project (and continues to be one), and it wouldn’t have been possible without your support!
Drop me a feedback!
Have any queries or want to know more? Feel free to shoot a DM over Twitter or LinkedIn.
Conditional Controls
Nov 9th, 2023
Design documentation
User testing
Hi there, I’m Mehak Samaiya, a Product Designer and a Scribbler. Here, I’ll talk about designing inter/intra-dependent conditional controls with one of my projects under Juspay.
By the way
I am thankful to the team and process to help me upskill my approach towards any problem - however messy and chaotic things seem in the beginning, we’ll find a way around it. Sure, we’ll face dips on the way. Sure, it will be hard to bring everyone on the same page. But just a little bit patience and far-sightedness will help us get through. And lets accept it, heated arguments are fun! :p
Tip for readers
This writeup is divided into two sections. Starting off for general readers who are looking for a ready-to-plug-n-play solution using a Juspay example, segueing into next part for the readers who’d like to deep dive into the how of that solution.
Preface
I’ve been designing Merchant-facing or B2B tools with my team at Juspay for past 1.5 years. And incidentally, each of these tools seem to possess conditional controls in one way or other. So, it made sense to dive deep into designing the best possible experience around this. One that can be scaled across different use cases, flows, or tools.
What are "Conditional Controls"
Conditional controls are used to achieve dynamic outcomes by triggering a series of controls that in-turn depend on different conditions. Let’s think of Conditional Controls in terms of roads and destinations. There are multiple destinations (outcomes) and, each of these destinations can be accessed with multiple roads. At every road intersection (condition), you take a decision (action) to move towards the destination. Incase all the roads are blocked, you decide for an alternate destination or take a U turn (fallback).
If you’re wondering why I use an example like that instead of the if/else conditions used in code - is because I don’t mean to talk only about code. I’d like to talk about conditions in a broader scope of application - where they are controlled visually through an interface. An interface that’s user friendly, sensitive, and transparent. Where there is no guess game about the outputs - what you command is what will get executed.
Application of Conditional Controls
Products that use conditional controls generally want to:
1) Cater to multiple dynamic outcomes, and
2) Give users complete autonomy to achieve these outcomes.
A common example of conditional controls can be seen in workflow automation tools like Jira and Mailchimp. Every workflow is sensitive and affects real users and real businesses. Every single control counts. It is the onus of the system to be a guiding light to the users. Noticeably, the applications are not just limited to workflow management. These products let users exercise full flexibility over their actions at every level - from rule name to rule game! Plus, as soon as we aim “complete user autonomy,” we introduce plethora of permutations and combinations in the field. And, not all of these PnCs will be valid. The system then needs to be fool-proof and fail-safe to be able to handle all the undefined and invalid cases.
How can your product make use of it? Let’s see a modular approach.
Firstly, list down what your product has to offer in terms of output. What is the form of that output? Is it just one form of output that you support? Do you want to support multiple outputs real-time? Once you know what you offer, try to modularise the ways in which those outputs can be achieved. Observe if any two or more controls are mutually exclusive. Try to hide controls that are indirect or dependent. Make groups using relevant information and structure it in a way that user feels like she is visually setting an output directly.
Basic
Intermediate
Advanced
Conditional
On/OFF
Control Title
Control Description
💡
With tag
Control Title
Control Description
Tag eg: “International use”
💡
Basic controls can be used when the expected output is just to toggle the state of something. Eg: Display or not display surcharge message, Enable or disable offers, etc.
Education about the Control (are you still using the “i” ?)
Interactive area
Let’s take an example. Juspay is a B2B payments company. Juspay has made a Payment Page builder, called Studio. An application that helps apps/companies build a fully functional end-to-end Payment experience. But Juspay wants to give users “a no-code interface” to easily build these experiences. Following the modular approach, let’s break down what Juspay offers:
Output: A fully functional good looking Payment experience
Possible Inputs: Design related (color, font, layout, etc.), Flow related (payment options, ordering of those options, outage, retry, etc.), Other parameters (platform, amount, PIN code, etc.)
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
Other applications of Conditional Controls
You may use the skeleton to turn any tool to a No-Code interface. An extended simple application of conditional controls is search filters. Filters when broken down into a modular user friendly options help users search faster and better. Some good experiences can be seen in Notion table filter, Slack message search, Jira advanced search, Framer editing, etc.
Diving deep into the approach
You made it till this part? The writer in me feels accomplished! I’ll continue talking about the approach we took to design the conditional controls in the “Payment Page builder” or Studio product.
A brief history about the product, Studio
Juspay has an offering called Payment Page where Juspay builds end to end Payment experiences for merchants like Big Basket, Airtel, Swiggy, Zepto, Acko, etc. Naturally, each of these companies needs a Payment Page of their own with more or less similar customisations.
Never forget the fundamentals
Typically any Payment Page has the lifecycle: Design → Test → Release → Maintain. Now within Design, there are broadly two areas: Design (UI) and Control (Payments flows). We (Design, PM, Dev) used to audit the code, remove the redundancy and surface the Design customisations on the interface. We presumed that both new and repeat users will predominantly use Design more than Controls. Continued this for months, only to realise that our presumption was wrong.
In all these MVP releases and refactoring, we missed one of the most fundamental user requirement. Actually, missed is an understatement - since we were so deep into the refactor, we forgot talking to the users. Turned out users needed to control the payments options as much as they wanted to customise the designs. All of this irrespective of the type of user (new or repeat).
Users come with varying use cases in mind - they may want to test a design, or add some offer element, or some payment option, or just want to do a minor platform specific change. With this wide a spectrum of usage, weightage of any configuration cannot be determined just by the stage of user.
By the way
Isn’t it cool, designing for inception - Juspay is designing something so their users can use it to design something for their users. Tell me you get it?
Process
So, we sat with the code again. Brought the 300+ key-value pairs into an excel, understood the shit out of them. Started a documentation to record all this. We absolutely didn’t want to leave any Design Debt at all. Once we understood the key-value pairs, we tried to regroup and categorise them.
Categorisation went almost 5 levels deep so we can come up with a meaningful grouping and translate it to a usable UI. We also found certain conditions and JS expressions under the process. It was important to understand the weightage of every control to be figure out the information architecture - when is the conditional control even used? How frequently or infrequently? Can users use its full potential or do they need some guidance?
For every design iteration, we conducted critique sessions cross teams, not just with designers. We tried to have atleast 1 senior developer, 1-2 PMs, 2-3 developers in the same. This went on for about 3-4 months rigorously for us to reach a confident enough product design. Post a critique, we try to conduct short user testing sessions infrequently with the internal users on smaller parts of design; 2-4 screens at max, or one end to end flow. Testing anything more than 4 screens overwhelmed and blurred the feedback. We’ve handed off the dev specs and moved to the next part of product design. Here’s a glimpse of how we’re using Figma and Confluence as the mode of all official hand-offs, QA, and to record all iterations.
By the way
I am thankful to the team and process to help me upskill my approach towards any problem - however messy and chaotic things seem in the beginning, we’ll find a way around it. Sure, we’ll face dips on the way. Sure, it will be hard to bring everyone on the same page. But just a little bit patience and far-sightedness will help us get through. And lets accept it, heated arguments are fun! :p
Highlights for me as a designer
Having been a part of the product “Payment Page Builder” from Day 0 since 2020 as an intern, I’ve seen almost 2 lifecycles of this product. Highlights, to name a few:
Extensive Design Documentation to log daily updates, helping anyone understand the rational behind each design decision and approach. I wish we had started doing this sooner!
Design being used as an idea propagator and communicator. Design being used as the pivotal reference to refactor code. The in-sync communication of devs-designers-PMs helped us all be on the same page at all times.
Getting early feedback from users and getting more eyes on the product. You can’t be afraid of your approach or design getting cancelled. At times, listening to different perspectives can help you stay grounded and keep you out of the bubble!
Note of thanks
Thanks to Samit, Anirudh, Naman, Karun, Venky, and so many more people for being ever so involved and open in the Design process. This has been a really upskilling project (and continues to be one), and it wouldn’t have been possible without your support!
Drop me a feedback!
Have any queries or want to know more? Feel free to shoot a DM over Twitter or LinkedIn.
Conditional Controls
Nov 9th, 2023
Design documentation
User testing
Hi there, I’m Mehak Samaiya, a Product Designer and a Scribbler. Here, I’ll talk about designing inter/intra-dependent conditional controls with one of my projects under Juspay.
By the way
I am thankful to the team and process to help me upskill my approach towards any problem - however messy and chaotic things seem in the beginning, we’ll find a way around it. Sure, we’ll face dips on the way. Sure, it will be hard to bring everyone on the same page. But just a little bit patience and far-sightedness will help us get through. And lets accept it, heated arguments are fun! :p
Tip for readers
This writeup is divided into two sections. Starting off for general readers who are looking for a ready-to-plug-n-play solution using a Juspay example, segueing into next part for the readers who’d like to deep dive into the how of that solution.
Preface
I’ve been designing Merchant-facing or B2B tools with my team at Juspay for past 1.5 years. And incidentally, each of these tools seem to possess conditional controls in one way or other. So, it made sense to dive deep into designing the best possible experience around this. One that can be scaled across different use cases, flows, or tools.
What are "Conditional Controls"
Conditional controls are used to achieve dynamic outcomes by triggering a series of controls that in-turn depend on different conditions. Let’s think of Conditional Controls in terms of roads and destinations. There are multiple destinations (outcomes) and, each of these destinations can be accessed with multiple roads. At every road intersection (condition), you take a decision (action) to move towards the destination. Incase all the roads are blocked, you decide for an alternate destination or take a U turn (fallback).
If you’re wondering why I use an example like that instead of the if/else conditions used in code - is because I don’t mean to talk only about code. I’d like to talk about conditions in a broader scope of application - where they are controlled visually through an interface. An interface that’s user friendly, sensitive, and transparent. Where there is no guess game about the outputs - what you command is what will get executed.
Application of Conditional Controls
Products that use conditional controls generally want to:
1) Cater to multiple dynamic outcomes, and
2) Give users complete autonomy to achieve these outcomes.
A common example of conditional controls can be seen in workflow automation tools like Jira and Mailchimp. Every workflow is sensitive and affects real users and real businesses. Every single control counts. It is the onus of the system to be a guiding light to the users. Noticeably, the applications are not just limited to workflow management. These products let users exercise full flexibility over their actions at every level - from rule name to rule game! Plus, as soon as we aim “complete user autonomy,” we introduce plethora of permutations and combinations in the field. And, not all of these PnCs will be valid. The system then needs to be fool-proof and fail-safe to be able to handle all the undefined and invalid cases.
How can your product make use of it? Let’s see a modular approach.
Firstly, list down what your product has to offer in terms of output. What is the form of that output? Is it just one form of output that you support? Do you want to support multiple outputs real-time? Once you know what you offer, try to modularise the ways in which those outputs can be achieved. Observe if any two or more controls are mutually exclusive. Try to hide controls that are indirect or dependent. Make groups using relevant information and structure it in a way that user feels like she is visually setting an output directly.
Basic
Intermediate
Advanced
Conditional
On/OFF
Control Title
Control Description
💡
With tag
Control Title
Control Description
Tag eg: “International use”
💡
Basic controls can be used when the expected output is just to toggle the state of something. Eg: Display or not display surcharge message, Enable or disable offers, etc.
Education about the Control (are you still using the “i” ?)
Interactive area
Let’s take an example. Juspay is a B2B payments company. Juspay has made a Payment Page builder, called Studio. An application that helps apps/companies build a fully functional end-to-end Payment experience. But Juspay wants to give users “a no-code interface” to easily build these experiences. Following the modular approach, let’s break down what Juspay offers:
Output: A fully functional good looking Payment experience
Possible Inputs: Design related (color, font, layout, etc.), Flow related (payment options, ordering of those options, outage, retry, etc.), Other parameters (platform, amount, PIN code, etc.)
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
First level of Grouping - Design and Flow Controls
Second level of Grouping - Payment options and Common features
Third level of Grouping - Individual Payment options
Fourth level of Grouping - Within a Payment option
Use combinations of basic, intermediate, and advanced to group your offerings
Add conditions at all levels
Other applications of Conditional Controls
You may use the skeleton to turn any tool to a No-Code interface. An extended simple application of conditional controls is search filters. Filters when broken down into a modular user friendly options help users search faster and better. Some good experiences can be seen in Notion table filter, Slack message search, Jira advanced search, Framer editing, etc.
Diving deep into the approach
You made it till this part? The writer in me feels accomplished! I’ll continue talking about the approach we took to design the conditional controls in the “Payment Page builder” or Studio product.
A brief history about the product, Studio
Juspay has an offering called Payment Page where Juspay builds end to end Payment experiences for merchants like Big Basket, Airtel, Swiggy, Zepto, Acko, etc. Naturally, each of these companies needs a Payment Page of their own with more or less similar customisations.
Never forget the fundamentals
Typically any Payment Page has the lifecycle: Design → Test → Release → Maintain. Now within Design, there are broadly two areas: Design (UI) and Control (Payments flows). We (Design, PM, Dev) used to audit the code, remove the redundancy and surface the Design customisations on the interface. We presumed that both new and repeat users will predominantly use Design more than Controls. Continued this for months, only to realise that our presumption was wrong.
In all these MVP releases and refactoring, we missed one of the most fundamental user requirement. Actually, missed is an understatement - since we were so deep into the refactor, we forgot talking to the users. Turned out users needed to control the payments options as much as they wanted to customise the designs. All of this irrespective of the type of user (new or repeat).
Users come with varying use cases in mind - they may want to test a design, or add some offer element, or some payment option, or just want to do a minor platform specific change. With this wide a spectrum of usage, weightage of any configuration cannot be determined just by the stage of user.
By the way
Isn’t it cool, designing for inception - Juspay is designing something so their users can use it to design something for their users. Tell me you get it?
Process
So, we sat with the code again. Brought the 300+ key-value pairs into an excel, understood the shit out of them. Started a documentation to record all this. We absolutely didn’t want to leave any Design Debt at all. Once we understood the key-value pairs, we tried to regroup and categorise them.
Categorisation went almost 5 levels deep so we can come up with a meaningful grouping and translate it to a usable UI. We also found certain conditions and JS expressions under the process. It was important to understand the weightage of every control to be figure out the information architecture - when is the conditional control even used? How frequently or infrequently? Can users use its full potential or do they need some guidance?
For every design iteration, we conducted critique sessions cross teams, not just with designers. We tried to have atleast 1 senior developer, 1-2 PMs, 2-3 developers in the same. This went on for about 3-4 months rigorously for us to reach a confident enough product design. Post a critique, we try to conduct short user testing sessions infrequently with the internal users on smaller parts of design; 2-4 screens at max, or one end to end flow. Testing anything more than 4 screens overwhelmed and blurred the feedback. We’ve handed off the dev specs and moved to the next part of product design. Here’s a glimpse of how we’re using Figma and Confluence as the mode of all official hand-offs, QA, and to record all iterations.
By the way
I am thankful to the team and process to help me upskill my approach towards any problem - however messy and chaotic things seem in the beginning, we’ll find a way around it. Sure, we’ll face dips on the way. Sure, it will be hard to bring everyone on the same page. But just a little bit patience and far-sightedness will help us get through. And lets accept it, heated arguments are fun! :p
Highlights for me as a designer
Having been a part of the product “Payment Page Builder” from Day 0 since 2020 as an intern, I’ve seen almost 2 lifecycles of this product. Highlights, to name a few:
Extensive Design Documentation to log daily updates, helping anyone understand the rational behind each design decision and approach. I wish we had started doing this sooner!
Design being used as an idea propagator and communicator. Design being used as the pivotal reference to refactor code. The in-sync communication of devs-designers-PMs helped us all be on the same page at all times.
Getting early feedback from users and getting more eyes on the product. You can’t be afraid of your approach or design getting cancelled. At times, listening to different perspectives can help you stay grounded and keep you out of the bubble!
Note of thanks
Thanks to Samit, Anirudh, Naman, Karun, Venky, and so many more people for being ever so involved and open in the Design process. This has been a really upskilling project (and continues to be one), and it wouldn’t have been possible without your support!
Drop me a feedback!
Have any queries or want to know more? Feel free to shoot a DM over Twitter or LinkedIn.
Conditional Controls