Design & User Experience

Design interfaces and digital products with OTOKO®: turn your requirements into clear user journeys and a consistent experience.

Customers want to complete their requests, field teams need information on site and business units need a reliable overview.

Clickable prototype and user testing with the business unit or customers before development Web frontend with React, Next.js or Vue, accessibility under WCAG 2.2 Mobile apps with React Native or natively in Kotlin and Swift, including publication in the stores Sign-in via OpenID Connect, session protection and certificate pinning under OWASP MASVS Offline capability, push notifications and telemetry with consent under GDPR

Published app and web application with source code Design system and accessibility report Security assessment report under OWASP MASVS

User groups and key tasks Existing login and role model Required devices and offline scenarios

A partner portal replaces email requests. Partners see only their own cases, upload documents and receive follow-up questions within the process. Internal processing uses the same data but different roles and approvals.

React Next.js Vue React Native Kotlin Swift

A portal is helpful when users reach their goal without detours. We design complete workflows for sign-in, data entry, upload, follow-up questions and status tracking. Error cases belong in the concept: expired sessions, incomplete documents or an interrupted connection must not lead to the loss of work already entered. Clickable prototypes make these workflows testable before implementation. Feedback from the business unit and the user group flows into navigation, forms and understandable feedback messages. A shared component system ensures that new features use the same interaction logic.

The choice follows the use case. A browser-based portal offers easy access without installation. A progressive web app can be sufficient for certain mobile workflows; native or cross-platform apps become relevant when device interfaces, background processing or offline requirements call for them. We test the required capabilities on real devices. Offline data needs rules for local storage, synchronization and conflicts. In a field service app, for example, it must be clear which change takes precedence when two people work on the same case. These questions affect the backend and permissions just as much as the user interface.

Keyboard operation, recognizable focus states, understandable error messages and scalable fonts are part of the interface work. We agree with you on the required test scope for accessibility. A visual design or an automated scan alone is not complete evidence of accessibility. We check access server-side for every role and every action. File uploads, sessions and data sharing each get their own protective measures. For the rollout, we plan test devices, app store approvals where applicable, support channels and introducing the application to your users.

A customer account consists of more than a single login. Invitations, changes of organization, lost access, delegations and employees leaving must fit into the permission model. We clarify who is allowed to approve new users and which steps require renewed confirmation. Centrally managed identities can be connected; the business decision on a specific order still rests with the portal. For application processes and uploads, we look at the entire path through to internal processing. File size, permitted content, quarantine and approval are planned, as are understandable status messages. A successful upload does not yet mean that a document has been checked or accepted. Drafts, automatic saving and continuing on another device need clear rules on visibility. Sensitive information should not appear by accident in notifications, URLs or diagnostic messages.

A mobile application used in a warehouse or in the field cannot assume a permanently stable connection. We distinguish readable offline data from changes captured locally and define how long they remain valid. Large data sets are not copied to every device indiscriminately. User permissions, device storage and how to handle a lost device all feed into the concept. By the time a connection is reestablished, the same record may already have changed on the server. A blanket rule of “last change wins” is unsuitable for many business processes. We define which fields can be merged automatically and which conflicts require a decision. Pending transmissions stay visible to users. Testing covers connection drops during sending, multiple retries, expired sessions and permission changes between capture and synchronization.

A portal is not used only on a large development monitor. Long names, translations, enlarged fonts, on-screen keyboards and slow devices all change the layout. We therefore test complete tasks on relevant devices and with different input methods. Error messages explain what needs to be corrected and lead to the right place. A form must not lose its entries just because the login needs to be renewed. For the introduction, we plan a limited group of users, available support and feedback from real workflows. With mobile apps, older versions can remain installed; the backend must account for the agreed transition period. Usage measurements should answer concrete improvement questions, for example at which point a case is abandoned. Which measurements may be used and what information they require is clarified before implementation.

Application landscape, requirements, risks Business unit, IT, information security, OTOKO® Software Architect Assessed initiatives, inventory, security and operations requirements

Architecture, technology, operating model Business unit, architecture, data protection, information security Target architecture, threat model, test strategy, operating model, milestones