Evergreen Data Permissions
Role
UI Designer
Date
Spring - Fall 2025
Timeline
30 weeks
Team
3 Des, 2 Devs, 2 Graphics, 1 PM
Evergreen is a $16 million mobile app project using passive sensor data and AI to provide proactive wellbeing support for Dartmouth students. It aims to catch mental health struggles before they become clinical.
THE CHALLENGE
To conceptualize and design the Evergreen app & onboarding.
This case study focuses on the data permissions aspect of onboarding.
I designed transparent data permission screens to clarify Evergreen's use of passive sensing data and build student trust
My Iterations
ROUND 1 ITERATIONS
Based on key insights from research
The partners liked the data-based organization the most (left). However, to satisfy the other insights from my research, I pulled in components of my other iterations and gave each data type its own page listing out the features it would be used for.
ROUND 2 ITERATIONS
With the ambiguity of the project, I wasn’t fully sure what these features would be, so I used these screens as a brainstorming hub where I could hold ideas for possible features based on the data types we had.
Scroll to read all my feature ideas
ROUND 3 ITERATIONS
We decided to create tiers of permissions to reduce the mental load of deciding which individual permissions to enable, and thus encouraging users to enable more. I designed an interactive sliding permissions meter with phone/battery imagery to convey the idea that the more permissions were enabled, the more "powered up" Evergreen would be.
Interactive permissions screen with tiers
ROUND 4 ITERATIONS
Changing to two tiers: During a team discussion, we worried that creating three tiers would lead users to default to the middle option. Thus, I changed the design to only incorporate two tiers and set the default to the high-permissions tier.
Language adjustments: I made subtle language changes to focus on how Evergreen supports users and develop trust.
Incorporating data pop ups: Following feedback from an external design mentor, I turned my data-focused screens into pop ups to bring more of my first designs' transparency into the new design.
Engaging and informative permissions screen
User Testing
We found that the majority of users preferred the simplest pop up (highlighted in blue). We also found the battery screen interaction was confusing for new users.
Scroll to see all data overlay iterations
ROUND 5 ITERATIONS
Discovering that the permissions screen was unintuitive to users was disappointing considering the past term of work I'd put into it. However, I overhauled the sliding battery visual and began iterating on new ways we could design an interactive, yet intuitive, permissions screen.
I wanted to emphasize the data types over the interactive battery component. So, I shrunk the battery to make it a visual indicator rather than the core interaction. Then I made each permission much larger and easier to toggle on/off.
Permissions screen iteration with more data focus
Having learned from the permissions slider, I ran user testing often, even on half-baked designs. This helped me get constructive feedback early.
Data cards still do not look clickable
When I gave my screens to a few users to test, 0% clicked on the data types to open the popup. Since the whole goal in shrinking the battery was to encourage opening these popups, this was an issue.
I turned to familiar design systems. I added the universal “i” button which was a clear indicator of more information. This made the design much simpler and in user testing, 100% of users selected the “i” button or stated that they knew where to click if they wanted to find more information.
Drop shadows look confusing
"i" clearly indicates more info
How to show which permissions are required
Removing the slider feature made it hard to show required permissions. I experimented with different ways to communicate which permissions were required, and grappled with transparency vs functionality. Ultimately in a conversation with partners, we decided to omit required permissions from this screen and simply have users approve the native permission alerts
Two ideas of how to communicate required permissions
How to encourage users to enable more permissions
My new designs lost the sliding designs' tiers to reduce the cognitive load of deciding which permissions to enable. I experimented with creating distinct tiers but instead opted to add enable all and disable all buttons for the same two-tier concept but with a simpler, more intuitive design.
Enable/Disable All
Tiers
I also designed a pop up that discouraged users from turning permissions off. I tested a more detailed design and a simpler design. 100% of users preferred the more detailed pop up.
100% of users preferred the more detailed pop up
The Final Design
The Evergreen Permissions Page
The final design is a clean, intuitive permissions screen that balances data transparency while encouraging users to enable more permissions.
I made minor visual changes in the final design switching from a battery visual to the Evergreen logo for a more cohesive look. I also further developed our style guide and changed the buttons to match our primary and secondary CTA colors.
CONCLUSIONS
I owned the design of the permissions screen over the course of three terms. Given the ambiguous nature of Evergreen, I learned how to evolve the design throughout the changing stages of the project.
Some lessons from this project
User testing
I learned first hand the importance of user testing early and often. Due to not testing a core feature of my permission screen (the slider), I was forced to pivot on a design I had spent 10 weeks developing.
Collaboration
Being on this project for 3 terms, I worked with 3 different teams. Additionally, Evergreen had 5+ regular partners and I actively sought new external mentors. This gave me tons of opinions to work with, which though difficult to consolidate at times, was crucial in designing a balanced final product.
Thanks for reading :)
Back to cases