Where the designstarts to shine
Designing a member portal web app experience worthy of the streets it serves, inside the constraints of a no-code platform, an established brand, and a lean team.
Role
Product Manager/Designer
Timeline
April 2024 – September 2025
Skills
Product strategy, UX design, UI Design
About Glitter
Glitter is a social impact cleaning service based in Philadelphia. They facilitate neighbor-funded cleanups for city blocks, hiring and paying a living wage to cleaners who often have barriers to work. The work is hyper-local by design: each city block has its own funding status, its own community, and its own story to tell.
As Product Manager, I owned the 0→1 build of Glitter's member portal web app — from tool selection and data strategy through design, iteration, and launch.
1k+
City blocks and users in a dynamic, on-brand member portal web app, each auto-generated from a single data source
0→1
Full product built from scratch, no custom dev, in-house maintained, scalable without manual intervention
How might we design a member portal web app experience that makes every neighbor feel like their block is known, without custom-building anything?
Glitter had an established brand, an engaged user base, and a growing program. What it didn't have was a digital front door that could meet neighbors where they were.
Before the member portal, neighbors had no place to log in, check their block's real-time status, or see real-time cleanup results. Trust was built through manual outreach. Pledge pages were hand-built per block — no real-time data, no personalization, no scale.
The design problem had two layers:
.svg){kind=small}
Surface the right info to the right user at the right moment
Build trust without overwhelming with complexity
Work for users with varying technical comfort
Starting loose. Getting precise.
Early wireframes and user flows were intentionally rough, focused on hierarchy and critical data touchpoints, not visual polish. The goal was to identify constraints before committing to decisions.
Tool selection was a foundational design decision. After evaluating options against Glitter's constraints — cost, in-house maintainability, no custom dev, scalable to 1,000+ blocks — Softr emerged as the right platform. Every subsequent design decision was made within that context.
How it unfolded
Initial user flows mapped three entry points: Glitter's interactive marketing map, direct URL, and QR codes on physical street signs. Each needed to land a neighbor on the right block page and guide them to act.
Lo-fi wireframes moved into Softr's editor early, letting real platform constraints inform design before high-fidelity work began. User interviews using these builds generated directional and specific feedback, synthesized and prioritized to guide iteration.
I collaborated with the CEO and founder on user feedback sessions, synthesizing insights from a range of conversations with existing users, prospects, and community members. Not all feedback mapped directly to scope or technical feasibility, so a meaningful part of the work was translating raw input into prioritized, actionable design decisions, filtering for what was realistic within Softr's constraints and Glitter's data architecture, and building alignment around what to act on and what to set aside.
User flow mapping & wireframes in Figma
Lo-fi prototype in Softr editor — first iteration
Marked-up user interview feedback from a long time subscriber
As early design concepts were developing, Glitter launched two large-scale grant-funded cleaning initiatives. My role expanded: stakeholder engagement, operations planning, community outreach, and integration of both initiatives into the app's data architecture.
To maintain momentum while managing parallel grant-funded initiatives, I collaborated with the founder on scoping and running an RFP process, evaluating Softr specialists, independent designers, and local agencies. I was present for every conversation and exchange, and advocated for the candidate I felt was best suited for the work, a Softr specialist with hands-on platform experience, data architecture knowledge, and some design and coding background.
We ultimately partnered with a local design agency whose designer had a strong grasp of the deliverables and scope, and brought graphic design experience to the asset creation work. I led onboarding, set collaboration parameters, and ran design reviews throughout the engagement.
As the work progressed, it became clear that the agency's limited experience with Softr and low-code platforms was creating friction between what was being designed and what could actually be implemented. Delivered assets required significant reworking to fit within the platform's constraints and align with the data architecture already in place. When the decision was made to step back from the engagement, I led the recalibration, took execution back in-house, and drove the work through to a shipped V1.
Agency user flow diagramming in FigJam
Proposed agency CTA assets — did not meet bar
With clearer alignment, I led the rebuild of the experience directly in Softr, working closely with the CEO through an iterative review process. I owned the end-to-end product management of the scope, documenting pages, sections, user flows, and data architecture considerations in Asana to keep the work on track. On the implementation side, I applied custom HTML and CSS for brand typography, window.record lookups to ensure dynamic data pulled accurately from Airtable, and AI-assisted illustration assets to fill visual gaps left by the agency, drawing on prior product design experience to guide accessibility considerations and platform-specific decisions throughout.
As early design concepts were taking shape, Glitter was preparing to launch two large-scale grant-funded cleaning initiatives. My role expanded to oversee stakeholder engagement, operations and logistics planning, community outreach, and the integration of these projects into Airtable and, ultimately, the web app.
To maintain momentum while the product remained in a pre-MVP stage and ensure alignment with brand and technical needs, we partnered with a digital product agency to help bring the experience forward.
With the initial structure in place, Glitter and the agency aligned on a scope focused on developing new brand assets, refining UX and user flows, and translating wireframes into Softr’s dynamic and static components, including custom code where needed. The collaboration began with a comprehensive walkthrough of the business and the Softr editor to ground the work in platform realities. Regular design reviews were conducted both one-on-one and with leadership to ensure alignment as the work progressed.
Recalibrating Our Approach
It became clear that alignment across stakeholder vision, platform constraints, and practical realities was essential before further design work could continue. We paused, reassessed the direction, and ultimately made the decision to step back and recalibrate our approach.
With clearer alignment and renewed focus, we returned to the core structure, iterating on what was working, refining what wasn’t, and rebuilding directly within Softr. This phase emphasized thoughtful execution, deeper customization, and a tighter connection between data architecture, brand, and user experience.
Where previously delivered assets fell short of expectations, we leveraged AI-assisted tools to generate adaptable visual components that, while not identical to the original Smith & Diction brand work, provided a cohesive and flexible extension of the identity within the web app. Additional refinement came through implementing targeted custom code, including window record lookups, to ensure dynamic data was pulled accurately and updates required minimal manual intervention.
Designed polished dynamic and static templatized mockups that would scale to 1,000+ city blocks in Glitter’s database
Extended Softr's out-of-the-box capabilities with custom HTML/CSS and window.record lookups
How might we build trust and increase visibility while streamlining onboarding for new city blocks and users?
The clearest expression of the design work is the transformation of Glitter's block pages — from static, hand-built pledge pages to dynamic, data-driven block profiles.
Before: Static Pledge Pages
Hand-built per block, no real-time data
Manual image uploads & monetary adjustments
No conditional content or permissions
Scaling was operationally impossible
After: Dynamic Page Templates
Auto-generated from Airtable data
Real-time funding status & cleaning history
Conditional visibility & permission-based access
Scales to 1,000+ city blocks and users
The public view of a city block’s page provides clear, block-specific details while introducing Glitter’s broader services, helping users easily imagine what the program could look like on their own block. The page is accessible through multiple entry points, whether users arrive via the interactive map on Glitter's web page or by scanning a QR code on a street sign.
Once signed in, users are brought to a personalized dashboard that conditionally reflects their block association based on their account. Visual cues, like the waving raccoon mascot and block-specific UI cards, reinforce correct identification and give users clear access to detailed block information.
Grant-funded blocks are surfaced alongside neighbor-funded blocks through the same templated, conditionally driven system. By planning for their inclusion in the database, Glitter made large-scale grant-funded initiatives visible, allowing residents to opt in to additional pledges to support expanded cleaning.
Real-Time Cleaning Photo Feed
After cleanings, Glitter cleaners submit photos through a Trello-based workflow, which flows into Airtable and surfaces block-by-block in the member portal through Softr. The design challenge was hierarchy: how do you surface this content prominently without making it the entire page?
Within Softr's constraints, we tested both horizontal scroll and a card-based layout with a load more option. Horizontal scroll created an infinite feed of cleaning photos, and while the accountability value is real, the content itself is photos of trash. Each week brings new trash. Surfacing years of it in a continuous scroll worked against the experience rather than for it.
We landed on a fixed set of UI cards with a load more button, giving users agency without defaulting to infinity. For logged-in users who want more legacy info, a cleaning log table displays all historical records from latest to earliest, keeping the detail available without putting it in everyone's path.
Real-time cleaning photo feed — block-specific, automatically updated
Previously, Glitter relied on a manual, time-consuming workflow that made scaling difficult. Each new city block or user required hand-creating fundraising pages, uploading images, and manually adjusting contribution amounts, slowing onboarding and limiting visibility for end users.
We designed scalable page templates that dynamically pull data across 1,000+ city blocks in Glitter's database, conditionally displaying block details, funding contributions, and cleaning status to improve transparency and accelerate onboarding.
Before: Static Pledge Pages
Manual updates required for each block, no real-time data
After: Dynamic Page Templates
Real-time data, conditional visibility, permission-based access
Designing at scale requires more than design.
Partnered closely with leadership to align on vision, goals, and constraints. Through ongoing prioritization and trade-offs, design decisions balanced business needs with scalability and long-term maintainability.
Facilitated user interviews with leadership and synthesized insights to surface trust signals, clarity gaps, and onboarding friction. Research findings and ongoing feedback informed product and design decisions, balancing user needs with technical and data constraints.
Collaborated with operations and cleaners to understand on-the-ground workflows and constraints. Their input surfaced edge cases and operational realities that directly shaped data visibility, content hierarchy, and system design.
Worked directly with the Softr team to navigate platform constraints and capabilities. These discussions shaped implementation decisions around dynamic data, templates, and custom code integrations to ensure scalability and a consistent product experience.
It paid off to build a strong relationship with the Softr team that went beyond customer success and engineering and into marketing. Together, we shipped a product they were proud to showcase — resulting in Softr’s first in-person, video-documented customer case study for their customer story series.
This work was shaped through close collaboration with internal stakeholders, operations, and external stakeholder partners. Input from cleaners, user interviews, and the Softr team directly informed design decisions, ensuring the solution worked in real-world workflows, not just in theory.
Partnered closely with leadership to align on vision, goals, and constraints. Through ongoing prioritization and trade-offs, design decisions balanced business needs with scalability and long-term maintainability.
Collaborated with operations and cleaners to understand on-the-ground workflows and constraints. Their input surfaced edge cases and operational realities that directly shaped data visibility, content hierarchy, and system design.
Facilitated user interviews with leadership and synthesized insights to surface trust signals, clarity gaps, and onboarding friction. Research findings and ongoing feedback informed product and design decisions, balancing user needs with technical and data constraints.
Worked directly with the Softr team to navigate platform constraints and capabilities. These discussions shaped implementation decisions around dynamic data, templates, and custom code integrations to ensure scalability and a consistent product experience.
What shipped and what it produced.
Launched a fully dynamic, on-brand member hub serving 1,000+ city blocks — each auto-generated from a single data source
Eliminated manual page creation entirely — new city blocks onboard automatically through the data architecture
Improved neighbor trust and visibility through real-time block data, cleaning photo history, and personalized dashboards
Selected by Softr as their first in-person, video-documented customer case study — recognition that extended well beyond Glitter's user base
Established a design system and component library that supports ongoing iteration without starting from scratch
Things I'd carry into the next build — on craft, constraints, and what it actually takes to ship something that feels right.
01
Softr's div block structure, conditional logic, and data binding weren't limitations to design around — they were the medium. Designing with the grain of the platform produced a more stable, maintainable result than forcing a Figma mock into a tool that couldn't support it.
work with the platform, not against it
02
Working within an established brand while building in a no-code tool created real tension. Custom code where needed, AI-assisted assets where acceptable — it worked for V1, but underscored that a mature design system needs to be platform-aware from the start.
style guide ≠ design system
03
The decision to bring in outside help, and then to step back from it, taught me more about scoping, onboarding, and design review than most projects do. Recognizing misalignment and making a clean pivot was as important as anything in the final product.
knowing when to change course
04
Getting leadership aligned on design thinking, on what "good" looked like, on how to evaluate options, on what trade-offs were worth making, was as important as the interface itself. You can't ship great design without it.
alignment before pixels
