Back to work
Case Study · PropTech NDA Protected

Society Management System (SMS)

Turning a technical society-management website into a mobile app for residents, admins and guards — and learning, along the way, that I couldn't design screens before I understood the people using them.

NDA-restricted project. The name, fonts and colours have been changed, and only partial resident screens are shown. Admin and guard screens are intentionally withheld.

Society Management System for Gulmohar Heights — cover with app screens
Role
Product Designer
Users
Resident / Tenant · Admin · Guard
Platforms
Website + Mobile app
Scope
Redesign, app design, multi-role flows
Team
2 designers, with a team lead
Timeline
Evolving scope — no fixed timeline
01In 30 seconds

The project at a glance

Context

A society management website existed, but it had no mobile app and no home screen for any user.

The hard part

Three roles, dense tables (visitor logs, a year of payments) and requirements that kept changing.

My contribution

Researched patterns, sketched, and designed website and app screens in Figma for resident, admin and guard flows.

Delivered

Final screens and a Figma file handed off to developers, after last-minute brand changes made through styles.
02The product

What is a Society Management System?

A digital tool that simplifies how residential communities manage daily tasks, communication and security — without endless WhatsApp groups and calls to the watchman.

Maintenance payment

Pay society dues online.

Raise a complaint

Log and track issues without chasing anyone.

Book a facility

Reserve the clubhouse, gym or halls in a few taps.

Track visitors

Stay updated on who's entering and leaving.

Announcements

Get updates from the society admin.

Manage residents

Keep resident details and communication organised.

03How it unfolded

Designing in a moving environment

The project wasn't linear. It moved through three phases, and the second one changed how I work.

  1. Phase 1

    Blind redesign

    Two designers, two hours, and a UI redesign of an existing SMS website — with little to no context.

  2. Phase 2

    Website → app

    I started turning the website into an app. After 2–3 screens I was doubting every decision, because I didn't know the context. How could I design without understanding the users?

  3. Phase 3

    Learn, question, iterate

    I asked the team lead questions, found problems in the design, and absorbed client changes — updating the website and app at the same time.

The moment I got stuck in Phase 2 was the most useful part of the project — it showed me I needed context before pixels.

04Process

How I worked, flow by flow

The website had no home screen for any user, so I started there with the resident. Then, for each flow (for example, paying the maintenance bill), I studied the existing website's order of actions and placement of information, looked at the same flow in competitor apps, sketched in my notebook, iterated, and only then moved into Figma.

Research, sketching and UI design looped back and forth. Once the resident was done, I repeated it for admin and guard.

Direct research

Competitor SMS apps — Township Management App, Neighbium, Adda Gatekeeper.

Indirect research

Products solving a similar problem: Zomato and Swiggy (active orders), PhonePe, Paytm and CRED (active bill payments), Myntra (filters), Google Images (receipt references).

Note

These were pattern references for my own decisions, not a formal research study.
Sketches and iterations, flow boards per role, and the overall process.
05Decision 1

Fitting a visitor log onto a phone

Problem

The website's visitor log was a wide table. It doesn't naturally fit a small mobile screen.

Exploration

Food delivery apps squeeze long order details into a card by prioritising data and arranging it in columns. Competitor SMS apps did the same.

Insight

Not everything needs to be visible at once. A PM on another project had suggested a dropdown for exactly this.
Indirect research: order cards in food delivery apps.
Direct research: visitor lists in competitor SMS apps.

Decision

Show visitor number and name first; put purpose, date, status and entry/exit times behind a dropdown.

Edge case

What if someone needs a criterion I didn't prioritise? I added search, filter and sort.

Building it as a system

I built the collapsed and expanded cards, turned them into components, prototyped them, combined them into a component set, and placed the list in vertical auto layout — so opening one card pushes the rest down instead of overlapping.

Card → component → component set.
Without vs with auto layout.
The final visitor log: prioritised cards, expandable details, search, filter and sort.
06Decision 2

A year of payments, without overwhelming the admin

The admin maintenance sheet held a year's worth of payment data per resident. Before designing, I asked one question: what would admins actually do on this screen?

Check totals
Cross-verify months
Troubleshoot specific cases

Not: scroll endlessly through every month for every resident.

Dense tablePrioritiseDisclose on demandFilters from smallest criteriaActive filter chips

Hierarchy

First view: resident/tenant name and total yearly payment — clean and scannable. Monthly detail sits in a dropdown for when it's needed.

Filtering

There were 3 filters, but admins work with many more criteria. I broke them down to the smallest units, since every real filter is a combination of those, and added filters accordingly.

The new problem

Many filters get buried — easy to miss and hard to manage. Shopping apps like Myntra solve this with chips.

Chips

Active filters appear as chips, so admins can always see what's applied and remove one with a single tap — no hidden menus.
Reference: Myntra's filter chips.
Applied: chips above a prioritised, expandable list.
07Decision 3

Sidebar or bottom navigation?

For the resident alone, either would work. The decision had to work for the whole system.

Bottom navigation

  • Fits the resident's 4–5 main flows
  • Can't hold the admin's many flows
  • Would mean different navigation per role
  • No room for future flows

Sidebar Chosen

  • Handles the number of flows across roles
  • One pattern everywhere — consistency and standards
  • Easier to extend if flows are added later
Admin and guard flows — real screens withheld under NDA.
The resident sidebar I went ahead with.
08Decision 4

Why a notification section, when there's already a bell?

Many of the app's users are senior citizens. From personal experience, I know many elders don't notice the tiny notification dot. Phone notifications get lost in a long list, or deleted by mistake.

How do we make sure important updates are actually seen?

Passive vs active

In-app notifications are passive. A banner on the home screen is active and clearly visible.

Real-world model

Like a lobby notice board or sticky notes on the fridge — important updates in one place. (Heuristic: match between system and the real world.)

Inspiration

Paytm, Zomato, PhonePe, CRED and Swiggy use entry-point banners to surface critical actions.
The question, on the home screen.
Pending tasks at first sight, like a notice board.
Pattern references from other apps.
Result: a one-stop notification hub, alongside the bell.
09Final UI

The resident app screens

Home, announcements, visitor log, maintenance sheet and the payment flow. A few details: unread notifications in a darker colour, an upload-receipt button for those who've already paid, upload and download receipt in a single flow, a snackbar confirming actions, and payment information ordered like an electricity bill.

Partial resident screens only — admin and guard screens are withheld under NDA.

Admin screens

Withheld under NDA

Guard screens

Withheld under NDA

10Real-world constraints

Change was the constant

Second-hand brief

The project came to the team lead; I learned it by asking questions.

Changing scope

Additions — and sometimes subtractions — came from the client throughout.

Two surfaces

Every change had to be made on both the website and the app.

Deadline day

Logo and colours changed at the last minute for the CEO and client — quick because everything used styles. Then the Figma file was handed off.
11Outcome

Where it landed

The website and app designs for resident, admin and guard flows were handed off to developers in Figma. I don't have usage data or test results, so I'm not claiming any — the value of this project is in the decisions above.

12Not yet done

If I had more time

These are planned improvements, not completed work.

Design for error and edge cases
Design further flows beyond the primary ones
Use variants for the different states of a button
Micro-details like next-page loading states
A more modular system
More snackbars showing the status of actions
13Reflection

What I learned

Context before screens

Phase 2 taught me that designing without knowing users and workflows produces doubt, not design.

Hierarchy is the real tool

Small screens force you to decide what matters first. Priority, then progressive disclosure.

Borrow patterns from anywhere

Food delivery, payments and shopping apps solved my problems before SMS apps did.

Components save the day

Styles and component sets made iteration — and the last-minute rebrand — fast.

Think in systems, not roles

Navigation for three user types had to be decided once, for everyone.

Happy paths aren't enough

Edge cases, and knowing when to add or remove screens, are where flows hold up or fall apart.

Want the full walkthrough?

Admin and guard flows can be discussed under NDA on request.

Request walkthroughNext: Sprout