Client-facing screens designed
Days of design, start to handoff
Operational modules the interface had to hold
Distinct user groups served
Twelve systems pretending to be one product.
Background. Furnished worker accommodation in Germany is an operational business, not a booking business. Providers manage property listings, occupancy, invoicing, stock, tenant support, and availability across third-party portals, in separate tools that do not speak to each other.
The platform set out to consolidate all of it: reservations, property and occupancy management, an invoice management system, inventory control, a helpdesk and ticketing system, an advertisement ticker, third-party API synchronisation, and automatic property closing across connected portals.
That is twelve operational modules. The design problem was not drawing twelve interfaces. It was making twelve systems feel like one product to four very different audiences.
One week, end to end.
The engagement ran to a single week: three days of design and two days of feedback and revision. That is the real story of this project, and it is worth being precise about how it was possible.
Patterns before screens
- Established the shared layout, table, filter, and form patterns first
- Every module reused the same primitives rather than inventing its own
- Consistency became a by-product of the method, not a review step
Decisions taken once
- Navigation model resolved before any module was drawn
- Density and hierarchy rules set for data-heavy views
- Booking, billing, and support flows mapped to one interaction grammar
Feedback built into the week
- Two days reserved for partner and client review
- Revisions scoped and closed inside the same week
- Handoff delivered without a second round of scheduling
Speed at this scale comes from resolving the system once and applying it fifteen times. It does not come from drawing faster.
UX and UI, end to end, behind a partner's brand.
VenNexis designed the client-facing interfaces for the platform, covering user experience and user interface design from first structure to developer-ready handoff. The work was delivered as a design partner to LambdaLogics, who held the client relationship and the build.
This is the agency partnership model working as intended: senior design capacity added to a partner's delivery, inside their brand, without a second vendor appearing in front of their client.
What the interface had to carry.
Booking and property
- Centralised booking and reservation management
- Property listing and occupancy management
- Nationwide inventory of furnished accommodation
- Automatic property closing across connected portals
Operations and finance
- Invoice management and financial tracking
- Inventory control for assets and supplies
- Workflow automation across manual admin tasks
- Centralised dashboard across accommodations and bookings
Service and integration
- Helpdesk and ticketing for tenant support
- Advertisement ticker for promotions and notices
- Third-party API synchronisation
- Multi-location, multi-tenant architecture support
Fifteen screens, ready to build.
The handoff covered the client-facing surface of the platform: the screens a provider, a booker, and a traveller actually touch, drawn to a consistent system so the engineering team could build without interpreting intent.
What we are not claiming.
Post-launch performance data for this platform sits with the operator and the delivery partner. We designed the interface layer and we are not in a position to measure what happened commercially afterwards, so we publish no percentage against this engagement.
What is measurable here is scope and speed: fifteen screens across a twelve-module platform, designed and revised inside one week. Where we do publish outcome numbers, as on the community sports platform, they come from targets we were set and results we can evidence.
Operational software is a clarity problem.
Platforms like this fail when every module is designed as its own product. The user does not experience twelve systems. They experience one screen at a time, and they carry the confusion between them.
Resolving the interaction grammar once, then applying it everywhere, is what let a twelve-module platform read as a single tool. It is also what made a one-week timeline realistic rather than reckless.
Have a platform with too many moving parts?
Fixed scope, fixed price, and a named senior lead in the proposal. The first call is a working diagnostic.