top of page
New requests & approval feature on mobile home
Smartsheet is a cloud-based project management tool. Users use Smartsheet's app to keep track of projects, and updates, automate processes and work on the go.
Main Contributions
Timeline
Team
+ UX Design Lead
+ Concept ideating
+ MVP design
Feb 2021 - Sept 2021
PM, dev partners (4), user researcher, content editor, UX (me)
Overview
The Smartsheet app has 2 million + downloads, and more than 424,000 + monthly active users. Approval and requests updates is a feature that allows anyone to request a sheet update to anyone shared to a sheet. Once an update is sent the requestee can respond to the request and the underlying sheet will be automatically updated.
My role on this project was to
-
Educate users on requests functionality in Smartsheet in order to increase the number of users sending and receiving requests
-
Lead UX design from ideation, prototyping, and delivering MVP assets
-
Spearhead collaboration efforts with dev, PM, and desktop partner teams to ensure all teams were aligned on goals and deliverables
Project timeline
The problem
-
82% of active users have never received a request
-
Of the users that received at least 1 request, 50% of the requests were never responded to
-
From talking to users we knew that users did not know of requests as a feature, and did not know where to go to send or respond to a request.
Update requests are an excellent way for users to maintain up-to-date data in a sheet. However, we saw very few users sending and receiving requests. The goal of this project was to increase the number of users using update requests. From looking at metrics and user feedback we knew that:
The opportunity
From findings provided by user research, we knew that one of the main reasons users were not using update requests is because of discoverability issues. Users simply did not know that update requests existed, and the current UI did not do a good job educating users about update requests. With this in mind, the team arrived at the following how might we statements:
Business opportunites
HMW educate users of requests as a feature?
HMW leverage homepage real-estate to surface update requests?
User opportunites
HMW show users that they have new requests, and allow them to respond?
HMW motivate users to start sending updating requests?
HMW increase requests usage from 18% to 35% of users sending or receiving at least 1 request?
HMW decrease number of pending requests that are pending for more than 2 weeks?
Low fidelity sketches
Now that the team is aligned on goals for this project I began concept ideation. Prior to designing in Figma, I hosted a brainstorming session with other designers in the organization. The brainstorming session was hosted on Miro because the team is working remotely. Below are some of my sketches from the session:
Concept 1 - Both received and sent requests are displayed in 1 screen. Users can drill in to see full-screen view.
Concept 3 - Without going into a sheet a user can directly make updates in a card.
Concept 2 - Each request is expandable. A user can see all the info they need without having to open a sheet.
Concept 4 - Requests live in the secondary navigation that exists today on home.
Early designs
At this point in the project, I started mocking up user flows in high fidelity. Once the flows were completed, I showed the proposed designs to the dev team. After getting feedback from the dev team I had a good idea of which features were costly, and what was cheaper or free to implement.
Free/cheap to implement
-
Swipe interactions for hiding requests
-
Showing meta data
-
Accordion-style sections for requests for you and requests from you
​
Costly to implement
-
Solo requests screen
-
Filtering for requests - will require API work from desktop
-
Dynamic view that changes per # of request user has
​
User Testing
Our research team helped us test concepts with 7 external participants. During test sessions, we asked testers to complete 3 tasks. From the test sessions we learned:
Simpler is not better
In testing, we were surprised to hear over and over again (71% of participants) ask for more information displayed with each request. We were surprised by this finding, but as it turns out users are okay with more information displayed such as date received, or underlying sheet displayed even if it means displaying a lot less requests on the screen.
"It's a bit cramped but I wouldn't change it. It's super helpful. I really like that (metadata)."
David
Prototype UI showed unrealistic # of requests
Nearly half of our testers pointed out that they almost never have any requests (which we should of known because we knew that 82% of users have never had a request) which meant concepts such as the version on the right would realistically only have 1 or 2 requests. Since most of our users have very few requests we moved away from a separated Requests page.
No one reads banners...and that's okay
Most participants either ignored, or immediately closed the blue banner that highlighted the new requests tab (57%), however, 100% of participants were able to locate requests! This led us to believe that a banner pointing to the new requests tab was a necessary evil. Users don't like it, but it gets the job done. It's a reliable pattern that can direct users to the new requests tab.
MVP Designs
Based on user feedback, dev limitations, and project budget we arrived at the following MVP designs. The plan is to launch and iterate as we go.
Quickly locate your requests
Users can quickly access their requests directly from the home screen. They can get all the information they need about a request without ever going into a sheet.
Dynamic error states
Depending on whether a user has ever received a request or not we show a different error state. If a user has never sent a request we provide educational information about requests.
Fully responsive
All designs are responsive for iOS and Android mobile and tablet devices. Designs will also support 9+ languages.
Measuring impact
1) 86% of test participants said they will visit the new requests tab based on new designs, of the testers 42% said they were not aware of requests functionality previously
2) 71% of testers indicated that they will more likely use requests per new design
3) 43% of testers indicated that if they received one request they are more likely to use requests in their workflow
3) Requests functionality is now accessible in 1 tap, instead of 5 taps currently
4) MVP design is fully accessible and meets WCAG 2.0 requirements
What I learned
1
2
In user testing it's important to test with realistic screens
The designer in me wants to show prototypes with designs that are perfectly laid out in testing sessions. In this project, I was reminded that an actual user's experience is almost never like what is mocked up. Sure the test designs might look great with a ton of requests, but the reality is that users will most likely only have 1 or 2 (to start with!).
Simpler is not always better
In most cases, the simplest solution is the best solution, but there are exceptions. Users use Smartsheet to get work done - in which case if something look's busy but offers a benefit users will glad to have a busier screen. When we iterate post MVP I'd like to investigate concepts to allow users to customize how much information they'd like to see.
bottom of page