The Call That Changed How I Design Software

By Hitesh Patil, UI/UX Designer at ElevatorPlus

Most elevator service software fails not because it lacks features, but because it wasn't designed around how owners, technicians, and admins actually work. This is the story of how I learned the elevator business from the ground up, found the real UX problems hiding inside it, and used a research-first design process to build ElevatorPlus - software people actually use, not software they route around.

Introduction: Why I took on ElevatorPlus

I've designed software for a handful of industries. None of them prepared me for elevators.

When I joined the ElevatorPlus project, my job title said "UI/UX Designer." What it actually meant, in practice, was closer to field researcher who happens to draw screens. I wasn't handed a feature list and asked to make it pretty. I was handed a problem: elevator service businesses were running on spreadsheets, paper job cards, and WhatsApp groups, and every CRM they'd tried before ours had been abandoned within months.

That's a hard problem to solve with a template. So I didn't start with a template. I started by asking why software that looked fine on a screen kept failing in the field.

Industry understanding: Learning a business I knew nothing about

Before I opened a design tool, I spent weeks learning how an elevator service business actually runs.

I learned that an AMC - Annual Maintenance Contract - is the heartbeat of the business. Renew it on time, and the company has predictable revenue. Miss it, and that revenue disappears quietly, without ever showing up as a clear loss anyone can point to.

I learned that a single service ticket touches three different people with three different needs: the technician who has to fix the problem, the admin who has to track the SLA, and the owner who has to know if this ticket is routine or a warning sign.

I learned that technician dispatch isn't a scheduling problem. It's a geography problem, a skill-matching problem, and a "who's already on a call" problem, all solved in the time it takes a phone to ring twice.

None of this was in a feature spec. It came from sitting with owners, riding along with technicians, and watching admins work through a real breakdown call. Understanding the business had to come before understanding the users - because in this industry, the two are the same thing.

Challenges: The UX problems I found hiding in plain sight

Once I understood the industry, the problems weren't hard to find. They were everywhere.

Technicians were designed out of the software. Every tool I looked at assumed a user sitting at a desk with two free hands and a stable connection. Real technicians work in machine rooms, stairwells, and rooftops - often with one hand on a tool and no signal until they're back in the lobby. Logging a job in six taps isn't a minor inconvenience out there. It's a reason to go back to a paper slip.

Admins were drowning in the wrong information first. During a breakdown call, an admin needs contract status, the nearest available technician, and the escalation path - instantly. Most dashboards I reviewed buried that information behind ticket history, customer notes, and other information that mattered later, not right now.

Owners couldn't see their business in one glance. Fleet-wide visibility - dozens of towers, several service areas - was scattered across sheets that had to be manually reconciled. Owners were making renewal and staffing decisions on numbers that were already a week old.

The software didn't speak the industry's language. Generic CRM terms like "leads" and "deals" don't map cleanly onto AMC renewals and service tickets. Every mismatch between the screen's vocabulary and the team's vocabulary was one more reason for the team to trust the software less.

Four problems. One root cause: the software had been built around a generic business, then relabeled for elevators.

Design process: Research, wireframes, prototypes, testing

I run every ElevatorPlus feature through the same four stages, in the same order, without skipping ahead.

Research first. Before I sketch anything, I go back to the people who'll use the screen - technicians, admins, owners - and ask what they need to know and when. This is the stage that stops me from designing a solution to a problem nobody actually has.

Wireframes second. Low-fidelity, no color, no polish. The only question a wireframe has to answer is: does the information appear in the right order? If an admin has to scroll to find contract status during a breakdown call, the wireframe has already failed, and it's cheap to fix at this stage.

Prototypes third. Once the structure holds up, I build a clickable version and hand it to real users - a technician logging a job, an admin resolving a ticket, an owner reviewing renewals. I'm not asking if it looks good. I'm asking if they can complete the task without me explaining anything.

Testing last, but never final. Every release gets tested against the same field conditions that caused the original problem - a technician on a rooftop, an admin mid-panic, an owner checking numbers between meetings. If it doesn't hold up there, it goes back to wireframes.

Research tells me what's true. Wireframes tell me if the structure works. Prototypes tell me if real people can use it. Testing tells me if it survives contact with a real workday. Skipping any one of those stages is how software ends up looking finished while still being unusable.

Design decisions: Where usability actually lives

A lot of the decisions that matter most in ElevatorPlus aren't visible as "features." They're ordering decisions.

Service tickets show contract and SLA status before ticket history, because that's the information an admin needs first during a live call.

Technician dispatch surfaces the nearest available technician before the full team roster, because during a breakdown, distance and availability matter more than a complete list.

Job logging was cut down to the fewest taps I could defend, because every extra tap is a small tax a technician pays on a rooftop with no signal — and small taxes are what push people back to paper.

Renewal tracking moved from a manual lookup to an automatic reminder that fires before a contract lapses, not after, because by the time someone notices a lapsed AMC manually, the revenue is often already gone.

None of these are dramatic redesigns. They're the difference between a screen that looks complete and a screen that actually reduces stress for the person using it under pressure.

Solutions built: Turning problems into product

Each problem I found in the challenges stage became a specific part of ElevatorPlus.

The technician-first UX problem became a field-optimized job logging flow - few taps, offline-friendly, built to sync the moment signal returns.

The admin information-order problem became a breakdown-call view that leads with contract status, nearest technician, and escalation path, in that order, every time.

The owner visibility problem became a fleet-wide dashboard that pulls AMC status, service history, and technician activity into one screen, so an owner isn't reconciling three spreadsheets to answer one question.

The vocabulary problem became a decision to build the entire product around industry-correct terms - AMC, service ticket, technician dispatch, complaint resolution SLA - instead of adapting generic CRM language after the fact.

Each solution traces back to a specific moment I watched someone struggle. That traceability is what separates a feature list from a product built for a real business.

Key learnings: What designing a niche SaaS product taught me

Designing for a niche industry taught me lessons I didn't expect.

Domain knowledge is a design skill, not a research footnote. I couldn't design a good service ticket screen until I understood what an AMC actually was. In a niche B2B product, the design and the domain are inseparable.

The best interface decisions are often invisible. Nobody praises the order information appears in. They just notice, months later, that they stopped thinking about the software altogether. That's the actual win condition.

Resistance is data. Every time a technician goes back to a paper job card, that's not a training problem - it's the interface telling you it failed a real test. I learned to treat resistance as a design signal, not a change-management problem.

Beauty and usability are not the same project. A screen can look finished and still fail the person using it under pressure. I stopped optimizing for how a screen looks in a demo and started optimizing for how it performs in a breakdown call.

Impact: What changed when the design changed

The clearest signal that the design was working wasn't a compliment. It was silence - technicians who stopped mentioning the app at all because logging a job stopped being something they had to think about.

AMC renewals that used to slip through the cracks of a spreadsheet started showing up automatically before the contract lapsed, giving owners a real chance to act instead of finding out after the revenue was already gone. Admins fielding breakdown calls stopped hunting through ticket history for contract status, because it was already the first thing on the screen. Owners stopped waiting on someone else to reconcile numbers across towers, because the fleet-wide view did that reconciling for them.

The real impact of good UX in a business like this isn't a flashier dashboard. It's fewer missed renewals, faster technician response, and a team that uses the software because it fits their day - not because they were told to.

Future vision: Where automation takes ElevatorPlus next

The next phase of ElevatorPlus isn't about adding more screens. It's about removing more friction.

Automated renewal reminders were the first step - the software noticing a deadline before a human has to. The next steps I'm designing toward are narrower and more specific: smart technician-to-ticket matching that accounts for skill and location automatically, and predictive maintenance flags built from service history, so a lift with a pattern of recurring issues gets flagged before it becomes a breakdown call.

Every one of these is scoped to a real moment of friction I've watched someone live through - not added because "AI" is expected in a product category. Automation earns its place in ElevatorPlus the same way every other design decision does: by making the software disappear a little more into the background of someone's actual workday.

Conclusion: What this project taught me about design

I came into ElevatorPlus thinking my job was to design an interface. I left understanding that my job was to design around a business I didn't know yet, for people I'd never met, doing work I'd never done.

The lesson I keep coming back to is simple: software fails when it's designed for a category instead of a person. An elevator business owner doesn't want a CRM. A technician doesn't want an app. An admin doesn't want a dashboard. They want the stress of their specific job reduced, in the specific moment it shows up.

That's still the only brief I design against.

FAQ: Designing UX for elevator service software

What does a UI/UX designer actually do when building software for a niche industry like elevator services? They start by learning the industry itself - terms like AMC, service ticket, and technician dispatch - before designing any screen. Understanding how owners, technicians, and admins actually work is what shapes the interface, not the other way around.

Why does elevator service software often fail to get adopted by technicians and admins? Adoption fails when software is built around generic CRM logic instead of real field conditions - technicians working with gloves and low signal, admins needing contract status instantly during a breakdown call. When the interface doesn't match how the job is actually done, teams quietly go back to WhatsApp and paper job cards.

What is the design process behind ElevatorPlus? ElevatorPlus follows a four-stage process: research with real users first, low-fidelity wireframes to test information order, clickable prototypes tested with technicians and admins, and field-condition testing before and after release. Each stage has to hold up before moving to the next.

How does better UX design impact an elevator service business? Well-ordered information reduces missed AMC renewals, speeds up technician dispatch during breakdowns, and gives owners real-time visibility across their fleet - turning software from a tool the team avoids into one that quietly runs the business in the background.

About the author

Hitesh Patil is a UI/UX Designer at ElevatorPlus, the Elevator Business CRM built for lift and elevator companies to run AMC renewals, service tickets, technician dispatch, and complaint resolution from one platform. His process starts on the field - learning the industry and studying how owners, technicians, and admins actually work - before a single screen gets designed.

 👉 Follow ElevatorPlus on,
Instagram LinkedIn Facebook YouTube Qoura Substack Twitter