Approvals and collaboration
A task shows who is responsible, what is complete and which step comes next. Roles and approvals connect the app with the way the organization works.
Design focusRoles · Approvals · Interfaces
MULTI-PLATFORM APP DEVELOPMENT · BERLIN
Science.Adapted toDigital.
One product. Every platform.
We connect web, iOS, Android and desktop through shared product logic and an experience designed for each device.
WEB / iOS / ANDROID / DESKTOPDIGITAL SCIENCE
ONE PRODUCT ACROSS DEVICESPeople switch devices.
People switch devices.
Their work continues.
Plan in the office. Document on site. Review on desktop. We design the handovers too: the task remains clear, access is defined and its current state is visible. Each platform provides the views and input methods its context calls for.
SHARED RULESCONTEXTUAL INTERACTIONCLEAR DATA FLOWS
TYPICAL USE CASES
For teams, customers and work on location.
Apps connect people with a task and the information it needs. We design that connection for different contexts and existing systems.
Access to information and services
People find their tasks and continue them on the right device. Sign-in, clear state and access to the required information form one connected flow.
Design focusAccess · Tasks · Device changes
Document and continue later
Brief sessions, a camera and changing connectivity shape the design. We establish which data must be available on site and how saved edits are transferred later.
Design focusTouch · Offline · Synchronization
THE PRODUCT IN CONTEXTThe same task.
The same task.
Four considered views.
A site inspection connects office planning with fieldwork. This design study shows how planning, documentation and review can work across devices. Choose a platform.
DESIGN STUDY
Concept study · fictional data.
Illustrating how a product adapts to each platform.
WEB
Plan and assign.
The web view brings together open tasks, responsibilities and the next step. It focuses on overview and collaboration.
- Context
- Team planning
- Interaction
- Mouse and keyboard
WEBFICTIONAL PRODUCT DESIGN
Site inspection
North site
StatusASSIGNED TOIn progressInspection team
Next step
Document accessDocumented
Check equipmentIn progress
Add a note
SHARED PRODUCT STATESite inspection / North site
iOS
Document on location.
A focused flow guides the inspection. Device cameras and appropriate permissions are considered where the task needs them.
- Context
- A short flow on location
- Interaction
- Touch and device camera
iOSFICTIONAL PRODUCT DESIGN
Site inspection
North site
Document accessDocumented
Check equipmentIn progress
Add a note
SHARED PRODUCT STATESite inspection / North site
ANDROID
Work without a connection.
Local editing and a clear transfer state make interrupted journeys understandable. Synchronization and conflict rules are planned for the individual project.
- Context
- Changing connectivity
- Decision
- Local draft and transfer
ANDROIDFICTIONAL PRODUCT DESIGN
Site inspection
North site
Document accessDocumented
Check equipmentIn progress
Add a note
LOCAL DRAFTTransfer pending
DESKTOP
Review and follow through.
Keyboard input and a split workspace help compare results, notes and follow-up questions.
- Context
- Review at a workstation
- Interaction
- Keyboard and split view
DESKTOPFICTIONAL PRODUCT DESIGN
Site inspection
North site
Document accessDocumented
Check equipmentIn progress
Add a note
SHARED PRODUCT STATESite inspection / North site
A considered starting point
Start where the work happens.
The first platform follows the task. We compare access, device functions and daily use before defining the initial release.
- Web
Reach people through a browser
Useful for portals, team planning and access without an app installation.
- iOS / Android
Support work on the move
Relevant when touch, camera, notifications or work with intermittent connectivity shape the task.
- Desktop
Make room for concentrated work
Useful for extensive input, several windows and integration with the workplace.
Shared product logic keeps later platforms connected. An offline mode or device integration is designed and scoped for the specific project.
THE ENGINEERING BEHIND IT
One core connects the views.
An approval process should follow the same rules on every device. Its screens can differ. We separate business rules, data and interaction, then determine which components the platforms should share.
WebiOSAndroidDesktop
SHARED PRODUCT CORERules · Data · State
Defined interfacesExisting systems & services
Schematic architecture principle. Actual system boundaries and shared components are defined for the project.
Product rules
Who can edit what? When is a task complete? Roles, approvals and states form a clear model across every platform.
Platforms
Touch on site, a keyboard at the desk, a camera when it helps. Navigation and device capabilities follow the actual tasks.
Interfaces
Business systems exchange data through defined contracts. Failure cases, access rights and version changes have clear owners.
Quality
Relevant devices, accessible interaction, failure cases and release paths become reviewable criteria. The project scope defines the checks.
RESULTS YOU CAN BUILD ON
A product your team can carry forward.
Decisions, work in progress and responsibilities remain understandable. Your team can review, take ownership of and develop the product further. The proposal defines the actual deliverables.
A clear product model
Target users, key tasks, priority platforms and an initial scope. This makes the first release and possible later stages explicit.
Reasoned architecture
Documented decisions about data, interfaces and shared components. Technical limits and dependencies remain understandable.
Reviewable development
Intermediate versions and agreed acceptance criteria. Relevant use cases and failure scenarios inform the checks.
An organized handover
Source code, documentation, accounts and responsibilities are handed over within the agreed scope. Maintenance and updates have a defined framework.
WORKING TOGETHER
From the first discussion to handover.
First, we clarify the task. Then we investigate the assumptions the implementation depends on. Each step provides a basis for the next decision.
- 01
Clarify the product
We establish who uses the app, which task it supports and which systems already exist. This gives platforms and features a reasoned order.
- 02
Investigate risks early
User journeys, prototypes and technical checks help examine critical assumptions. Interfaces, offline needs and security boundaries are considered before larger implementation steps.
- 03
Develop in steps
We implement agreed features, discuss intermediate versions and check them against concrete criteria. Findings inform the next decisions.
- 04
Release and hand over
Release paths, store accounts, approvals and responsibility for operation are clarified. Further development, maintenance and updates are agreed separately.
DIGITAL SCIENCE
Turn assumptions into reasoned decisions.
Which task costs people time? Which information is missing? Which technical constraint matters? Digital Science connects those questions with product research, data models and software development. Prototypes and focused investigations provide evidence for the next step.
- Observe tasks and make assumptions explicit.
- Examine the origin, meaning and quality of data.
- Define limits and human oversight for AI and automation.
- 01Question
What needs to continue when switching devices?
- 02Hypothesis
One shared task avoids duplicate input.
- 03Investigation
A prototype reveals unclear transitions.
- 04Decision
Refine state and feedback with a clear purpose.
↶ The findings inform the next question.
GOOD QUESTIONS TO START WITH
The questions behind a well-planned app.
01When does multi-platform development make sense?+
When several user groups or contexts need the same product rules and data. Shared components can make ongoing development easier. Whether they are economical depends on device capabilities, platform differences and maintenance needs, among other factors.
02Do all platforms need to launch together?+
No. We first consider where the product offers concrete value. An initial release may focus on one platform. The architecture considers later stages where they can already be anticipated.
03Can you work with existing apps and systems?+
Existing products can be a starting point. We first clarify source code, interfaces, rights and technical dependencies. We can then decide which parts to keep, adapt or replace in stages.
04How do you choose technology and frameworks?+
From user journeys, device capabilities, performance, team and operation. We compare possible approaches and explain key trade-offs. You do not need to have chosen a framework before an initial discussion.
05How are security and privacy considered?+
We examine access rights, data flows, storage locations and relevant failure scenarios in the design. Specific safeguards, legal requirements and checks are defined for the individual project.
06What determines effort and schedule?+
Primarily scope, platforms, interfaces, data migration, quality requirements and external approvals. A useful proposal needs a defined scope and named dependencies. Approval by independent app stores cannot be guaranteed.
07What happens after publication?+
Operating systems and connected systems continue to change. Responsibilities for operation, updates, fixes and extensions are therefore explicitly agreed. They are not automatically included in every development contract.
08How does the collaboration start?+
With an email to mail@deepburg.com. Describe the goal, future users and existing systems. A complete specification is not required. Credentials and other confidential information should not be included in the initial enquiry.
THE NEXT STEP
Which workflow should your app improve?
Describe the workflow, the people behind it and the change you want to achieve. Existing systems and open questions help us define a useful first development step.
Discuss your idea by emailNo form. No tracking. No embedded third parties.Four useful details for your first email
- Task
- Which workflow should become easier?
- People
- Who uses the app and in which situation?
- Systems
- What exists already, and what needs connecting?
- Scope
- Which platforms, dates or constraints are known?