Client work · Vehicle auctions
SazCars
A car-auction app connecting vehicle discovery with live bidding across Android and iOS.
Design an interface around the decisions people need to make and the work they came to do. Cloudemy develops user flows, prototypes and screen systems for mobile apps, websites and business software.
The engagement identifies which research, design and review work is needed. Existing product evidence and implementation constraints guide the decisions.
Review the users, business requirements and available product feedback. Interviews, analytics or other research can be included where suitable access and scope are agreed.
Map the information hierarchy and navigation through low-fidelity layouts. Work through the important choices and unsuccessful paths before settling the visual detail.
Develop typography, spacing and screens in Figma. Include relevant component states and responsive layouts so the interaction can be assessed alongside its appearance.
Connect the key screens for review. A prototype helps the project team discuss behaviour and identify questions; user testing can be scoped around the audience and decisions involved.
Organize components, assets and design specifications for the implementing team. Agree file access, review points and any support needed as the design is built.
A customer journey, employee tool and information website need different flows. We scope the screens, states and handover around the people using them.
Plan navigation, input, account journeys and device-related states. Android and iOS conventions, permissions and supported screen sizes need to be considered alongside the shared product direction.
Organize the offer, supporting information and enquiry or purchase journey. The responsive layout should make those tasks clear on a phone as well as a larger screen.
Tables, filters, record changes and approvals need clear priorities. Roles and permitted actions affect what the interface shows, including recovery from an unsuccessful operation.
Document typography, colour, spacing and component behaviour for consistency across related screens. The scale and deliverables of the system should fit the product and the team maintaining it.
Brand assets, typography and image treatment should support the business and remain consistent through the journey. Any separate identity or illustration work is identified in the design scope.
Review the existing structure, useful interactions and available feedback. Preserve what works and improve the flows or screens that need attention; the review should explain what is changing and why.
The design should help someone understand the next step, complete a task and recover when something goes wrong. We review hierarchy, wording and interaction together. A polished surface is useful when it supports that journey.
If the project has a measurable goal, agree a baseline and the way it will be assessed. Completion, abandonment and support questions may provide useful feedback where reliable data is available. A redesigned screen alone does not establish a revenue improvement.
Talk to a DesignerThe information and action needed at each step.
Useful validation, error and empty states.
Controls and patterns that work together.
Files and specifications the team can use.
The deliverables should suit the people reviewing and building the interface. We agree access, format and the supporting material for the engagement.
Screens, components and prototypes can be shared for review. The scope identifies file access, organization and the specifications needed by the implementing team.
Material design guidance can inform navigation, controls and adaptive layouts. The actual product still needs choices suited to its tasks, audience and device scope.
Apple’s interface guidance can inform layout, navigation and input behaviour. Flutter-led and native implementations both need review against the expected iPhone or iPad experience.
Identify the icons, imagery and other assets needed by the product. Export formats, usage notes and any separate brand or illustration work are agreed before handover.
SazCars presents vehicle information and auction participation. PocketBook handles business records and role-based employee workflows. The interface decisions follow those different tasks.
Client work · Vehicle auctions
A car-auction app connecting vehicle discovery with live bidding across Android and iOS.
Client work · Business management
Role-based product, order and employee workflows, redesigned for partners, counters and teams.
The scope may include product research, user flows, wireframes, visual screens, prototypes and component guidance. We agree the journeys, supported layouts, review stages and handover material before work starts. Existing feedback and implementation constraints help make the work more specific.
UX concerns how the journey works: information, navigation and the steps needed to complete a task. UI concerns how the interaction is presented through typography, layout, controls and states. We review them together so appearance and behaviour support the same purpose.
The proposal identifies the Figma screens, prototype, component definitions and exported assets included, along with file access and handover format. If another team is implementing the work, we discuss the specifications they need. A shared file is useful when its structure and decisions are understandable.
Yes. Start with the existing screens, important journeys and available evidence of difficulty. We can focus on those areas while preserving useful structure and visual identity. The review should explain the changes and the implementation responsibilities.
The number and complexity of journeys, interface states, responsive layouts, research and feedback cycles affect the work. We define the required deliverables before estimating effort. A single screen, a complete product and a design system are different engagements.
Tell us about the people who will use it, the work it needs to do and any systems it should connect to. We’ll discuss the scope, dependencies and next steps with you.