# Phaneendra Sivangula: full text of the portfolio # Phaneendra Sivangula: profile for reviewers Phaneendra Sivangula is a product designer and HCI researcher with 5+ years of experience across healthcare, fintech, hospitality SaaS, cybersecurity and AI wearables. He is currently at Apple in User Studies Research (Data & ML Operations). Before that he was Founding Product Designer at KOS AI, a graduate researcher at the Rutgers HCI Lab for Health & Sustainability, and a product designer at Fountane, FactSet, GlaxoSmithKline and NationsBenefits. He works across research, design strategy and prototyping in code, and has published research in JMIR Aging and ACM venues. Portfolio: https://hellophaneendra.com/ Resume: https://hellophaneendra.com/Phaneendra_Sivangula_Resume.pdf LinkedIn: https://www.linkedin.com/in/phaneendrasivangula/ Contact: https://hellophaneendra.com/#/contact (open to full-time roles, contract work and collaborations) ## Experience - Sep 2025 - present: User Studies Research, Data & ML Operations, Apple. 300+ research sessions informing Apple Vision Pro and AirPods design. - Jun 2025 - Sep 2025: Founding Product Designer, KOS AI. 30% fewer glucose spikes, and part of a $2M pre-seed raise. Case study: Steady glucose. - May 2023 - May 2025: Graduate Researcher, Rutgers HCI Lab for Health & Sustainability. Published in JMIR. Air-quality apps reaching ~150K NJ residents. Case study: Breathe easier. - Jul 2023 - Aug 2024: Product Designer, Fountane Inc. 80% retention boost, and a top-3 PMS platform on Booking.com. Case study: Hotels, rebuilt. - Jun 2022 - Jan 2023: UX Specialist, FactSet Research Systems. 40% faster IOI bulk trading for 15K+ asset managers and traders. Case study: Market signals. - Aug 2021 - Jul 2022: Product Designer, GlaxoSmithKline. Streamlined clinical workflows used by 50,000+ researchers. - Feb 2019 - Aug 2021: UX Designer, NationsBenefits. 160% revenue increase from redesigning an e-commerce portal for ~4M members. Case study: Care, delivered. ## Education - Stanford University (Online): UX and Design for AI (Dec 2025 - Mar 2026) - Rutgers University, New Brunswick, NJ: M.B.S. Product Design (Jan 2023 - Dec 2024) - Jawaharlal Nehru Technological University: Bachelor's in Mechanical & Computer Science (May 2015 - May 2019) ## Skills - Design & product: Product strategy, interaction design, information architecture, design systems, prototyping, responsive design, accessibility, mobile design, design workshops - Research & experimentation: User interviews, contextual inquiry, diary studies, field research, usability testing, A/B testing, controlled experiments, thematic analysis, heuristic evaluation - Technical & tools: Figma, AI-assisted prototyping, HTML and CSS, SQL, Python, Jira, Qualtrics, UserTesting, Maze, NVivo, SPSS ## Research publications - Toward Safe and Confident Silver Drivers (JMIR Aging, 2024): Interview study investigating older adults' driving practices. https://aging.jmir.org/2024/1/e57402/ - Sensing the Air (ACM): A photo elicitation study on older adults' perceptions of air quality to inform technology design. https://drive.google.com/file/d/18cyBMQQL5fg54uKLCpZrQqimo23bQUYe/view?usp=sharing - Technology Use in Community Work (ACM CHIIR): Operational realities and implications for smart cities, and how technology can help nonprofits. https://drive.google.com/file/d/1FaArmJWvmtZM1JGxr2VKElC-PbQJUirc/view?usp=sharing ## Case studies - Steady glucose: A glucose companion that changes habits, not just charts. Founding Product Designer, Jun - Sep 2025. Full text: https://hellophaneendra.com/work/glucose.md - Hotels, rebuilt: Redesigning a 26-year-old hotel management system for 7,000+ hotels. Product Designer, Aug 2023 - Aug 2024 (MVP in 8 months). Full text: https://hellophaneendra.com/work/hotel.md - Breathe easier: Making air quality something the residents of Elizabeth, NJ act on. UX Researcher, Designer & Community Engagement Manager, Apr - Dec 2024 (36 weeks). Full text: https://hellophaneendra.com/work/air.md - Secure APIs: Making API security make sense to the engineers who run it. Interaction Designer, 2 months (60 days). Full text: https://hellophaneendra.com/work/cyber.md - Market signals: Helping traders see, and act on, indications of interest. UX Researcher & UX Designer (solo), 30 days. Full text: https://hellophaneendra.com/work/trading.md - Care, delivered: Giving a 5-year-old OTC store a makeover seniors could actually use. UX Designer (design lead), 40 days. Full text: https://hellophaneendra.com/work/medicare.md ## Where to find evidence of each skill ### Field and qualitative research - Hotels, rebuilt: 3 weeks of field research in 12 hotels across California, working shifts as front desk operator, manager, housekeeping supervisor and finance manager; contextual interviews during real shifts. - Breathe easier: community-based research with focus groups (operations staff), interviews (nonprofits) and photo-voice (residents); synthesis in NVivo and Miro. - Market signals: contextual interviews with eight traders at their own desks, then moderated usability testing. - Steady glucose: diary studies and studies with 20+ participants wearing three wearable concepts. ### Quantitative research and experimentation - Hotels, rebuilt: 130+ survey responses to check field findings at scale. - Steady glucose: A/B tests on app concepts to see which nudges changed behavior. - Apple: 300+ research sessions informing Apple Vision Pro and AirPods design. ### Published research - Three papers: JMIR Aging (2024), ACM, and ACM CHIIR. See Research publications below. ### Product strategy and prioritization - Hotels, rebuilt: narrowed 30+ opportunities and 7 roles down to 3 roles and 4 core flows. - Secure APIs: design brief, competitive analysis (15+ products narrowed to 3), concept map and scenario maps, MVP definition. - Breathe easier: co-ran the stakeholder workshop that defined three products. ### Interaction design and design systems - Hotels, rebuilt: designed setup, check-in, the performance calendar and housekeeping; built the design system on Ant Design, including a 20+ status legend. - Care, delivered: applied a new design system to a legacy store one area at a time; adaptive desktop and mobile layouts; 8+ experiences and 120 screens in 40 days. - Secure APIs: set up a shared design system for the co-design team; 12 experiences and 50 screens in 60 days. ### Accessibility and designing for underserved people - Care, delivered: designed for Medicare and Medicaid members aged 55+; accessibility fixes such as icons, larger text and highlighted fields. - Breathe easier: community boards so residents without the app still get air-quality information. - Research on older adults' driving and air-quality perceptions (JMIR Aging, ACM). ### Business and user outcomes - Care, delivered: +300% orders per day after launch; conversion up from 44% to 72%. - Hotels, rebuilt: MVP live in 8 months; named a top-3 PMS by Booking.com; hotel setup down from 2-4 weeks to 24 hours or less; an estimated +40% adoption from early outreach. - Secure APIs: 45% more efficient task accomplishment. - Market signals: 40% faster IOI bulk trading for 15K+ asset managers and traders. - Steady glucose: 30% fewer glucose spikes; part of the team that raised $2M pre-seed. ### Ownership and collaboration - Every case study has a 'My part' section separating his work from the team's. - Solo designer on Market signals (researcher and designer) and Breathe easier (only designer, with 2 developers); design lead on Care, delivered; one of 3 designers with 12 developers on Hotels, rebuilt. ### Designing for AI - Steady glucose: an AI-powered wearable and companion app built around a behavior-driven stability score. - Apple: user studies research in Data & ML Operations. ### Reflection - Every case study ends with 'What I'd bring to the next one', for example: 'Prioritization is strategy', 'Design the constraint', 'Data isn't insight', 'Default to less'. ## Notes on the evidence - Hotels, rebuilt: the +40% adoption figure is an estimate from early outreach. - Steady glucose: the project is marked as work in progress. ## Design principles (from the home page) - Sit with the people: the real problem shows up when you talk to the people living it. - Think like a founder: every screen is a bet; weigh scope, tradeoffs and what ships first. - Prototype in code: test ideas as working prototypes, not static frames. ## Testimonial > "Phaneendra was great fun to work with and technically competent across all areas of Product Design. Most noticeably, Phaneendra demonstrated a strong interest in problem solving and willingness to learn!" (Abhinav, Founder of Clair Health) --- # Home page (https://hellophaneendra.com/) ## Hello! I'm Phaneendra, product designer with a founder mindset. Skilled in design strategy, prototyping with code, and designing for AI. Currently at Apple, in User Studies Research for Data & ML Operations. PROJECTS ### Selected work Work in progress 30% Rebuilt a hotel management system, with an estimated 40% lift in adoption. Helped ~150K people adapt to changing air and weather conditions. Simplified workflows for a cybersecurity startup and improved efficiency by 45%. Made IOI bulk trading 40% faster for 15K+ asset managers and traders. Made health and wellness products easy to buy online for ~4M Medicare & Medicaid members. PRINCIPLES ### What I believe Good design is a series of decisions, made with people, not for them. #### Sit with the people The real problem shows up when you talk to the people living it. #### Think like a founder Every screen is a bet. I weigh scope, tradeoffs and what ships first. #### Prototype in code I test ideas as working prototypes, not static frames. EXPERIENCE ### Where I've worked Sep '25 - Now Apple User Studies Research, Data & ML Operations Jun '25 - Sep '25 KOS AI Founding Product Designer May '23 - May '25 Rutgers HCI Lab for Health & Sustainability Graduate Researcher Jul '23 - Aug '24 Fountane Inc. Product Designer Jun '22 - Jan '23 FactSet Research Systems UX Specialist Aug '21 - Jul '22 GlaxoSmithKline Product Designer Feb '19 - Aug '21 NationsBenefits UX Designer RESEARCH ### Research publications JMIR AGING, 2024 #### Toward Safe and Confident Silver Drivers Interview study investigating older adults' driving practices. ACM #### Sensing the Air A photo elicitation study on older adults' perceptions of air quality to inform technology design. ACM CHIIR #### Technology Use in Community Work Operational realities and implications for smart cities, and how technology can help nonprofits. WHAT'S NEXT ### Let's build something that works for everyone. LinkedIn --- # About (https://hellophaneendra.com/#/about) ABOUT ## Hi, I'm Phaneendra. I grew up in a village in India with no electricity. When something broke, you fixed it with what you had. That's still how I work. Since 2019 I've designed healthcare portals, clinical tools and trading platforms used by millions of people. Today I'm in User Studies Research at Apple, watching how people use new products. I care most about the people systems leave out. One day, I'd like to build a company that fixes broken systems. LinkedIn --- # Steady glucose: A glucose companion that changes habits, not just charts Designer: Phaneendra Sivangula Interactive version: https://hellophaneendra.com/#/work/glucose Role: Founding Product Designer Timeline: Jun - Sep 2025 Team: KOS AI Summary: Designing a gamified companion app and a wrist-worn wearable that turn glucose data into small, daily behavior changes. Problem: Glucose apps show charts after the fact. People saw their spikes, felt judged, and nothing about their day changed. Approach: Diary studies, A/B tests and 20+ participants wearing three wearable concepts, to find which nudges actually changed habits. Outcome: 30% fewer glucose spikes, three concepts validated, and part of a $2M pre-seed raise. --- Work in progress HEALTH / AI WEARABLE / KOS AI ## A glucose companion that changes habits, not just charts Designing a gamified companion app and a wrist-worn wearable that turn glucose data into small, daily behavior changes. ROLE Founding Product Designer TIMELINE Jun - Sep 2025 COMPANY KOS AI METHODS A/B testing, diary studies, participant studies 30% fewer glucose spikes 3 wearable concepts validated $2M pre-seed raised with the core team PROBLEM Glucose apps show charts after the fact. People saw their spikes, felt judged, and nothing about their day changed. APPROACH Diary studies, A/B tests and 20+ participants wearing three wearable concepts, to find which nudges actually changed habits. OUTCOME 30% fewer glucose spikes, three concepts validated, and part of a $2M pre-seed raise. 01 Overview OVERVIEW ### From data to daily habits As the founding product designer at KOS AI, I designed and evaluated a gamified glucose-tracking companion app alongside a wrist-worn wearable. The goal was simple to say and hard to do: help people keep glucose steady by nudging everyday behavior, not by showing them more charts. 02 Research RESEARCH ### Listening over weeks, not minutes Glucose changes with food, sleep, stress and mood, so a single interview would miss most of the story. We combined methods that follow people over time. - Diary studies to capture daily context around spikes - A/B tests on app concepts to see what actually changed behavior - Studies with 20+ participants wearing the wrist-worn device 03 Insight INSIGHT ### Mood and glucose move together Diary studies surfaced a correlation between mood and glucose that shaped how the app nudges people. That finding moved the design away from pure numbers and toward a behavior-driven stability score that people could act on during their day. 04 Design DESIGN ### A score people can act on The companion app turns readings into a single stability score, with game mechanics that reward steady days instead of punishing bad ones. For the wearable, I co-led research on ergonomics and comfort so the device would work for everyday, long-term wear, iterating across three concepts. 05 Outcome OUTCOME ### Validated and funded - Participants saw 30% fewer glucose spikes - Three wearable concepts validated through participant studies - Co-presented the product to investors, helping secure $2M in pre-seed funding --- # Hotels, rebuilt: Redesigning a 26-year-old hotel management system for 7,000+ hotels Designer: Phaneendra Sivangula Interactive version: https://hellophaneendra.com/#/work/hotel Role: Product Designer Timeline: Aug 2023 - Aug 2024 (MVP in 8 months) Team: 3 designers, 12 developers Summary: ASI PMS runs 7,000+ US hotels and 1B+ bookings a year, but it was built for small, simple properties. We researched, prioritized and redesigned it for complex, multi-role hotels, and shipped the MVP in 8 months. Problem: A 26-year-old PMS built for small hotels. Setup took 2-4 weeks and staff worked around it with spreadsheets and paper. Approach: Worked shifts in 12 hotels, picked 3 roles out of 7, and redesigned 4 core flows on a modular design system. Outcome: MVP live in 8 months. Top 3 PMS on Booking.com, an estimated +40% adoption, setup in 24 hours or less. --- HOSPITALITY / SAAS / ASI VIA FOUNTANE ## Redesigning a 26-year-old hotel management system for 7,000+ hotels ASI PMS runs 7,000+ US hotels and 1B+ bookings a year, but it was built for small, simple properties. We researched, prioritized and redesigned it for complex, multi-role hotels, and shipped the MVP in 8 months. ROLE Product Designer TIMELINE Aug 2023 - Aug 2024 (MVP in 8 months) TEAM 3 designers, 12 developers TOOLS Figma, Ant Design, SurveyMonkey Top 3 PMS, as named by Booking.com ~40% estimated adoption lift, from early outreach 24 hrs or less to set up a hotel, down from 2-4 weeks PROBLEM A 26-year-old PMS built for small hotels. Setup took 2-4 weeks and staff worked around it with spreadsheets and paper. APPROACH Worked shifts in 12 hotels, picked 3 roles out of 7, and redesigned 4 core flows on a modular design system. OUTCOME MVP live in 8 months. Top 3 PMS on Booking.com, an estimated +40% adoption, setup in 24 hours or less. 01 The brief OVERVIEW ### The product and the business need ASI PMS is a property management system that has run hotels across the US for 26 years: 7,000+ properties and 1B+ bookings a year. Front desk, housekeeping, managers and owners all work in it every day. 26 yrs in the market 7,000+ hotels 1B+ bookings a year It was built for small, simple hotels. As ASI moved into larger properties, with many departments and roles working at the same time, the product couldn't keep up. #01 #### Clients were frustrated Just getting set up took 2-4 weeks of back-and-forth with ASI support. #02 #### The interface had aged 26 years of features without a design system made a capable product hard to use and hard to trust. #03 #### A deadline was coming The AAHOA conference was the moment to show a new ASI, and any delay risked losing clients. The goal: research, strategize and redesign the end-to-end experience for complex, multi-role hotels, on a modular foundation that could grow. MY PART ### What did I do? I was the product designer on a team of 3 designers and 12 developers, from research through launch. - Field research in 12 hotels, working as front desk operator, manager, housekeeping supervisor and finance manager - Helped narrow 30+ opportunities down to 3 roles and 4 core flows - Designed setup, check-in, the performance calendar and housekeeping - Built the design system alongside the product, on Ant Design - Wrote handoff docs for every component, including a 20+ status legend - Ran live usability tests with customers at AAHOACON 02 Research RESEARCH ### We worked the front desk ourselves We came in as outsiders to hospitality, with no assumptions to protect. We knew the system was broken. We didn't know why staff kept using it anyway. 3 weeks in the field 12 hotels across California 130+ survey responses - Ethnographic studies from small independent motels to large chains - Contextual interviews with staff during real shifts - Surveys to check what we saw at scale FINDINGS ### Staff were working around the product Next to the software, in almost every hotel, we found the same three things: #01 #### The rate spreadsheet Pricing was managed outside the system, then typed back into it. #02 #### The paper checklist Housekeeping tracked rooms on clipboards, not screens. #03 #### The verbal handoff Reservation changes were passed on by word of mouth between shifts. That's not a user problem. It's a design failure that had been normalized for years. #### Underneath, the problems were architectural #01 #### Weeks before day one Setup ran through ASI support. Hotels met the product through weeks of back-and-forth. #02 #### Everything for everyone Built for no role in particular, so every role got every feature. #03 #### Always reacting No proactive intelligence. Problems were handled after they arrived. #### And then, the screen itself 26 years of features, no design system. Nothing told you what needed attention now and what was just background. At a busy front desk, that's not an aesthetic issue. It's a functional barrier. 03 Strategy STRATEGY ### 30+ opportunities. 7 roles. We picked 3. Designing for all seven roles would have diluted everything. With a hard conference date and frustrated clients, we set three principles: 1 Start with the 3 roles with the most daily use and the most workarounds: front desk, housekeeping and hotel manager 2 Use AAHOACON as a forcing function: real users, a real booth, a real date 3 Build modular, so the other roles and integrations can plug in later Prioritization was the most important decision we made, and it wasn't a design decision. IDEATION ### Mapping, sketching, then deciding - Experience maps for every scenario, including failure states - Workflows co-written with engineering before committing to a direction - 8-up sketching to stay divergent, then peer reviews before high fidelity - Borrowed mental models from tools staff already used every day #### Sketches first Every flow started on paper, so we could throw away ideas cheaply before any pixels existed. That work shaped four core flows. Here's how each one went from finding to design. 04 Design 01 SETUP ### The four-week wait A new hotel signs up, then waits two to four weeks for ASI support to configure it, with no way to see how far along it is. That wait is where people form their first picture of a product. The picture was friction and dependency. THE QUESTION How might we let hotels set themselves up, and reach first value without calling support? Experience maps showed which moments actually blocked people and which only slowed them down. That line decided the MVP. Workflows also showed pricing and plans sat at the very end of setup, which changed the design. #### Two constraints we couldn't remove #01 #### The verification wait Regulation required it. So we designed the waiting, instead of pretending it away. #02 #### The price list Pricing had to get simpler before the UI could. That was a business conversation, not a design one. Here is the new setup flow, from an empty account to the first payment. Every step saves, and the plans fill the verification wait. 01Start from an empty list Add a group or a single property, or import from Booking.com. 02Property basics Name, website, proof of identity, logo and photos. 03Contacts and address Who to reach, who owns it, and where it is. 04Pick a plan while verification runs The required wait becomes time to choose a plan. 05Add-ons and a bundle Extra modules and hardware sit right next to the plans. 06Pay, with the total in view Saved cards or a bank account, and a clear subscription summary. BEFORE 2-4 weeks, run by support, with no progress in sight. AFTER A 4-step guided flow, self-served. Every step saves, so an interruption means pausing, not starting over. 20 min - 24 hrs to set up a hotel 02 CHECK-IN ### Three screens, one guest At the front desk, operators switched between three screens, rooms, guest details and billing, while the guest waited. Check-in isn't a form. It's a conversation. THE QUESTION How might we make check-in fast and intuitive enough to finish within five minutes? We tested three information architectures instead of betting on one: Variation 1 Booking details Available rooms You're in! Less navigation, more visual complexity. Variation 2 Available rooms Booking details You're in! Matched how staff think, but broke when rooms weren't available. Variation 3 Room needs Available rooms Booking details You're in! Best completion under realistic interruptions. - Progressive disclosure: only what this moment needs - Pre-filled suggestions for repeat guests - Patterns staff already know, for a role with high turnover It should feel inevitable. Not something you learned, but something you already knew. 03 PERFORMANCE ### Pulling the spreadsheet back inside A revenue manager wants to know three things: how bookings look, which rooms are out of service, and what the next few days hold, so they can change prices without leaving the system. THE QUESTION How might we show hotel performance so it's clear, complete and quick to read? Revenue managers already knew these patterns. We didn't need a new paradigm, just a familiar one applied to hotel data. - A calendar and Gantt hybrid: overview up top, detail inline - Color-coded room status you read before you read a word - KPIs inside the chart, not on a separate report #### One legend, 20+ statuses Every status had rules for when it could be applied or overridden, and a color that had to be readable at a glance and technically exact. It took several rounds with engineering. I'd rather have those conversations at the start of a sprint than at the end. 04 HOUSEKEEPING ### Hands full, no time to tap A housekeeper moves room to room all day, hands full. A supervisor sits at a desk, planning the floor. Same data, very different days. Staff pushed back on a complex app. So we split it in two: SUPERVISOR Auto-assign, a full room status overview and oversight tools. STAFF A status-first view: a room's condition reads through color, without reading anything. One interface for both would have served neither. 05 Outcome DELIVERY ### Designing while it was being built As scope grew and time shrank, design and development ran in parallel sprints. Design kept uncovering problems the original documents had missed. Agile gave us room to act on them instead of filing them away. LAUNCH ### The booth became the usability lab Eight months in, we took the MVP to AAHOACON and ran live usability tests with real customers at the ASI booth. Their feedback landed on the exact friction points our research had found. 8 mo from research to a live MVP Top 3 PMS, named by Booking.com ~40% estimated adoption lift And Expedia made ASI a preferred partner. The real validation wasn't that we shipped something impressive. It's that we shipped something that solved the right problem. TAKEAWAYS ### What I'd bring to the next one 1 #### Prioritization is strategy. Choosing 3 roles out of 7 shaped the product more than any screen. 2 #### Design the constraint. When the wait couldn't go away, designing the wait was the answer. 3 #### Work the job. A shift behind the desk explained more than any interview. 4 #### Talk to engineering early. The legend, the flows and the setup all got better before a line of code. --- # Breathe easier: Making air quality something the residents of Elizabeth, NJ act on Designer: Phaneendra Sivangula Interactive version: https://hellophaneendra.com/#/work/air Role: UX Researcher, Designer & Community Engagement Manager Timeline: Apr - Dec 2024 (36 weeks) Team: 1 designer, 2 developers Summary: BREATHE Elizabeth turns live air quality and heat data into simple, local guidance for residents, staff and researchers. Built with the community under a $1M NSF grant, and released in 36 weeks. Problem: Elizabeth faces serious air quality issues, and residents judged the air by smell and sight, with no easy way to see real data. Approach: Community-based research with residents, staff and nonprofits, then a workshop that turned findings into three products. Outcome: A live dashboard, sensor map and community boards, released to the residents of Elizabeth. --- PUBLIC HEALTH / RUTGERS HCI LAB ## Making air quality something the residents of Elizabeth, NJ act on BREATHE Elizabeth turns live air quality and heat data into simple, local guidance for residents, staff and researchers. Built with the community under a $1M NSF grant, and released in 36 weeks. ROLE UX Researcher, Designer & Community Engagement Manager TIMELINE Apr - Dec 2024 (36 weeks) TEAM 1 designer, 2 developers TOOLS Figma, Miro, NVivo, SurveyMonkey ~150K residents in Elizabeth, NJ can check their local air 3 products shaped in one community workshop 36 wks from first interviews to launch PROBLEM Elizabeth faces serious air quality issues, and residents judged the air by smell and sight, with no easy way to see real data. APPROACH Community-based research with residents, staff and nonprofits, then a workshop that turned findings into three products. OUTCOME A live dashboard, sensor map and community boards, released to the residents of Elizabeth. 01 The brief OVERVIEW ### Air you can't see, decisions you make every day Air pollution is the leading environmental threat to human health worldwide. In Elizabeth, New Jersey, it hits hardest in vulnerable, low-income neighborhoods. 8.1M premature deaths a year, worldwide 2.2 yrs of life expectancy lost $1M NSF grant behind the project Sensors across the city were already collecting data. The problem was that almost nobody could use it to decide whether to open a window, go for a walk or wear a mask. The goal: deliver real-time air quality data, health insights and behavioral recommendations, so residents can make safer choices on bad-air days. MY PART ### What did I do? I was the only designer, working with 2 developers, and the link between the research team and the community. - Planned and ran community-based research with residents, staff and nonprofits - Synthesized findings in NVivo and Miro - Co-ran the stakeholder workshop that defined what we'd build - Designed the design system, dashboard, map and community boards - Ran think-aloud usability tests and tracked design vs build quality 02 Research RESEARCH ### Research with the community, not about it With so many stakeholders and researchers involved, we chose Community-Based Participatory Research (CBPR), so every group had a voice in what we built. #01 #### Focus groups with staff Operational needs, pain points and day-to-day work with the sensors. #02 #### Interviews with nonprofits The challenges of groups already working with the community. #03 #### Photo-voice with residents Residents photographed what good and bad air looks like in their lives. FINDINGS ### People trusted their senses, not the data Each group struggled with air quality in a different way: #01 #### Residents Judged the air by smell and sight. No clear way to track it in real time, and little awareness of the health impact. #02 #### Operations staff Maintained equipment by hand, with no alerts for air quality or heat problems. #03 #### Nonprofits Little data sharing between city organizations, and a hard time motivating action. #### What good and bad air looks like Photo-voice showed residents link good air to green spaces and clear skies, and bad air to traffic, construction and garbage. If people read the air with their eyes and nose, the design had to translate numbers into something just as quick. 03 Strategy DEFINE ### Four questions to design for THE QUESTION How might we fit air quality data into residents' daily routines, so it changes what they do? - How might we give residents personalized health recommendations? - How might we make maintaining the system easier for operations staff? - How might we present air quality data so researchers and policymakers can act on it? IDEATION ### One workshop, three products We ran a collaborative workshop with stakeholders and researchers, and weighed every idea against the budget and resources we actually had. #01 #### A community app One place for residents' everyday needs, with air quality and health tips built into the routine. #02 #### A system for staff and researchers Monitor city-wide sensors, get alerts, and explore the data for reports and policy. #03 #### Community boards Screens in shared spaces: local air quality at a glance, with no effort at all. 04 Design INSPIRATION ### Borrowing from weather apps We studied weather apps, resident portals and community platforms. Weather apps stood out: they make complex, changing data feel simple. They also showed the gap: almost nothing tied air quality to the community it affects. ITERATIONS ### Version after version, June to August We started with a design system, so accessibility and branding stayed consistent across every product. Each version went back to stakeholders. We compared variations side by side, which made decisions faster than debating one design. TESTING ### Think aloud, then refine We looked at SUS, scenario-based testing and the NASA task load index, then chose think-aloud sessions and moderated interviews to hear how residents read air quality in the moment. We piloted the protocol with students first, and fixed it before testing with residents. DELIVERY ### Design vs development Design and build always drift apart. I kept a design delta document that tracked every difference, so we fixed the ones that mattered most first. 05 Outcome LAUNCH ### Live for the residents of Elizabeth BREATHE Elizabeth went live across three surfaces. Each surface goes one level deeper, from a glance on the street to the full sensor map. 01Glance at a community board Air quality, weather and quick tips, readable from across a room. 02Read the dashboard History, pollutants, weather and health advice for Elizabeth. 03Explore the sensor map Every sensor in the city, color-coded, for staff and researchers. The final designs. Use the arrows or swipe. Click a screen to see it full size. 01 / 03 Community boards, readable across a room TAKEAWAYS ### What I'd bring to the next one 1 #### Insights aren't enough. Actionable data only matters if it's delivered in a way that builds long-term habits. 2 #### Not every answer is an app. A screen in a community room reached people an app never would. 3 #### Let the community lead. Photo-voice showed us how people really read the air. --- # Secure APIs: Making API security make sense to the engineers who run it Designer: Phaneendra Sivangula Interactive version: https://hellophaneendra.com/#/work/cyber Role: Interaction Designer Timeline: 2 months (60 days) Team: Co-designers, PMs and the client team Summary: CloudVector's API security platform had the data but not the experience. In 60 days we redesigned the Enterprise and Community Editions around what SecOps engineers and admins actually need to see and do. Problem: A powerful API security product buried its value under raw data, which kept user acquisition and retention low. Approach: Product strategy first (brief, competitors, concept and scenario maps), then workflows, sketches, wireframes and visuals. Outcome: Redesigned Enterprise and Community Editions, a standout at the RSA conference and an award-winning design. --- CYBERSECURITY / CLOUDVECTOR ## Making API security make sense to the engineers who run it CloudVector's API security platform had the data but not the experience. In 60 days we redesigned the Enterprise and Community Editions around what SecOps engineers and admins actually need to see and do. ROLE Interaction Designer TIMELINE 2 months (60 days) TEAM Co-designers, PMs and the client team SCOPE 12 experiences, 50 screens 45% more efficient task accomplishment 12 experiences designed 50 screens in 60 days PROBLEM A powerful API security product buried its value under raw data, which kept user acquisition and retention low. APPROACH Product strategy first (brief, competitors, concept and scenario maps), then workflows, sketches, wireframes and visuals. OUTCOME Redesigned Enterprise and Community Editions, a standout at the RSA conference and an award-winning design. 01 The brief OVERVIEW ### APIs are everywhere, and so are the risks Businesses use APIs to connect services and move data. Broken, exposed or hacked APIs are behind major data breaches, and even practitioners struggle to discover, monitor and secure them. CloudVector built an end-to-end API security system that goes beyond the gateway, giving teams a full picture of their environment. Their core user, the SecOps engineer, needs both the big picture and the detail of a company's network. The hard part wasn't collecting the data. It was understanding raw data and turning it into insight. The challenge: a seamless, robust application that protects information privacy and delivers insight, because the poor experience was driving low acquisition and retention. MY PART ### What did I do? As the Interaction Designer, I worked with a team of co-designers and set up a common design system for all of us. I managed daily client conversations to set expectations on a tight two-month deadline, and flagged inconsistencies across modules to the PMs and design teams. - Design brief and concept map - Experience audit - Interaction design and interaction notes - Visual design and prototyping 1 Product strategy: validate the problem, pick the right problems, define the MVP 2 Design execution: workflows, sketches, wireframes and visuals 02 Research DESIGN BRIEF ### Naming every problem up front The design brief pinned down every user and business problem we were solving. Through several sessions with the client, we agreed where to focus: - The key differentiators of CloudVector weren't visible in the product - Users dug through multiple layers to find safety information - With so much data, it was easy to miss what mattered most - High cognitive load, and no clear next step after reading the data COMPETITIVE ANALYSIS ### Feature-rich, but not seamless Early research turned up 15+ products that could solve parts of the problem. We narrowed them to three: Wallarm, Salt Security and PingIdentity. We compared target users, problems solved, features and value proposition. They were powerful, but none addressed a robust, seamless experience. So we built our own. 03 Strategy CONCEPT MAP ### One web of players, objects and actions To make sure nothing slipped through, I built a concept map: the players, the objects and how they interact, forming the ecosystem the solution lives in. It grouped the product into Security, Discovery and Monitoring, and confirmed the two players we were designing for: the SecOps engineer and the system admin. SCENARIO MAP ### From every scenario to an MVP A scenario map listed every experience relevant to our players, and every scenario inside each one. The SecOps engineer and admin scenarios defined the MVP. We ranked the rest by the priority of the problems they solved, and split the roadmap into phases. #### Core experiences - Setup - Monitoring - Discovery - Configuration #### Responding - Events handling - Incident response - Alert management - Troubleshooting 04 Design WORKFLOWS ### Every scenario, step by step Each scenario needs a set of actions. I assigned those actions to specific screens and ordered them so they made logical, intuitive sense. These workflows set the information architecture for every platform, like the first-run path from the website to the Community Edition dashboard. SKETCHES ### Many ideas, quickly, on paper I sketched every screen from the workflows to explore layouts and patterns fast, each one aimed at a design problem: - How might we help the SecOps engineer proactively prevent risks? - How might we help admins create a monthly report? The sketches led to layout variations, pattern ideas, and even new features. WIREFRAMES & VISUALS ### Pinning down every component Low-fidelity wireframes nailed the exact function of each component, with interaction notes on the logic between elements. A simple-looking monitoring tool hid several hard problems, so I compared variations side by side for each one. Once the functionality was fixed, I created a style guide, and we designed the hi-fi screens for the DevOps engineer and admin platforms. Here is the final flow, from the first look at the dashboard to the audit report. Every view leads with the insight, and the raw data sits one click below. 01See every API at once 02Compare two spec profiles 03Zoom into any hour Brush the timeline and the whole dashboard follows. 04Read similarity at a glance One score and one bar before the detail. 05Track every call Daily API calls, with new APIs called out. 06Flag sensitive calls Sensitive calls get their own line, so spikes stand out. 05 Outcome VALUE DELIVERED ### A streamlined experience unlocked the product 2 editions redesigned: Enterprise and Community RSA a standout at the conference 1 award-winning design - CloudVector stood out at the RSA conference, where 32% of attendees had seen attempts to exploit their APIs in the past year - The Community Edition let teams try before they buy, and raised awareness of CloudVector's value - The client went on to win an award for the design The final designs. Use the arrows or swipe. Click a screen to see it full size. 01 / 03 One dashboard for every API TAKEAWAYS ### What I'd bring to the next one 1 #### Data isn't insight. Security data only helps when it points to what to do next. 2 #### Map the system first. The concept and scenario maps kept 12 experiences consistent in 60 days. 3 #### A free tier is a feature. Designing the Community Edition made the product easy to try, not just to buy. --- # Market signals: Helping traders see, and act on, indications of interest Designer: Phaneendra Sivangula Interactive version: https://hellophaneendra.com/#/work/trading Role: UX Researcher & UX Designer (solo) Timeline: 30 days Team: Worked directly with FactSet stakeholders Summary: Indications of interest (IOIs) tell traders who wants to buy or sell, but they were scattered and hard to read. In 30 days, I designed a FactSet IOI platform that captures, analyzes and presents them inside the trader's workflow. Problem: Traders had no easy way to capture, compare and act on IOIs inside their order workflow. Approach: Contextual interviews with 8 traders, affinity mapping, 6-up ideation, two concepts, then moderated usability tests with 5 users. Outcome: An IOI app with live market data, buy and sell side by side, custom filters and one-click routing from linked apps. --- FINTECH / TRADING / FACTSET ## Helping traders see, and act on, indications of interest Indications of interest (IOIs) tell traders who wants to buy or sell, but they were scattered and hard to read. In 30 days, I designed a FactSet IOI platform that captures, analyzes and presents them inside the trader's workflow. ROLE UX Researcher & UX Designer (solo) TIMELINE 30 days TEAM Worked directly with FactSet stakeholders SCOPE 6 experiences, 20 screens 40% faster IOI bulk trading 15K+ asset managers and traders 6 experiences, 20 screens in 30 days PROBLEM Traders had no easy way to capture, compare and act on IOIs inside their order workflow. APPROACH Contextual interviews with 8 traders, affinity mapping, 6-up ideation, two concepts, then moderated usability tests with 5 users. OUTCOME An IOI app with live market data, buy and sell side by side, custom filters and one-click routing from linked apps. 01 The brief BACKGROUND ### Signals of who wants to trade Indications of interest (IOIs) are messages from market participants saying they intend to buy or sell a financial instrument. They help other traders judge liquidity and interest before they place an order. IOIs come in many forms, from block trades and dark pool orders to conditional orders, after-hours trading and algorithmic strategies. Read well, they show market sentiment and point to real opportunities. How might we build a user-friendly platform that captures, analyzes and presents IOIs, so traders can make informed decisions and act on market opportunities? MY PART ### One designer, end to end I worked independently with FactSet stakeholders as both the UX researcher and the UX designer, from the first interview to the tested prototype. 1 Research: contextual interviews and synthesis 2 Ideation: workflows, 6-ups and two concepts 3 Design: wireframes, visuals and prototype 4 Validation: moderated usability testing 02 Research UNDERSTANDING THE PROBLEM ### Eight traders, in their own setup I started with contextual inquiry interviews with 8 traders, chosen to cover a range of perspectives, and followed their journey from spotting interest to executing an order. An affinity map turned the notes into four clear needs: - Essential data points to choose the right broker - IOIs inside the order workflow, not in a separate tool - Real-time market data to read sentiment - Control over what's displayed 03 Strategy IDEATING ### Workflows first, then two big ideas Each scenario became a workflow: the actions a trader needs, assigned to screens and ordered into a clear information architecture. Two opportunities stood out: #### Suggest the best IOI - Recommend the strongest available IOI - Cut the manual analysis - Lower the cognitive load #### Show IOI trends - Visualize historical IOIs - Pair them with market trends - Read liquidity quickly 04 Design PROTOTYPING ### 6-ups, two concepts, many rounds I ran 6-up brainstorms around key scenarios: viewing available IOIs, connecting to different blotters, filtering, and customizing the view. That led to two concepts, an IOI Deal Pad from the Orders panel and a discretionary approach. I iterated on both with client feedback across workflows, IA, sketches, wireframes and prototypes. FINAL DESIGNS ### Designing around real constraints Technical constraints meant trading off some features. I kept the focus on the user problems and product requirements, so the product would drive adoption and retention. Here is the final flow, from a ticker to a routed order. Live data gives each IOI context, buys and sells sit side by side, the grid is easy to customize, and linked apps route in one click. 01Search a security 02See every IOI for it 03Read the live quote Price, spread and volume give each IOI context. 04Compare buys and sells Both sides together help with price discovery and liquidity. 05Make the grid yours Filters and columns for each desk. 06Route in one click Linked apps trigger the order right from the IOI. 05 Outcome USABILITY TESTING ### Less data by default, more control I ran moderated usability tests with 5 FactSet users on their own desktops, testing efficiency, intuitiveness, learnability and findability. - Participants found the flows intuitive and finished tasks efficiently - Most users only needed some of the data, so I limited the default view - Users can still customize the display to match their needs What the new flow changed. Traders go from a ticker to a routed order without leaving their workflow: 40% faster IOI bulk trading 1 click to route an IOI from a linked app 2 letters to find a security 6 steps from ticker to routed order The final prototype. Use the arrows or swipe. Click a screen to see it full size. 01 / 03 Start with a search TAKEAWAYS ### What I'd bring to the next one 1 #### Go to the desk. Contextual interviews showed IOIs belong inside the order workflow. 2 #### Default to less. Show the few fields most traders use, and let the rest opt in. 3 #### Constraints shape the scope. Cut features, but never the core user problems. --- # Care, delivered: Giving a 5-year-old OTC store a makeover seniors could actually use Designer: Phaneendra Sivangula Interactive version: https://hellophaneendra.com/#/work/medicare Role: UX Designer (design lead) Timeline: 40 days Team: Head of Design, developers, internal and external stakeholders Summary: NationsOTC lets Medicare and Medicaid members spend their insurance benefits on over-the-counter health products. In 40 days, I redesigned the legacy store for members aged 55 and up, without touching its old code. Problem: A complex, dated store built on old tech, used by seniors only because nothing else let them spend their benefits. Approach: Persona-led experience audit, a new design system applied area by area, accessibility fixes and constant stakeholder feedback. Outcome: An adaptive desktop and mobile store, 3x the daily orders, and a Spot Award for the work. --- HEALTHCARE / E-COMMERCE / NB HEALTHCARE TECHNOLOGIES ## Giving a 5-year-old OTC store a makeover seniors could actually use NationsOTC lets Medicare and Medicaid members spend their insurance benefits on over-the-counter health products. In 40 days, I redesigned the legacy store for members aged 55 and up, without touching its old code. ROLE UX Designer (design lead) TIMELINE 40 days TEAM Head of Design, developers, internal and external stakeholders SCOPE 8+ experiences, 120 screens, 2 user roles +300% orders per day after launch 72% conversion, up from 44% ~4M Medicare & Medicaid members PROBLEM A complex, dated store built on old tech, used by seniors only because nothing else let them spend their benefits. APPROACH Persona-led experience audit, a new design system applied area by area, accessibility fixes and constant stakeholder feedback. OUTCOME An adaptive desktop and mobile store, 3x the daily orders, and a Spot Award for the work. 01 The brief BACKGROUND ### A store that looked like 1995 NationsOTC is a 5-year-old, highly complex product that members use to buy over-the-counter health products with their insurance benefits. Demand kept growing, but the product never changed. Siva Koneru, Head of Design, wanted to untangle it piece by piece and replace it with a modern, user-friendly experience. The first step was a new product details page. The challenge: give the old product a real makeover without major changes to its code or functionality, in about 6 weeks. MY PART ### Leading the design end to end As the UX Designer, I led the design work under Siva's guidance, handed designs off to developers and made sure there was no design-to-development gap. I also managed timelines, deliverables and schedules. - Experience audit, concept map and experience map - Interaction design and interaction notes - Visual design and prototyping 02 Research PERSONA ### Designing for members 55 and up Seniors had used the site since 2015, not because it was good, but because nothing else let them spend their benefits on OTC and food products with no out-of-pocket cost. Too much change, too fast, would overwhelm them, and everything had to be accessible. I built personas with internal and external stakeholders, then went through every button and function in the main areas asking one question: Would an older, first-time user know what this means? 6 times out of 10 the answer was no, so we changed it. 03 Design UI DESIGN ### A new design system on very old tech Just before the project, I had been building the company's first design system. The OTC store ran on old technology, with real limits: - No drop shadows - No rich interactions - No clear hierarchy - Failing accessibility standards almost everywhere Users shouldn't notice a jarring change, so I audited each area of the old product and applied the new brand and UI standards one area at a time, with multiple design versions per release for a smooth transition. Many members were visiting on phones and tablets. With no time for native apps, we built an adaptive site that follows mobile and tablet standards. ACCESSIBILITY ### Small fixes, big difference Within the timeframe, I improved accessibility wherever I could: adding icons, larger text and highlighted text fields so members always knew where they were on the page. Even the highlights were a technical nightmare and shipped a few months later. I also reviewed every button so its label was consistent and explicit. FEEDBACK & ITERATION ### Putting designs in front of real users We kept testing designs with internal and external stakeholders and iterated on what we heard. The visits showed valuable features members didn't know existed, hidden behind obscure icons. Some feedback was negative. One client preferred the old version. That helped us work out whether it was resistance to change or a real problem many users would share, and fix it early. Here is the final flow, from logging in to a product page. Benefits lead every step, and the health profile shapes what members see. 01Log in Recommended products start right at the door. 02Start a health profile Home invites members to share conditions, and shows what's trending. 03Conditions in plain words Simple buttons instead of medical forms. 04Search by benefit Results filtered by wallet and benefit balance. 05Product details Price, purchase limit and Add to Cart up front. 06Condition info and related products Clear labels, larger text and explicit buttons. 04 Outcome LAUNCH ### Three times the orders, every day +300% orders per day 72% conversion, up from 44% ~4M Medicare & Medicaid members The store launched in desktop and mobile layouts. Daily orders grew by 300%, conversion rose from 44% to 72%, and by 2022 it was serving more than 25 million people in the US. The final designs. Use the arrows or swipe. Click a screen to see it full size. 01 / 05 Log in, and get products picked for you RECOGNITION ### A Spot Award for Project OTC The work on Project OTC earned me a Spot Award (Rookie) at NB Healthcare Technologies in January 2021. Only a handful are given across the organization each year. TAKEAWAYS ### What I'd bring to the next one 1 #### Change gently. For long-time users, a gradual redesign beats a big reveal. 2 #### Clarity is accessibility. Explicit labels did as much as bigger text. 3 #### Negative feedback is data. Find out if it's habit or a real problem, then act.