Hello, Customer
Designing a basic app feature end-to-end
with cross-team support
Project Overview
Situation
In starting from scratch with a new app, the team needed to decide on a method for creating accounts and managing returning user sign in that felt contemporary, leveraged the latest technologies and was as customer-friendly as possible.
Task
Devise a frictionless login process for new customers while also adopting the latest trends in multi-factor authentication.
Action
Conduct a small research project to investigate the available options and present the pros and cons to the cross functional team
Derive a feature IA that can be used to guide UX design and set the stage for app and cloud development
Create a detailed wireframe prototype to guide app implementation
Begin populating a virgin design system with new UI elements
Result
A surprisingly smooth review process with consent from all teams and the first demonstrable feature in the new app
Tools
Invision Freehand
Figma
Time
~1 Month
My Role
Solo Designer
Guiding Principles
Account creation and login could be a mundane element but it’s usually the customer’s first interaction with a brand. Since this is a new company and I would also be tasked with building the brand from scratch, this process needed to set the tone for future interactions.
With every new feature, I attempt to identify up to three guiding principles that help align everyone’s decision making. These principles are usually borne out of past frustrations with a similar feature or represent an ideal towards which to strive. I’ve reproduced the three principles below.
1️⃣
Frictionless Login
Login is a frictionless as possible, doesn’t require the use of passwords and leverages industry-standard multi-factor authentication.
2️⃣
Keep Me Logged In
The login sessions are persistent until the session needs to be terminated either by the user or for some perceived security reason.
3️⃣
Happy Path
Login is optimized for a happy-path workflow while maintaining recovery options for corner case scenarios.
Part 1: Comparison Research
How do we handle the three pieces of account creation, multi-step or multi-factor authentication and returning user login while keeping the experience short and customer friendly?
I conducted a simple research project to help ensure everyone was aware of the most common off-the-shelf options and presented my findings in a cross-team review to begin building buy-in to our eventual solution. Below is a reconstructed sample of the content that I presented to the team for consideration.
Traditional
Utilize a login handle, password and additional separate 2FA setup
3rd Party
Rely on authentication from Apple, Google, Facebook, Amazon, etc. to handle all user authentication
Passwordless
Adopt a modern password less login like the kind used with Slack or Eero
Examining a very trendy, contemporary app, Robinhood just uses a traditional email and password sign-in process. This is complimented by an integrated second factor challenge.
This example, from eBay, uses both a first-party sign in as well as partner sign ins. Solutions like this allow for customer choice - they can pick from four different options - but adds complexity to the interface and requires additional development effort.
Looking at the Square Cash app, there is no distinction between sign-in and account creation. The system doesn’t require the user to select an authentication method.
Robinhood
Traditional onboarding with discrete account creation, 2FA setup and login process
Square Cash
More modern account creation and login workflow that blurs the lines between the two and requires mandatory one-time-passwords for login. Routes all logins through SMS OTP unless an email address is added to the account.
Eero
Similar to Square Cash but offers both Phone and Email login options to account setup. Defaults to email.
Slack
Similar to an email-only version of Square/Eero but adds Sign-in with Google. Somewhat unusual as a partial account setup may be done by a team admin.
Benefits
✅ Comfortable for users as they’ve done this a million times
✅ Well-established process
✅ Consolidated workflows eliminates many screens
✅ Multi-step login is required
✅ No user-provided passwords to reset or manage
✅ As few as three screens for account creation
✅ Consolidated workflows eliminates many screens
✅ Multi-step login is required
✅ No user-provided passwords to reset or manage
✅ As few as three screens for account creation
✅ Offers both email and SMS validation options from the start
✅ Consolidated workflows eliminates many screens
✅ Multi-step login is required
✅ No user-provided passwords to reset or manage
✅ As few as three screens for account creation
Risks
⛔️ Requires discrete workflows for onboarding, 2FA setup and returning user login
⛔️ Largest, most complex workflow possible
⛔️ Users can forget their passwords
⛔️ Users can use weak or often-used passwords
⛔️ Users don’t have to setup 2FA
⛔️ Requires password reset infrastructure
⛔️ Potentially “foreign” workflow for users
⛔️ Requires some kind of account recovery mechanism
⛔️ Defaulting to SMS OTP is expensive
⛔️ Potential “multiple account” complications due to the sign-in process with less experienced users
⛔️ No clear benefit or way to implement Sing-in with Apple/Google/Amazon/FB, etc.
⛔️ Potentially “foreign” workflow for users
⛔️ Requires some kind of account recovery mechanism
⛔️ Potential “multiple account” complications to due the sign-in process with less experienced users
⛔️ No clear benefit or way to implement Sign-in with Apple/Google/Amazon/FB, etc.
⛔️ Potentially “foreign” workflow for users
⛔️ Requires some kind of account recovery mechanism
⛔️ Presenting multiple login methods can be confusing to less sophisticated users
⛔️ Google sign-in makes the process much longer
Considerations and Proposal
I extracted the best parts of the reviewed workflows and distilled them into two high-level IA diagrams for the team to consume.
Happy Path IA Draft
A happy-path diagram allowed our leadership stakeholders to grasp on to the every-day-user scenarios and feel confident that new customers would have a smooth onboarding.
Account Creation and Login IA Draft
The slightly more in-depth diagram was intended to help the engineering stakeholders scout for unexpected corner cases and begin to imagine implementation.
Cross Functional Review Discussion Topics
As part of selecting a method to move forward, I compiled a list of questions for which I needed team consent to make the best decisions possible. Representatives from firmware, app, cloud, QA, program management and the executive team were all present to voice their thoughts.
My main goal was ensuring that all teams were content with the decisions moving forward as I wanted to minimize rework for anyone so early in the game. The questions are reproduced below but I have omitted the answers.
Can we go with a passwordless login option?
Do we need to collect the user’s email address at account creation?
Do we need to collect the user’s phone number at account creation?
Do we need to collect personally identifiable information at account creation? If so, why and what will it be used for?
First and last name? Physical Address? Birthday?
Can we use the Cash App-style PP/TOS consent without extra confirmation? If not, why?
Do we need to collect the country for legal and GDPR compliance reasons?
Does passwordless login have complications with potential hardware devices/firmware interaction?
Do we want to support Login with Apple/Google/Amazon/FB?
After our discussion, I had everything I needed to move forward on a full draft of the Account Creation and Login IA. An additional review session was conducted to discuss the differences between an OTP and a Magic Link. The format of this review followed the same as above but was more targeted given the narrower scope of the deliberation.
Part 2: Finalizing the IA
I always conduct IA reviews with the stakeholder team as I’ve found it the easiest way to gain consensus and represents relatively low-level effort for building a feature. Depending on the complexity of the feature, a single cross functional team review may be sufficient. More complex features usually result in two or three sessions to address all of the concerns.
The IA for this particular feature went through a single major revision and review followed by seven minor updates as the team began implementing the workflow and it was built out into a full UX prototype.
Leveraging Freehand
As we began our company journey shortly after the start of the pandemic, our team was not only remote but scattered across the west coast of the United States. As a result, I decided to adopt Invision Freehand to conduct our whiteboard sessions.
I always send out a link to the well in advance of the meeting so that everyone can familiarize themselves with the workflow.
My general process in a review is to narrate the customer’s happy path journey as we go through the IA. If the feature is particularly complex, I might even extract the happy path IA for review before I take the team through a complete workflow with all of the integrated corner cases.
This feature began life as a complete IA diagram, partially reproduced below.
Simple Color Coding
I have found that the team doesn’t particularly care if I utilize diamonds for decisions, circles for popups or any other shape-based trope. So instead, I use simple rectangles for all elements and a very simple color coding method to denote higher-level decision tree elements of the IA.
Normal Elements
Basic elements of the workflow are black. These could be represented in the app as screens, modals, actions sheets or anything in between.
Simple Logic
Any kind of branching point with an external input, like if a token is valid or a device is offline, is orange.
Happy Path
Logic decisions that take the user towards the happy path are always green. Any kind of corner case or error is always red.
Go To
Whenever the workflow needs to do more than a simple 2D chart can manage, a blue Go To block directs the reader to the screen or IA necessary to complete the workflow.
Collecting Feedback
Just like we were in a conference room together reviewing on a white board, I find using sticky notes is an efficient and concise way to capture the team’s feedback.
Sticky notes are added in the general location of the comment and I try to use a color coding system to denote unresolved from resolved issues. Small issues with the IA may be dealt with during the meeting itself.
Initial IA
Prior to team feedback, this was the initial IA that I presented following our research discussions. I knew it was incomplete but would be sufficient for us to begin a feature deep dive. Simpler starting IAs are also often easier for everyone to digest.
Final IA
After two full-team reviews and several small side conversations, the scale of the IA increased but also accounted for all of the possible error cases.
Serializing the IA
Once I am reasonably certain that no additional major changes will take place with the IA, I “serialize” each element for mapping to the UX prototype.
I have used several different numbering systems but my current methodology follows a spreadsheet with vertical and horizontal identification information. It’s not meant to be sophisticated, just sufficient so that the team can correlate a particular screen across IA, UX and UI.
I have reproduced an excerpt of the IA document with the serialized information added.
Part 3: Building the Prototype
I always conduct IA reviews with the stakeholder team as I’ve found it the easiest way to gain consensus and represents relatively low-level effort for building a feature. Depending on the complexity of the feature, a single cross functional team review may be sufficient. More complex features usually result in two or three sessions to address all of the concerns.
The IA for this particular feature went through a single major revision and review followed by seven minor updates as the team began implementing the workflow and it was built out into a full UX prototype.
Jumpstarting a Design System
Because so much effort has already been front-loaded with a well vetted IA, creating wireframes and a click-through prototype becomes a bit paint-by-number.
Both before and while creating the actual screen wireframes, I work to build the design system that will eventually house all of the final visual components. I have found that starting the design system with wire-frame components helps with consistency in the wire-framing process and also makes it easier to transition to final visuals later on.
Text Styles
Text styles and basic buttons are the first to be drafted. While there might end up being more styles in the long run, this set covers most of what is needed to build the basic app framework.
Buttons
The buttons, while primitive, account for all of the expected states that will be needed in the app.
Navigation Widgets
Navigation widgets are also needed on the first few screens so a simple back and cancel are added to the library with their accompanying button states.
Action Sheets
While I could leverage the OS-native components on iOS, there is a sufficient difference between iOS and Android that I prefer these to be custom components to present a common interface on both platforms.
This helps with customer legibility as well as our documentation and tech support efforts as only one interface needs to be described.
Form Fields
Of the basic components, form fields receive the most attention at the wireframe stage because interacting with them, while mundane, is rather critical to entering account information for a new user. I’ve also seen very poorly crafted form fields that immediately chastise a customer for “incomplete passwords” before they have had a chance to complete their entry, so there is an accompanying set of validation rules that are tested at this point.
OTP Fields
OPT fields are an extension of the basic form field with a much more rigid structure to account for the expected entry. Discrete fields are used to imply the number of digits that need to be entered with auto-advancing between the fields.
Click-Through UX Prototype
With the basic components created, the wireframe can be rather quickly assembled following the outline created with the IA.
To keep things simple, I usually start with a basic iPhone X-sized art board and follow the IA through the happy path. Once this workflow is fully assembled, I can go back through and add in all of the corner and error cases.
Once the full workflow has been built in Figma, I host a cross-team design review to confirm that the prototype matches everyone’s expectations from the IA.
Seeing the prototype usually sparks discussions about potential app and cloud requirements that weren’t obvious from the IA. All feedback is collected and incorporated into an updated prototype. If changes are minor, an offline review. If the changes are major, I’ll conduct a second cross-team review before moving onto visuals.
Customer Facing Screens
The majority of customer-facing screens propose a basic layout without final spacing or layout constraints.
An orange bar across the top of the art board highlights the screen’s wire-frame nature and also includes a reference to the screen ID that links back to the IA.
Error States
I’ve found it best to include as much detail as possible even in the early wire frames as something a minor as an error message could wreak havoc with a design later on if not properly accounted for early on.
This also gives me an opportunity to test out copy with the team. We check for intelligibility, personality and potential localization issues. If everyone is happy with the copy, it gets added to our string management tool.
Branching Logic
Full-screen orange modals are used in the prototype to account for all of the branches in the user flow or to include external IoT device events. Utilizing screens like this allows me to create a single prototype that mirrors the IA without needing discrete prototypes for each workflow, especially when considering negative cases.
Complete Feature UX
While the happy path only includes four customer-facing screens, the completed prototype includes all of the state transitions and negative flows as well. I’ve had the fortune of working multiple times with a very detail-oriented QA lead and her focus on the corner cases has ensured my work is always optimized for the happy path but inclusive of all possible errors.
Rather than deliver a frozen PDF with immutable click paths and notes, I prefer to utilize a live Figma prototype as the UX source of truth. I’ve worked with PDF UX workflow handoffs and they are time consuming to create, tedious to update and can’t convey the interactive elements of an interface.
While the workflow is displayed above as a flat array of screens, all stakeholders principally interact with the Figma prototype. Comments are tracked using Figma and updates are pushed with a Slack channel integration. Implementation effort is tracked in JIRA with direct links to the screen in the Figma prototype ensuring there is only one source of truth.
Part 4: Completing the Visuals
If everything has gone according to plan, at this point, the visual effort is usually rather rote, especially if things are leveraging the existing design system.
While conveying the actual look of the screen is the general goal of this stage in my design effort, I feel that one of the most important things to convey to the app team is how components are built and intended to scale. To that end, I provide multiple examples of screen size layouts and resizing behavior so that the Figma component can be properly translated into the iOS and Android visual SDKs being built by the team.
Expanding the Design System
At this stage, I need to take the wireframe elements from the design system and expand the variants to include light and dark mode elements. The final sizes of items are also decided and checked against reference devices to ensure legibility.
Each of the six component types referenced above are expanded to include light and dark mode components. This is the first time that the brand colors and typeface are deployed in the app components.
Resizing, Localization and Accessibility
Each component also gets a special resizing art board that explains how it is supposed to resize in a variety of circumstances. Narrow and wide screens help show wrapping while German and Japanese are used to show how the component should work when localized. Additionally, a version is created with the text enlarged by 150% to show accessibility resizing.
Technically, all of the resizing behavior should be properly embedded in the component. The resizing art boards serve more as a confirmation to ensure that the implemented component behaves as expected and that nothing has been omitted during the component design.
Building the UI
With completed components, the next step is to try them in an actual layout. I try to design everything in both light and dark mode simultaneously to minimize the amount of variances needed in each.
On-Device Validation
To check on-device legibility, I use four different hardware devices, two iOS, two Android, one each mobile and tablet. While this by no means represents all of the possible screen sizes available, it is at least a sanity check to ensure that something looks as good on a device as it does on screen, especially when it comes to text sizes.
Full Layout Spectrum
If everything looks good on the test devices, I’ll expand the screen layouts to include legacy devices and additional screen orientations. The completed art board serves as the visual reference for the app team and accounts for a broad range of devices.
Narrow screen devices like iPhone 5
Devices with home buttons like iPhone SE
Full screen iOS devices like iPhone X
Legacy Android devices without gesture control
Modern Android devices with gensture control like the Pixel 4a
Full screen iOS tablets like iPad Pro
Android tablets like the Lenovo tab
Final Happy Path UI
While the full onboarding workflow contains about 18 customer-facing screens, the vast majority of customers will only ever see these three.
There’s no customer-facing difference between the new and returning user experience
There are no passwords for customers to forget or be breached
There are only three screens that a customer needs to engage with to create an account
The widgets created for this feature form the foundation of an app-wide design system
Leveraging cross-team collaboration at the IA stage ensured a smooth transition from concept to implementation that only required revision because of missing elements, not because of team dissent
