Internal Product · 0 → 1 ConceptUX / UI · Product DesignMobile-First B2B ToolService Design
RAKAZ OPERATIONS
A maintenance-operations app concept for a Berlin property management company, designed alongside middle management to replace the phone calls and chat messages with one accountable ticket loop.
Client confidential · Berlin, Germany · Names and identifying details withheld
4
User roles served — tenant, ops manager, field team, external contractor
13
Steps mapped in the issue-to-resolution loop, report to confirmed close
6
Core system modules structured from one sprawling mind map
1
Source of truth — every issue, photo, and status in a single record
// 01// The ChallengeBefore The App
MAINTENANCE RAN ON PHONE CALLS AND MEMORY
Every repair, inspection, and tenant complaint travelled by phone call and chat message, and none of it was written down anywhere both sides could see.
The company manages residential properties across Berlin with a mix of in-house field teams and external contractors. When something broke, a tenant called someone, anyone. That person called someone else. The job got done, or half-done, or forgotten.
The maintenance manager sat in the middle of it all with no way to answer the two questions that mattered: who took care of it, and was it actually done? There were no photos of the issue or the fix, and no record to check weeks later when the same unit complained again.
Meanwhile tenants waited. When a technician ran late or never showed, nobody told them, and they felt ignored by a company they pay rent to. Those calls escalated, and they all landed on middle management.
Before-state illustration — calls, chats & sticky notes
Before-state illustration — calls, chats & sticky notes
DetailThe communication mess this concept replaced.
// 02// The Business ProblemRoot Cause
THREE FAILURES, ONE ROOT CAUSE
DIRECTION 01
No Accountability
Impact
With work assigned verbally, the manager couldn’t see who owned an issue, when it started, or when it was due. Follow-up meant calling around and reconstructing the story person by person.
Impact
Jobs were closed on someone’s word. Without before-and-after photos there was no way to verify quality, and half-done repairs surfaced weeks later as new complaints from the same unit.
DIRECTION 03
Tenants In The Dark
Impact
Late or rescheduled visits went uncommunicated. Tenants who felt ignored escalated by phone, straight to management, turning small repairs into customer-satisfaction problems.
Every failure traced back to the same gap: no shared record.
// 03// Framing The ProblemHow Might We
How might we give every issue one home, visible to the tenant, the field team, and management, from first report through to a fix the tenant confirms?
// 04// DiscoveryMapped With The People In It
MAPPING THE OPERATION WITH THE PEOPLE RUNNING IT
I worked directly with middle management, the people stuck in the bottleneck, and mapped every actor, message path, and handover before drawing a single screen.
We ran working sessions around one growing mind map: who reports, who assigns, who fixes, who checks, who talks to the tenant. Departments were circles, actions were arrows, and colour carried the split: black for what the system should automate, purple for what a human has to decide.
That split turned out to be the product. Almost none of the chaos was judgment work. It was routing, reminding, and record-keeping, all of which software can take, leaving people the decisions that need them.
rakaz / stakeholder mind map
DetailThe original working mind map — departments as circles, records as files, black arrows for automation, coloured arrows for human action.
discovery / pain-point affinity map
discovery / pain-point affinity map
DetailStakeholder session notes, clustered into recurring pain points.
discovery / current-state journey
discovery / current-state journey
DetailA ticket's life by phone — the current-state journey the app replaced.
// 05// Who The System ServesFour Roles
FOUR ROLES, FOUR VERY DIFFERENT JOBS
Each role needs a different slice of the same record. Four views, one source.
Needs
Report an issue in seconds, know it was received, get told when it’s fixed.
Needs
One prioritised queue, SLA countdowns, and the single decision only a human should make: who does the work.
Needs
Job details, photos, and a fast way to capture before/after evidence on mobile.
ROLE 04
External Contractor
Needs
Just enough access to do the job — nothing about other tenants or units.
DetailSystem data model — asset-centric, with a single API layer feeding every role's view.
// 06// The Core LoopReport → Confirmed Fix
FROM COMPLAINT TO CONFIRMED FIX — WITHOUT A PHONE CALL
One flow carries every issue through three swimlanes (tenant, manager, technician), and nothing closes until the tenant says so.
DetailThe decision flow — tenant reporting, manager triage & dispatch, technician execution & closing, all writing to one central record.
Actor
Tenant · automated triage
What happens
The tenant picks a category, describes the issue, and attaches photos — the unit is pre-filled from their profile. The system creates the issue record and auto-flags urgency from keywords like "no heat" or "flooding", pushing critical issues straight to on-call staff.
PHASE 02
Triage & Dispatch
What happens
Issues land in one prioritised queue with SLA countdowns. The manager makes the one decision only a human can: internal handyman or external contractor, weighed against staff availability, skill tags, and cost. One tap creates the work order.
PHASE 03
Execute & Document
Actor
Field team / contractor
What happens
The worker gets full job details on mobile — address, tenant photos, priority, due date. On site they capture before, during, and after photos, flag blockers, and update status. Every update streams live to the management dashboard.
What happens
Ops reviews before/after photos side by side and approves or rejects. Then the tenant gets the final question: "Was this resolved to your satisfaction?" Yes closes the issue with a full audit trail. No sends it back to reassignment, not back to re-reporting.
// 07// Key Design DecisionsWhere The Thinking Lives
WHERE THE THINKING LIVES
DECISION 01
Photo evidence is mandatory, not optional
Problem
Jobs were closed on trust — half-done work resurfaced as repeat complaints.
Solution
Before/after capture built into the field flow; verification screen shows both side by side.
Why it matters
Quality is checkable in seconds by someone who was never on site.
DECISION 02
Automate routing, keep judgment human
Problem
Managers spent their day forwarding messages, not making decisions.
Solution
Urgency detection, task creation, notifications, and history are automatic. Humans only decide priority overrides and who does the work.
Why it matters
The bottleneck role shrinks to the two decisions that genuinely need a person.
DECISION 03
Automated decisions are badges, not screens
Problem
Flowchart diamonds tempt you into a screen per decision, which bloats the app.
Solution
System decisions (urgent? complete?) surface as status badges on existing screens; human decisions are buttons inside the issue detail.
Why it matters
Fewer screens, and the UI stays honest about who decided what.
DECISION 04
The tenant closes the ticket, not the staff
Problem
"Done" meant done for the worker, not for the person living with the problem.
Solution
Resolution requires tenant confirmation with optional rating; a "No" auto-reopens and routes to reassignment.
Why it matters
Satisfaction becomes a recorded step in every job rather than a guess.
DECISION 05
A human fallback is part of the design
Problem
Tenants felt ignored when visits slipped and nobody told them.
Solution
Delay and blocker states trigger tenant notifications, and flag the cases where a personal call from the company is the right move.
Why it matters
The app reduces calls without removing the human touch that keeps tenants loyal.
DECISION 06
Contractors get a keyhole, not a key
Problem
External vendors need job info but must never see tenant data or other units.
Solution
A limited-permission contractor view: job details, status update, photo upload — nothing else.
Why it matters
Privacy by design, which the German rental market expects.
// 08// Design LanguagePalette & Type
BUILT TO BE READ IN A STAIRWELL
A tool used in stairwells and basements needs calm surfaces, big touch targets, and status you can read in bad light.
Core Palette — Architectural Stability
Primary Sage
#345443
Primary Container
#4C6C5A
On-Primary Tint
#C8ECD5
Surface Base
#E6EFEA
Urgent
#D9534F
Priority
#E67E22
Hanken Grotesk carries headlines and numbers; Inter handles body copy, labels, and dense list UI. Status is carried by low-saturation chip backgrounds with high-saturation text, so urgency reads instantly without the interface shouting.
// 09// The ProductMid-Fidelity Screens
ONE RECORD, FOUR VIEWS
Mid-weight concept screens built to pressure-test the flows with management. Real enough to argue about, cheap enough to bin.
DetailThe morning answer to "what's on fire?" Active tickets, critical count, and occupancy up top; the priority queue below with urgency badges and one-tap Assign.
DetailEvery task owns its status, owner, and deadline. Open, in progress, blocked, needs approval — the states from the swimlane flow made visible.
DetailThe asset file, the system's centre of gravity. Each property carries its status, current tenant, open issues, and last inspection.
DetailLease status and open issues per person.
DetailIssue trends, SLA compliance, staff workload.
DetailThe limited-permission outside view.
// 10// Beyond MobileBack Office
A desktop view for the back office.
Field work is mobile-first, but triage and oversight happen at a desk.
A companion dashboard mirrors the same live record: KPIs, maintenance requests, and financial context in one view, refreshing as field updates come in. It's deliberately a read-only mirror, never a gate the flow has to pass through.
rakaz / desktop dashboard
DetailDesktop dashboard direction — portfolio KPIs with a live maintenance-request feed.
// 11// Where It Landed
PAUSED BEFORE PRODUCTION, BUT THE THINKING SHIPPED
The project stopped early, before development began. What it left behind was something the company never had: a shared, structured picture of how their own operation works.
The mind map, role definitions, the 13-step resolution flow, and the mid-fi screens turned "we need an app" into a build-ready specification: modules, data relationships, automation rules, and permission boundaries a development team could pick up on day one.
Just as valuable: the discovery sessions gave middle management a vocabulary for the problem. "No shared record" became the phrase they used to explain the bottleneck upward, and that definition survives even if this particular product doesn't.
// 12// If The Project ResumedValidation Plan
THE VALIDATION PLAN
STEP 01
Pilot in one building
Plan
Run the full loop on a single property with real tenants and one field team before scaling anything.
STEP 02
Test the tenant flow with actual tenants
Plan
The concept was built with management — the reporting and confirmation screens need validation from the other side of the door.
STEP 03
Measure the two numbers that started this
Plan
Time from report to confirmed fix, and repeat complaints per unit — the honest test of whether evidence-based closing works.
STEP 04
German-first localisation
Plan
Berlin tenants report issues in German; the tenant-facing surface has to be native-language from the pilot, not after it.
// 13// ReflectionWhat This Taught Me
The Honest Column
01
The best interface for a broken process is a shared record, not a prettier inbox.
02
Deciding what to automate is a design decision. The colour coding in a mind map became the product’s architecture.
03
Letting the customer close the ticket changes who the system is accountable to.
04
A project that pauses can still be worth it, if the organisation understands itself better afterwards.
A SHARED RECORD BEATS A PRETTIER INBOX.
Check out another project
