Marqeta Onboarding – SSO Forms
Helping developers onboard to Marqeta to decrease time to value.
Over fall of 2022, I interned at Marqeta under the Developer Experience and Marqeta Dashboard teams. I redesigned onboarding for developers and business owners as part of a larger initiative to decrease time to value.
I also worked on another project on helping businesses streamline manual exchanges with self-service workflows – specifically on bulk-adding /users or /businesses. Please see the project here↗.
Timeline
Sep - Nov 2022
Team – Developer Experience
2 Designers
1 Software Engineer
1 Product Manager
2 Security
Tools
Figma
Jira
Disciplines
Visual Design
Interaction Design
Product Strategy
SUMMMARY
All SSO forms redesigned for better accessibility, visual hierarchy, and craft. A new redesigned password requirement component.
I worked on the onboarding process for developers to test Marqeta's APIs which included single sign-on, sign in, and more. From redesigning form structure, to content writing, and interaction accessibility, I developed this project with a holistic view in mind to strive towards an amazing experience.
Introduction
What is developer experience?
The Developer Experience (DX) team at Marqeta is a unique blend of software engineering and product design.
A seamless developer experience allows all developers to onboard and build on the Marqeta platform. It encompasses all the necessary tools, documentation, and APIs maintained by design, engineering, and product.
With 25 million active developers around the world, projected to grow to 45 million by 2030…
We have an amazing opportunity to help builders realize the potential of Marqeta’s powerful APIs.
The problem
The current customer sign-up journey is inconsistent with the sandbox visually, and lacks a sense of craft as Marqeta's onboarding experience.
Granular Design Problems
Outdated user interface design patterns
All form fields look old and aren’t updated to the newest Volt design system components.
Poor password requirement experience
The form field seemingly errors out immediately and appears as a 'popover' when the form is minimized.
Aggressive micro-interaction experiences
Customers are met with input fields that look like error states when they click out the input.
Information cut-off
Key information like the CTA is cut-off due to the form card height being too short for all the info.
Existing form design using old Volt Design System
Existing form design using old Volt Design System
Goal
Designing a best-in-class form experience
Marqeta’s customers who test the sandbox are primarily developers and business owners, and it’s pivotal to craft a positive first impression and build trust immediately upon onboarding.
Form redesign
Part of the larger initiative of improving onboarding.
Improve accessibility
Current form design does not meet WCAG standards.
Guided Setup
The flow would lead to a guided setup experience for the sandbox.
Process and reasons
SSO Form Audit
I did an audit of over 20+ enterprise and consumer product SSO forms, detailing everything from error states, password field components, and more. Making a password can sometimes take too long, and I wanted to craft an experience that isn’t aggressive and can be seamlessly done quickly. A great onboarding experience incentives customers to continue testing our product.
Best-in-class form examples audited
Password component Insights
Crafting a better password input
A seemingly simple component that turned out to have many parameters which heavily affect the experience. Below are some insights and design decisions I thought through to attempt to achieve a great experience.
Explicit or Implicit with Password Requirements?
Being explicit with the requirements provides clarity but can also take more effort to process. Being implicit allows for a simple interface and gives customers more flexibility but is also vaguer.
Ultimately, I prioritized clarity over simplicity – also given the constraints of time and potential ML/AI models needed for a password strength bar.
Safer Initial States
This new initial state is much less aggressive and is clearer to the customer that they need to meet the requirements listed. Research also shows that the length of the password matters more than the requirements listed.
Icon Selection
The initial icon chosen was both not accessible and had too much contrast not feeling like an initial state. I ended up going with a lighter shade and a 'x-mark' icon as it felt most opposite of a 'checkmark'.
Number of Requirements
In order to accommodate all the information within the fields, I combined various requirements and used a horizontal layout to reduce the password requirements’ overall height.
Visual Design
Visual Iterations
I experimented with different visual representations of the password requirement information presented above. Ultimately, I went with simplicity in the right option to reduce any visual distraction.
Accessibility
How can we design forms that are accessible to everyone?
For the experience to be seamless and easy, designing accessible forms with detailed interactions was key to allowing everyone to fill out forms quickly.
Designing Password Requirements
When creating your password, you’re likely focusing on the input field or what you’re typing to be accurate versus focusing on the requirements themselves. If you aren’t paying attention, you could miss the color change which indicated a requirement was met.
This problem is an even bigger problem for the colorblind who can’t tell changes in states by color alone. The password requirements needed an icon change to be more indicative of a change in state.
Designing Error States
When designing for error states, I had to balance a decision between extending the form height to accommodate the error state captions or indicating with just a color change. After testing the interactions, I decided that the extension of the form would be helpful for accessibility given that the animation of captions and form height extension would indicate a change in state.
Error State Microinteractions
To reduce the aggressiveness of error states while maintaining accessibility, I designed two separate indications for the password requirement error states for the form.
01
Error state indication after clicking out of input
A more subtle indication with an icon color change to show that the password doesn’t meet the requirements
02
Error state after submitting the form
An error caption and red-bordered input field are more obvious indications of an error – necessary when a customer is trying to understand what’s wrong with the information they submitted
Interactions
How can we design forms that feel easier to navigate?
For the experience to be seamless and feel fluid, designing accessible forms with great interactions was important. I experimented with various interactions for components that assist users with forms.
CTA Motion
To make the CTA animation more prominent between screens, I chose to mask the incoming text inwards while the previous CTA text masked outwards as a way to gesture entrance and exits.
Dynamically Revealing Inputs
Input is revealed gradually to reduce cognitive load on users as they navigate individual input fields. The form container expands smoothly to accomodate new inputs.
Design systems
Form details
Anatomy and consistency
Using the updated Volt design system, I created better consistency across all forms. I worked with our design systems manager to ensure components were accessible, along with guidelines for future forms.
Spacing guidelines
8px between labels, input fields, and input captions/error messages
8px between labels, input fields, and input captions/error messages
16px between all input fields
16px between all input fields
32px between headers/CTA’s with input fields
32px between headers/CTA’s with input fields
Mobile Compatibility
Brand Identity Iterations
Mobile Compatibility
Brand Identity Iterations
A white layout is a cleaner visual aesthetic, but it would be inconsistent with the desktop version. Having more information (slogans/logos) seemed unnecessary on a mobile layout, so they were removed in the final design.
A white layout is a cleaner visual aesthetic, but it would be inconsistent with the desktop version. Having more information (slogans) seemed unnecessary on a mobile layout, so they were removed in the final design.
Final Mobile Design
Final Mobile Design
Customers may want to sign up for Marqeta through a mobile device. Scaling this design down to mobile format meant showing only the important information which is the form itself.
Simple password requirement components for input
Each variant is specific to its use case and utilizes different content to help people create, reset, or change their passwords.
↓
A modern experience for card-issuing onboarding experience
With new form fields, an updated password strength requirement, and improved accessibility.
Public Sandbox Sign Up
A customer’s first interaction with Marqeta’s onboarding flow after making a decision to sign up.
Public Sandbox Sign In
Public sandbox refers to the demo version with more limited features that developers use to test the APIs.
Private Sandbox Sign In
Private sandbox refers to the full version with all features that developers use to test the APIs and start building card programs.
Forgot your password? No worries, reset it with ease.
The form is pinned to its top edge to prevent too much motion during animations between forms. It changes height fluidly from its bottom edge to accommodate the appropriate input fields.
DEVELOPER HAND OFF
Detailed design guidelines for front-end engineering
Below are some examples of the guidelines I created to ensure designs were thoroughly executed.
Learnings and impact
Product shipped
All new customers experience the work I did
It’s a huge privilege to get ownership of a project that so many people will see and experience as this is one of my first products I’ve shipped.
Do more of…
Talking to everyone, including those you don’t work with directly
This is applicable to both project work and connecting with others on a more personal level. I had so many questions throughout my project and had I not reached out to various people in other departments like security and engineering, I would’ve been left to make a lot of assumptions and not be able to back up design decisions.
Be meticulously and almost obsessively detail-oriented in your work
There’s a fine balance between what is detailed versus ‘overdoing it’, but this shows that you care and put in the effort to understand the problem. I consider this a strength of mine due to my architectural background and something that I will continue to carry throughout my design career.
Marqeta Onboarding – SSO Forms
Helping developers onboard to Marqeta to decrease time to value.
Over fall of 2022, I interned at Marqeta under the Developer Experience and Marqeta Dashboard teams. I redesigned onboarding for developers and business owners as part of a larger initiative to decrease time to value.
I also worked on another project on helping businesses streamline manual exchanges with self-service workflows – specifically on bulk-adding /users or /businesses. Please see the project here↗.
Timeline
Sep - Nov 2022
Team – Developer Experience
2 Designers
1 Software Engineer
1 Product Manager
2 Security
Tools
Figma
Jira
Disciplines
Visual Design
Interaction Design
Product Strategy
SUMMMARY
All SSO forms redesigned for better accessibility, visual hierarchy, and craft. A new redesigned password requirement component.
I worked on the onboarding process for developers to test Marqeta's APIs which included single sign-on, sign in, and more. From redesigning form structure, to content writing, and interaction accessibility, I developed this project with a holistic view in mind to strive towards an amazing experience.
Introduction
What is developer experience?
The Developer Experience (DX) team at Marqeta is a unique blend of software engineering and product design.
A seamless developer experience allows all developers to onboard and build on the Marqeta platform. It encompasses all the necessary tools, documentation, and APIs maintained by design, engineering, and product.
With 25 million active developers around the world, projected to grow to 45 million by 2030…
We have an amazing opportunity to help builders realize the potential of Marqeta’s powerful APIs.
The problem
The customer sign-up journey was inconsistent with the sandbox from a visual and experiential standpoint. It lacked a sense of craft as Marqeta's onboarding experience.
Granular Design Problems
Outdated user interface design patterns
All form fields look old and aren’t updated to the newest Volt design system components.
Poor password requirement experience
The form field seemingly errors out immediately and appears as a 'popover' when the form is minimized.
Aggressive micro-interaction experiences
Customers are met with input fields that look like error states when they click out the input.
Information cut-off
Key information like the CTA is cut-off due to the form card height being too short for all the info.
Existing form design using old Volt Design System
Process and reasons
Designing a best-in-class form experience
I did an audit of over 20+ enterprise and consumer product SSO forms, detailing everything from error states, password field components, and more. Making a password can sometimes take too long, and I wanted to craft an experience that isn’t aggressive and can be seamlessly done quickly. A great onboarding experience incentives customers to continue testing our product.
Best-in-class form examples audited
Password component DESIGN DECISIONS
Crafting a better password component
A seemingly simple component that turned out to have many parameters which heavily affect the experience. Below are some detailed decisions I thought through to attempt to achieve a great experience.
Explicit or Implicit with Password Requirements?
Being explicit with the requirements provides clarity but can also take more effort to process. Being implicit allows for a simple interface and gives customers more flexibility but is also vaguer.
Ultimately, I prioritized clarity over simplicity – also given the constraints of time and potential ML/AI models needed for a password strength bar.
Safer Initial States
This new initial state is much less aggressive and is clearer to the customer that they need to meet the requirements listed. Research also shows that the length of the password matters more than the requirements listed.
Icon Selection
The initial icon chosen was both not accessible and had too much contrast not feeling like an initial state. I ended up going with a lighter shade and a 'x-mark' icon as it felt most opposite of a 'checkmark'.
Number of Requirements
In order to accommodate all the information within the fields, I combined various requirements and used a horizontal layout to reduce the password requirements’ overall height.
Visual Design
Visual Iterations
I experimented with different visual representations of the password requirement information presented above. Ultimately, I went with simplicity in the right option to reduce any visual distraction.
Accessibility
How can we design forms that are more accessible to everyone?
For the experience to be seamless and easy, designing accessible forms with detailed interactions was key to allowing everyone to fill out forms quickly.
Designing Password Requirements
When creating your password, you’re likely focusing on the input field or what you’re typing to be accurate versus focusing on the requirements themselves. If you aren’t paying attention, you could easily miss the color change which indicated a requirement was met.
This problem is an even bigger problem for the colorblind who can’t tell changes in states by color alone. The password requirements needed an icon change to be more indicative of a change in state.
Designing Error States
When designing for error states, I had to balance a decision between extending the form height to accommodate the error state captions or indicating with just a color change. After testing the interactions, I decided that the extension of the form would be helpful for accessibility given that the animation of captions and form height extension would indicate a change in state.
Error State Microinteractions
To reduce the aggressiveness of error states while still maintaining accessibility, I designed two separate indications for the password requirement error states for two parts of the flow.
01
Error state indication after clicking out of input field
A more subtle indication with an icon color change to show that the password doesn’t meet the requirements
02
Error state after submitting the form
An error caption and red-bordered input field are more obvious indications of an error – necessary when a customer is trying to understand what’s wrong with the information they submitted
Interactions
How can we design forms that feel easier to navigate and transition?
For the experience to be seamless and feel fluid, designing accessible forms with detailed interactions was important. I experimented with various interactive motions for components that assist users with forms.
CTA Motion
To make the CTA animation more prominent between screens, I chose to mask the incoming text inwards while the previous CTA text masked outwards as a way to gesture entrance and exits.
Dynamically Revealing Inputs
Input is revealed gradually to reduce cognitive load on users as they navigate individual input fields. The form container expands smoothly to accomodate new inputs.
Design systems
Form details
Anatomy and consistency
Using the updated Volt design system, I created better consistency across all forms. I worked with our design systems manager to ensure components and interactions were accessible, along with guidelines for future forms.
Spacing guidelines
8px between labels, input fields, and input captions/error messages
16px between all input fields
32px between headers/CTA’s with input fields
Final Mobile Design
Customers may want to sign up for Marqeta through a mobile device. Scaling this design down to mobile format meant showing only the important information which is the form itself.
Mobile Compatibility
Brand Identity Iterations
A white layout is a cleaner visual aesthetic, but it would be inconsistent with the desktop version and other form pages. Having more information (slogans, logos) besides the form seemed unnecessary on a mobile layout, so they were removed in the final design.
Simple password requirement components for input
Each variant is specific to its use case and utilizes different content to help people create, reset, or change their passwords.
↓
A modern experience for card-issuing onboarding experience
With new form fields, an updated password strength requirement, and improved accessibility.
Public Sandbox Sign Up
A customer’s first interaction with Marqeta’s onboarding flow after making a decision to sign up.
Public Sandbox Sign In
Public sandbox refers to the demo version of the sandbox with more limited features that developers use to test the APIs.
Private Sandbox Sign In
Private sandbox refers to the full version of the sandbox with all features that developers use to test the APIs and start building card programs.
Forgot your password? No worries, reset it with ease.
The form is pinned to its top edge to prevent too much motion during animations between forms. It changes height fluidly from its bottom edge to accommodate the appropriate input fields.
DEVELOPER HAND OFF
Detailed design guidelines for front-end engineering
Below are some examples of the guidelines I created to ensure designs were thoroughly executed according to exact details.
Learnings and impact
Product shipped
All new customers experience the work I did
It’s a huge privilege to get ownership of a project that so many people will see and experience as this is one of my first products I’ve shipped.
Do more of…
Talking to everyone, including those you don’t work with directly
This is applicable to both project work and connecting with others on a more personal level. I had so many questions throughout my project and had I not reached out to various people in other departments like security and engineering, I would’ve been left to make a lot of assumptions and not be able to back up design decisions.
Be meticulously and almost obsessively detail-oriented in your work
There’s a fine balance between what is detailed versus ‘overdoing it’, but this shows that you care and put in the effort to understand the problem. I consider this a strength of mine due to my architectural background and something that I will continue to carry throughout my design career.
Goal
Designing a best-in-class form experience
Marqeta’s customers who test the sandbox are primarily developers and business owners, and it’s pivotal to craft a positive first impression and build trust immediately upon onboarding.
Form redesign
Part of the larger initiative of improving onboarding.
Improve accessibility
Current form design does not meet WCAG standards.
Guided Setup
The flow would lead to a guided setup experience for the sandbox.
Marqeta Onboarding – SSO Forms
Helping developers onboard to Marqeta to decrease time to value.
Over fall of 2022, I interned at Marqeta under the Developer Experience and Marqeta Dashboard teams. I redesigned onboarding for developers and business owners as part of a larger initiative to decrease time to value.
I also worked on another project on helping businesses streamline manual exchanges with self-service workflows – specifically on bulk-adding /users or /businesses. Please see the project here↗.
Timeline
Sep - Nov 2022
Team – Developer Experience
2 Designers
1 Software Engineer
1 Product Manager
2 Security
Tools
Figma
Jira
Disciplines
Visual Design
Interaction Design
Product Strategy
SUMMMARY
All SSO forms redesigned for better accessibility, visual hierarchy, and craft. A new redesigned password requirement component.
I worked on the onboarding process for developers to test Marqeta's APIs which included single sign-on, sign in, and more. From redesigning form structure, to content writing, and interaction accessibility, I developed this project with a holistic view in mind to strive towards an amazing experience.
Introduction
What is developer experience?
The Developer Experience (DX) team at Marqeta is a unique blend of software engineering and product design.
A seamless developer experience allows all developers to onboard and build on the Marqeta platform. It encompasses all the necessary tools, documentation, and APIs maintained by design, engineering, and product.
With 25 million active developers around the world, projected to grow to 45 million by 2030…
We have an amazing opportunity to help builders realize the potential of Marqeta’s powerful APIs.
The problem
The customer sign-up journey was inconsistent with the sandbox from a visual and experiential standpoint. It lacked a sense of craft as Marqeta's onboarding experience.
Granular Design Problems
Outdated user interface design patterns
All form fields look old and aren’t updated to the newest Volt design system components.
Poor password requirement experience
The form field seemingly errors out immediately and appears as a 'popover' when the form is minimized.
Aggressive micro-interaction experiences
Customers are met with input fields that look like error states when they click out the input.
Information cut-off
Key information like the CTA is cut-off due to the form card height being too short for all the info.
Existing form design using old Volt Design System
Process and reasons
Designing a best-in-class form experience
I did an audit of over 20+ enterprise and consumer product SSO forms, detailing everything from error states, password field components, and more. Making a password can sometimes take too long, and I wanted to craft an experience that isn’t aggressive and can be seamlessly done quickly. A great onboarding experience incentives customers to continue testing our product.
Best-in-class form examples audited
Password component DESIGN DECISIONS
Crafting a better password component
A seemingly simple component that turned out to have many parameters which heavily affect the experience. Below are some detailed decisions I thought through to attempt to achieve a great experience.
Explicit or Implicit with Password Requirements?
Being explicit with the requirements provides clarity but can also take more effort to process. Being implicit allows for a simple interface and gives customers more flexibility but is also vaguer.
Ultimately, I prioritized clarity over simplicity – also given the constraints of time and potential ML/AI models needed for a password strength bar.
Safer Initial States
This new initial state is much less aggressive and is clearer to the customer that they need to meet the requirements listed. Research also shows that the length of the password matters more than the requirements listed.
Icon Selection
The initial icon chosen was both not accessible and had too much contrast not feeling like an initial state. I ended up going with a lighter shade and a 'x-mark' icon as it felt most opposite of a 'checkmark'.
Number of Requirements
In order to accommodate all the information within the fields, I combined various requirements and used a horizontal layout to reduce the password requirements’ overall height.
Visual Design
Visual Iterations
I experimented with different visual representations of the password requirement information presented above. Ultimately, I went with simplicity in the right option to reduce any visual distraction.
Accessibility
How can we design forms that are more accessible to everyone?
For the experience to be seamless and easy, designing accessible forms with detailed interactions was key to allowing everyone to fill out forms quickly.
Designing Password Requirements
When creating your password, you’re likely focusing on the input field or what you’re typing to be accurate versus focusing on the requirements themselves. If you aren’t paying attention, you could easily miss the color change which indicated a requirement was met.
This problem is an even bigger problem for the colorblind who can’t tell changes in states by color alone. The password requirements needed an icon change to be more indicative of a change in state.
Designing Error States
When designing for error states, I had to balance a decision between extending the form height to accommodate the error state captions or indicating with just a color change. After testing the interactions, I decided that the extension of the form would be helpful for accessibility given that the animation of captions and form height extension would indicate a change in state.
Error State Microinteractions
To reduce the aggressiveness of error states while still maintaining accessibility, I designed two separate indications for the password requirement error states for two parts of the flow.
01
Error state indication after clicking out of input field
A more subtle indication with an icon color change to show that the password doesn’t meet the requirements
02
Error state after submitting the form
An error caption and red-bordered input field are more obvious indications of an error – necessary when a customer is trying to understand what’s wrong with the information they submitted
Interactions
How can we design forms that feel easier to navigate and transition?
For the experience to be seamless and feel fluid, designing accessible forms with detailed interactions was important. I experimented with various interactive motions for components that assist users with forms.
CTA Motion
To make the CTA animation more prominent between screens, I chose to mask the incoming text inwards while the previous CTA text masked outwards as a way to gesture entrance and exits.
Dynamically Revealing Inputs
Input is revealed gradually to reduce cognitive load on users as they navigate individual input fields. The form container expands smoothly to accomodate new inputs.
Design systems
Form details
Anatomy and consistency
Using the updated Volt design system, I created better consistency across all forms. I worked with our design systems manager to ensure components and interactions were accessible, along with guidelines for future forms.
Spacing guidelines
8px between labels, input fields, and input captions/error messages
16px between all input fields
32px between headers/CTA’s with input fields
Final Mobile Design
Customers may want to sign up for Marqeta through a mobile device. Scaling this design down to mobile format meant showing only the important information which is the form itself.
Mobile Compatibility
Brand Identity Iterations
A white layout is a cleaner visual aesthetic, but it would be inconsistent with the desktop version and other form pages. Having more information (slogans, logos) besides the form seemed unnecessary on a mobile layout, so they were removed in the final design.
Simple password requirement components for input
Each variant is specific to its use case and utilizes different content to help people create, reset, or change their passwords.
↓
A modern experience for card-issuing onboarding experience
With new form fields, an updated password strength requirement, and improved accessibility.
Public Sandbox Sign Up
A customer’s first interaction with Marqeta’s onboarding flow after making a decision to sign up.
Public Sandbox Sign In
Public sandbox refers to the demo version of the sandbox with more limited features that developers use to test the APIs.
Private Sandbox Sign In
Private sandbox refers to the full version of the sandbox with all features that developers use to test the APIs and start building card programs.
Forgot your password? No worries, reset it with ease.
The form is pinned to its top edge to prevent too much motion during animations between forms. It changes height fluidly from its bottom edge to accommodate the appropriate input fields.
DEVELOPER HAND OFF
Detailed design guidelines for front-end engineering
Below are some examples of the guidelines I created to ensure designs were thoroughly executed according to exact details.
Learnings and impact
Product shipped
All new customers experience the work I did
It’s a huge privilege to get ownership of a project that so many people will see and experience as this is one of my first products I’ve shipped.
Do more of…
Talking to everyone, including those you don’t work with directly
This is applicable to both project work and connecting with others on a more personal level. I had so many questions throughout my project and had I not reached out to various people in other departments like security and engineering, I would’ve been left to make a lot of assumptions and not be able to back up design decisions.
Be meticulously and almost obsessively detail-oriented in your work
There’s a fine balance between what is detailed versus ‘overdoing it’, but this shows that you care and put in the effort to understand the problem. I consider this a strength of mine due to my architectural background and something that I will continue to carry throughout my design career.
Goal
Designing a best-in-class form experience
Marqeta’s customers who test the sandbox are primarily developers and business owners, and it’s pivotal to craft a positive first impression and build trust immediately upon onboarding.
Form redesign
Part of the larger initiative of improving onboarding.
Improve accessibility
Current form design does not meet WCAG standards.
Guided Setup
The flow would lead to a guided setup experience for the sandbox.