echoes
Awareness App to Mitigate Environmental Grief
Duration
3 months
source
Master's Project
Role
UX/UI desıgner
tools
Fıgma
team
svetlana chırkova
rıtu chowdhury
adrıta ghosh
elısa hıpolıto
keywords
Design Brief
The project started as a studio brief:
"Mitigating the impact of Environmental Grief on society. Design a concept for hope and mourning in the Anthropocene. Exercise it as a solution in the field of physical wellbeing and mental health."
It gave us an emotional territory and a field, but the task of defining a problem, a user, and a medium was ours. So the first half of the project went into discovering our direction before anything got designed.
Solution
We created a platform called echoes for people who are anxious or suffering from environmental grief, but don't have the time or don't know where to start their eco-journey. Its main function is to integrate ecological habits into everyday life by encouraging individual eco-activism through gamification and storytelling.
Process
Echoes was a team project with five of us. In the early stages, we worked all together on research, discovery, and synthesis to turn a broad brief into a defined problem and a chosen direction.
When our direction was clear, I was responsible for the overall product design, including the information architecture, the user flow, the wireframes, the component library, the high-fidelity screens, and the clickable prototype in Figma.
Research
We started with a semantic analysis of the brief, investigating each keyword and defining it properly. From there we looked at the history of the subject, how different cultures have approached it, and how artists and designers have responded to it from the eighteenth century to today. Alongside that we researched mental health and how it connects to climate change and environmental grief.
Semantic Analysis
History of Environmental Grief
Milestones in Art & Design
Cultural Approaches
Once the user scenario and leverage points were identified, the product’s initial information architecture and wireframes began to take shape.
Design Decision: During this discovery phase, the product evolved into an interactive platform rather than a form designed to collect patient information. By that, it also avoided Europe's complicated data privacy rules.
Interface Design
As the product’s core structure took its final form, a high-quality prototype also began to take shape, starting with the product’s visual hierarchy, component library, and color palette.
Building MVP
I worked with an ophthalmologist to build the recommendation tree that generates unique suggestions for each patient's condition. With that and the detailed screens were in place, I used Builder.io and Claude Code to build a working MVP that matched my design, ran the recommendation logic, and pulled condition and test data from Supabase.
Fınal product
Cover
The Cover screen is what users see while the tablet sits idle. There, they can swipe it up to start interacting. I designed this screen to be more approachable, like a magazine cover.
Conditions
The Conditions screen is where users input data. However, as part of the frictionless interaction logic I defined during the process, I kept it as far from a form as possible.
The product asks users only to select their conditions from cards supported by images, in order to get a tailored set of recommendations.
Recommendations
The Recommendations screen is where the product performs its actual function. Based on the selected conditions, the recommendation tree returns tests that are relevant to that patient and available at that practice.
Patients get information such as why each test is recommended, how often it should be done, and what it costs, so they can take their time and reach an informed decision.
Checkout
The Checkout screen is straightforward. Users select the tests they are interested in and see a summary of their choices. This way, staff receive a clear request rather than having to start the conversation from scratch.
Branding
Reflection
The core characteristic of this B2B project was designing for a client who would never directly use the product. There were three stakeholders: the clinic, the patients, and the medical assistants. They each brought their own requirements into the service.
That split created its own set of rules. To the patient, I was responsible for providing clear information without pressuring them into a decision about their own health. To the clinic owner, I owed a product that genuinely helps them to give better care for their patients, make more revenue, and decrease workload for their staff.
The user journey analysis was what gave me the leverage point. It let me define an interaction logic that focuses on informing patients rather than selling to them or collecting their data. Visually, I stayed deliberately plain. Given the target user group and where the product sits, the interface needed to feel simple, reliable and familiar.