top of page
Main Contributions
Deliverables
Team
Year
+ UX Design Lead
+ Concept ideating
+ User testing
+ Prototyping
+ New login experience for iOS/Android mobile and tablet devices
+ Responsive designs localized in 9 languages
1 PM, 4 dev partners, 2 QA, content editor, 1 UX researcher, UX (me)
Oct 2021 - Jan 2022
Overview
Smartsheet's mobile app has 2+ million downloads and 424,000+ monthly active users. I led design efforts on this project to de-risk mobile adoption on Smartsheet, and remove any barriers to entry. Around 10% of Smartsheet users use the mobile app today.
Project timeline
The problem
From talking to customers my team knew that there were usability issues with Smartsheet's current login experience. Problems with the current experience included
-
Users were unable to access Smartsheet due to login usability issues. For example, on failed login attempts we did not tell users why they failed.
-
There was a myriad of accessibility violations including color contrast not meeting WCAG 2.0 standards.
-
Visually mobile login was very different from desktop's login experience. Users said it felt like two different products.
-
Internal heuristics evaluation supported what users said and showed many usability violations. For example, key actions were not prioritized on screens.
On the left is a screenshot of the old login experience. The right is the updated designs.
Heuristics evaluation on existing login experience
In order to better understand areas of improvement, I completed an audit of the current experience. This audit was a tool used to further discuss goals and look at user metrics with my PM.
The opportunities
From our identified problems we arrived at our opportunity areas.
Business opportunities
User opportunities
How might we re-design mobile login's experience so that it is consistent with the rest of Smartsheet's product ecosystem?
How might we make it easier for users to login so that they can access their work faster?
How might we create an inclusive experience so that all users can use Smartsheet mobile?
Design process
Early concepts
Early wireframes include ideas for an improved set of welcome screens and login flow. This was shown to the larger UX org and dev squads for feedback.
Questions that I had at this point
-
Who owned the set of marketing illustrations? Can mobile make changes to this set of illustrations?
-
Did we need to loop in compliance if we're making flow level changes?
-
What privacy concerns do we have if we wanted to tell a user why their login attempt failed?
​
Trade offs due to dev limitation
-
If we wanted to place email and password inputs on one screen this will require twice as much time scoped for this project (yikes!)
-
Remember me capabilities will require months of work for iOS
Early wireframe ideas used for discussions with team
High fidelity designs
As I worked on high fidelity designs I had regular design check-ins with my PM to ensure that all use cases were covered. I also looped in the desktop design system team for any feedback and double checked with our accessibility specialist that all accessibility violations were addressed.
High fidelity screens after multiple rounds of iteration
User research
UX and research worked together to test concepts with 9 participants. We tested with internal Smartsheet employees ranging from UX designers, PMs, researchers, and devs we learned the following:
Illustrations make the login experience feel cramped
Testers pointed out that there's already limited space on a mobile device. They didn't appreciate any illustrations if it meant cluttering the screen.
On mobile users prefer to log in with third party options
Most testers (7/9 users) directly logged in with a third-party option. Data from BI supported this as well. This suggests that third-party login options should be prioritized on the screen.
Users don't like reading anything
Most users voiced that IF they were to view the welcome screen tiles they would only spend a couple seconds on each tile. This validated our hypothesis that users won't spend the extra time needed to go through all the existing information available.
If a user login's attempt failed they want to know why
Users voiced that it was very frustrating when their login failed but the system did not say why they failed.
Documentation & hand-off
Redlines in Figma
All designs are in Figma and our dev team has access to grab redlines directly from design files.
Accessibility documentation
In this update, we addressed accessibility violations and added new rules for ARIA voice-over logic.
Final designs
Beautiful and accessible
Final designs addressed numerous accessibility violations. All color contrast ratios in updated designs meet WCAG 2.0 standards, ARIA descriptions were added to images and tap targets were at least 44px by 44px.
Login without
mental gymnastics
Users can find their preferred login methods quickly and get work accomplished sooner. On failed login attempts we inform users of why their attempt failed.
Login designs are fully responsive for tablet in iOS and Android
Measuring success
Customer impact
-
Decreased average login time from 30 seconds to 17 seconds
-
Provided usable login experience for 240,000 + monthly active users
-
Brand new responsive states for 26,400 + tablet users
-
Shortened onboarding flow by 55% by eliminating repetitive screens
-
82% of users can see their preferred login method prioritized in the login flow
Business impact
-
Removed legal risks associated with enterprise software that did not meet WWCAG 2.0 standards
-
Launched a consistently branded user experience for mobile and
desktop login
​
​
What I learned
1
Show developers your designs frequently and early on in the design process
During the initial phases of design, there was time spent designing a login experience that included email and password fields on one screen. As it turns out because of technical limitations it was out of scope of create a login experience that included email and password. A lot of time could of been saved on design iterations had design talked to dev partners earlier in the process.
2
Understand when feedback is just a thought, a suggestion, or a mandate
When working on projects with cross-functional teams where many stakeholders are giving feedback it's key to understand when someone is just thinking aloud, giving a suggestion or giving a mandate. This can help prevent unnecessary design churn and help the team arrive at the best solution sooner.
bottom of page