Our multidisciplinary expertise and a mature approach enable our customers to find optimal solutions for their specific challenges. To achieve this, we use established tools in a variety of ways to accompany them on this journey.
Our approach is based on principles borrowed from the methodologies of Design Thinking and Google Design Sprints, and creates a shoulder-to-shoulder relationship with established agile frameworks such as Scrum or Kanban. We do not follow a strict methodology, but choose tools that fit the task at hand for a responsible use of the time we are given.
Design-driven and user-centered solutions
In our understanding, digital products are digital solutions for communicative, business, societal or social problems. Such solutions range from web-based applications running in a browser, to mobile applications, to applications running on hardware designed specifically for this purpose.
We can bring our qualities especially to design-driven projects that are aimed at new or further development of a solution and are at an initial stage. We accompany our customers in strategy development, goal setting, conception and realization as an advocate of the user and thus bring in a perspective that is becoming more and more relevant for the success of digital solutions.
To address the different requirements in the individual project phases, we draw on various methods for goal-oriented and solution-oriented progress.
Typical project goals and approaches
As a rule, we work on projects that follow a specific objective. Depending on the purpose of the intended solution and the available resources, the objectives vary in maturity, scope and sustainability of the outcome.
Typical result goals that we regularly encounter in our daily work and in whose context we feel at home are prototypes, PoC, MVP and release projects.
Prototypes are used to test a specific and concrete section of a project. A small unit - for example, a complex user interaction, a critical technical implementation or a central architectural component - can be evaluated quickly and in short iterations. When a more comprehensive perspective is needed as a result, such as to fully depict a process from the user's point of view, functionally non-essential components of the prototype can be simulated.
POC – Proof of concept
"Proof-of-Concept" projects pursue the goal of testing a critical part of a project. The focus lies on entire functionalities or features. That means that the same functional and content-related requirements apply to these parts of a solution that are also applied to a productive release. On the technical level, simpler tools can be selected to achieve a testable result in a short time. As a rule, proof-of-concept results are not suitable for productive use.
MVP – Minimum viable product
The result of a "Minimum-Viable-Product" project is a product reduced to the essential technical core. The scope is defined by a strict prioritization of the minimum business requirements to fulfill the original purpose. The result must conform to all requirements for a full development - the defined scope must therefore be realized under consideration of all framework conditions (functional, technical, legal, operational). Based on the experience gained from operating an MVP under real conditions - i.e. user feedback, functional evaluations, etc. - valuable insights can be gained to evaluate the assumptions made during the project and to determine the further procedure on the way to a release candidate.
Release candidate
With each release, various aspects of a product can be made available and put into operation under productive conditions. The focus here is on bug fixes, adjustments or extensions of the range of functions. Usually, the first releases are developed on the basis of an MVP. The scope and maturity of a product increases with each release. If adjustments planned for a release are extensive and require renewed evaluation, a renewed PoC or MVP phase is often resorted to in order to illuminate only that aspect under laboratory conditions.
Typical procedures and goals, development phases, domains and disciplines
Procedure and goals
Our approach is characterized by the ability to work closely with our clients in a transparent and comprehensible step-by-step process to create value and to achieve goals. Thereby we follow a proven procedure in order to gain necessary information, creating the resources required for the next step.
Understanding the big picture
At the beginning of each mission, we need to understand the big picture, how a project is situated, and what the overall requirements are. We rely on knowledge of business goals as well as a fundamental understanding of the technical content. We deal intensively with user needs and expectations. This is how we work with our clients to find a goal, measure the value of a product, and develop objective criteria for evaluating the project.
Usage scenarios
We help our clients to derive and evaluate individual usage scenarios from the big picture. During this process, a permanent alignment with functional and business processes and goals takes place to ensure that a homogeneous product can be created which meets both the user needs and the business framework.
Project content and tools
Along the way, a clear picture of the project content and scope emerges. A goal-oriented, project-specific approach and the criteria that subsequently gain relevance can also be derived conclusively in this manner.
Thus, we gain a common understanding of appropriate ways and means, project participants and their roles. The extent of the project in terms of duration as well as the required people and their expertise also becomes tangible.
Project work
The preliminary work done enables us to proceed in a cross-domain, efficient and targeted manner in the further process. The information and knowledge gained gives everyone involved confidence, simplifies decision-making, and allows the project team to move forward confidently and collaboratively.
Development Phases
Every product development or enhancement occurs in several development phases, the results of which determine the basis for further action in the next one. These phases are completed to the extent required in each release cycle of development - for example, in each sprint. In order to achieve the goals of each phase, we use various methods to achieve the desired results transparently and quickly. The methods outlined below represent a typical approach in a common product architecture. This does not mean that we follow a rigid process with a fixed schedule. Our projects are characterized by diverse challenges and so it is important to meet the specific requirements and the respective overall picture with the most promising tools.
Discover
Research
Concept
Ideate, Define, Visualize
Refine, Prototype
Build, Integrate, Deliver
Measure, Optimize
Discover
The aim of this phase is to find out, to structure and to record the business objectives as well as the technical and functional requirements for a solution. It is equally relevant to investigate and understand the user's needs and expectations. This requires a close exchange between the specialist departments, project managers, the design team and the development team. All findings and information are relevant for all project participants, since essential decisions are made in all disciplines on this basis.
Research
During the research phase, competitive observations and initial considerations are made as to how the critical points of the challenge can be met. A deeper understanding of the users or target groups will also be created in this phase. This way, initial assumptions can already be made about the way and the scenarios in which a user will interact with the solution.
Concept
The knowledge gained up to this point is brought together in a holistic concept that makes the basic features of a solution recognizable for the first time. The first rough visualizations can already be developed in parallel to further considerations on user interaction.
Since sufficient knowledge is available to make initial technology decisions, a realization concept is also developed at the same time as a design concept. In this way, initial architectural decisions can be made and the essential technology stacks can be defined.
Ideate, Define, Visualize
In order to make the product idea tangible, the results of the conception phase are used as a foundation for idea generation, exploration and visualization of user interfaces, the first derivation of a user concept and content architecture. These results are continuously evaluated and refined with regard to their accessibility and usability with the involvement of users. In this phase, the initial technology decisions should be made, the first technical setup should be completed, and the implementations that are considered critical for the project should be tested.
Refine, Prototype
To simulate an interactive user experience, the design of the user interfaces is refined to the point where they are mature enough to be transformed into a simple prototype. This way, assumptions and decisions are evaluated in collaboration with the user community and resilient design decisions are made.
At the same time, the new or adjusted design components of the interface are specified and prepared for further implementation. In the front-end implementation, architectural decisions are put into practice and initial views and components are realized in a raw version. The implementation of the front-end application is also started on the basis of the business requirements.
In the backend, the first components are also implemented in real terms on the basis of the designed business requirements. The interfaces between the front-end and back-end are also designed and tested in the course of a technical run-through.
Build, Integrate, Deliver
During this mostly extensive phase, practically everything happens at the same time. All requirements for the current cycle are available in a reliable form. Based on that, all relevant design components are documented in detail and compiled in a design component library. Specifications are created for new components.
During development, the specific requirements are implemented, design components are mapped in the form of a pattern library, external services are integrated, tests are automated and all product components are prepared for commissioning.
Measure, Optimize
Measure, Optimize
This phase usually comes after the release of the current cycle and includes reviews, user testings and technical analysis about the current release. This provides feedback and metrics that enable adjustments to be made to the current results in the following cycle. In order to be able to make statements on a well-grounded basis, it makes sense to have already defined assumptions and metrics for various test scenarios in advance.
Domains and disciplines
User Experience Design
UX design usually deals with the migration of business goals, functional framework conditions and user needs into a product strategy and realization in order to ensure that a solution is technically correct, able to achieve the business goals as well as the economic goals and experiences a maximum user acceptance. This requires extensive conceptual and research work to make informed assumptions that serve as the basis for appropriate conclusions in further product development.
What things look like - in other words, what shape and appearance they have - is explicitly not the content of a UX design process. Rather, the result is how a product should function, which structure and form a product must assume in order to meet specific requirements.
UX research or user research focuses on identifying and structuring user needs and deriving requirements from them, which must be taken into consideration during a product development cycle.
Data and Information Architecture
In order to be able to use the information relevant in a product or feature in a technically correct way and in the interest of the user, knowledge of the data and information architecture and its meaning is required. This is the only way for a solution to represent them in a use-case-specific manner or to migrate them into the business logic.
Requirements Engineering (business, contextual and functional requirements)
Requirements engineering or requirements management is used to develop and to document the business, functional, legal and technical requirements for a product or a feature development. The resulting information about framework conditions, current goals as well as relevant constraints is essential for the entire process of the current development phase.
Interaction Design
Interaction Design (IxD) considers the general relationship between a product and its user. This involves researching and defining how and in which situations a user interacts with a solution. The knowledge gained in this way is required to determine which type of interface - e.g. a Graphical User Interface or a Conversional User Interface - offers the user the best possible interaction with the product. Physical requirements are also illuminated to ensure that a solution is as accessible as possible. If an interface should also be operable with protective gloves, this knowledge must be taken into account in the further process.
Usability Evaluation
From the moment the form of a product or feature becomes apparent, it is necessary to regularly check whether it can be used by users in a real context. The aspects of usability and user-friendliness are examined and, if possible, evaluated according to objective criteria.
Accessibility Evaluation
If there are requirements or even mandatory conditions for a product to be suitable or optimized for users with various limitations, this aspect must be taken into account from the very beginning. Existing standards such as the W3C WAI Web Content Accessibility Guidelines are used for evaluation in order to be able to apply an objective standard. Direct user feedback is also relevant here, since non-visual hurdles in operation can only be determined to a limited extent.
User Interface Design
In a UI design process, it is defined, visualized and rehearsed which form a product takes and how it is interacted with within a user interface. The focus is on creating the visual presentation of a product for the user. Functional issues are in the background, while the emotional user appeal and an independent aesthetic are the core of the process.
A product that is to achieve a high level of user acceptance must function in a first-class manner, support the user in his actions in the best possible way and provide him with an environment in which he can act without being affected by the solution. To achieve these goals, complete UX and UI processes are necessary.
Visual design is the discipline that has the greatest influence on the appearance of a product. It determines the appearance of an application in terms of shape, color and appeal, and establishes an emotional bond between the product and the user. Aesthetics, a subjectively perceived attractiveness and visual independence are the key factors for a product with a high user identification.
Interface Design
Like visual design, interface design is responsible for high user acceptance. Here, however, the focus lies less on the overall appearance and more on the design of the individual control elements and their composition into a user interface. Following the guidelines of the UX process, the already created and evaluated assumptions are transformed from an abstract concept into a concrete image.
Interactive Design
In an interactive design process, the concrete user interactions are designed and tested in relation to the user interface. Here, in comparison to interaction design, the focus does not lie on the general relationship between product and user, but on the interaction and communication between a concrete user interface and the user. This defines how UI elements provide feedback on user actions, how notifications are displayed, or how complex action scenarios are mapped.
Accessibility Design
Accessibility design ensures that the user community can use the functionalities of a product. The characteristics of the user and the situations in which a product is used play just as important a role as the characteristics and design of the product itself. The devices by means of which the product is interacted with and their specific characteristics also influence the design of a product in terms of accessibility.
Design Component Separation
To ensure the reusability of the elaborated design and interaction elements, we follow a component paradigm. This means that a given UI element always represents the same interactive and informal function. In this way, components can be defined based on the semantics of the elements, which implement consistent behavior and appearance. These elements, in turn, are used to build the individual user interfaces. The task of Design Component Separation is to distinguish the elements from each other, to find relationships and to decide which components make up a component.
Component Library Creation
Once you have a collection of design components that are used in more than one context and by one designer, you create a central library that aggregates all components, changes versioning, and is generally available and distributed. This ensures that the team in a design process can rely on the same resources. Updates to the library can be used directly and are automatically incorporated into the design documents.
Design Guidelines
To ensure that the design resources are used correctly and are not interpreted differently by different team members, guidelines are defined for handling the resources and the general concept. These serve both to make the basic considerations comprehensible and to provide assistance for further development in the concrete application. Often, design handoffs are created in tandem, which look at the design components from the perspective of a front-end developer.
Frontend Engineering
A frontend is the technical part of a digital product that is visible to the user. As a rule, it is the programmatic realization of a user interface with the help of various, usually device-specific technologies. Thus, applications are implemented for operation in the browser or on a native platform and for different device types under specific framework conditions in each case.
The results of a UI design process flow directly into this. In doing so, these domains support each other in order to benefit from a consistent transfer of knowledge and resources. We use special tools and process patterns to ensure that UI design and front-end implementation emerge in a common flow and smoothly lead to rapid and resilient results that can be iterated over in short cycles.
The general frontend architecture defines at a high level which components exist within the frontend implementation and which tasks they perform. Both business and technical demarcation criteria can be defined. A clear architectural separation makes it easier to deal with dependencies and to work with several developers in one project.
Technology Selection and Setup
Once the basic architecture has been defined, the technologies suitable for implementation are selected on the basis of the business and technical requirements and the product concept. In order to be able to start the development quickly, the required infrastructure and services - e.g. version control systems, basic setup, continuous integration, delivery and deployment - are set up and configured. A development environment and the tools it contains for quality assurance are also defined and made available to all those involved.
Frontend UI Component Development
Based on the interface design specifications, the required design components are implemented in the form of frontend components. Thus, a seamless transition from design resources to frontend resources takes place. The frontend components obtained in this way are often kept in the form of a pattern library and distributed across all relevant components - such as various micro frontends - of the product. This ensures maximum reuse and consistency in user interaction.
Frontend Application Development
In order to map the business and technical integration in the frontend, one or more frontend applications are usually required, which implement the business logic together with a backend. The applications consume the frontend UI components to compose the required views and to present them.
Test Development
To produce releases with as few errors as possible, the respective versions of the frontend UI components and the frontend applications are tested. Usually, this is done automatically in the course of a Continuous Integration scenario. In most cases, both unit tests and end-to-end tests are used.
Backend Integration
In order to integrate a frontend application into the overall product, it must be ensured that the frontend implementation and backend systems can communicate via interfaces. This usually involves the use of standardized protocols such as RESTful JSON or GraphQL. Authentication and authorization are also relevant aspects of back-end integration.
Service Integration
If third-party services such as geo-referencing or tracking solutions are required to map a functionality, they should also be integrated at an early stage to ensure that they can provide the relevant functions that comply with the business and technical framework and are subordinate to the chosen architecture.
Operations Priming, CI/CD
In order to bring a frontend application into an operational state, various adjustments are often necessary. These are mostly optimizations in terms of runtime performance and operational reliability. In order to be able to distribute releases in an error-free and controllable manner, continuous delivery or continuous deployment mechanisms are usually implemented. In this way, each release or version can be published automatically or manually without additional effort.
Backend Engineering
In general, the back end is where the main part of a product's business logic is implemented on the basis of the overall product architecture and the defined business requirements. This is the purely technical part, which remains invisible to the user. The front end and back end usually communicate via interfaces, so-called APIs (Application Programming Interfaces), which are provided by the back end and consumed by the front end.
The topics of access control, rights management, data storage and integration of other services are also usually located in the back end and are implemented here.
The general backend architecture defines at a high level which components exist within the backend system, which tasks they perform and how they are distributed. Both business and technical demarcation criteria can be defined. Clear architectural separation makes it easier to deal with dependencies and to work with multiple developers on a single project. The integration of further services - e.g. single sign-on services, connection to third-party systems - must also be taken into account.
Technology Selection and Setup
The choice of suitable technologies is usually made as part of the architectural considerations. Not only considerations of meeting requirements, but also operational requirements play an essential role. When distributed system components are required or dictated by the architecture, the integration of the various system fragments must be considered and rehearsed. All components are set up, deployed on representative infrastructure and the functionality is tested.
Backend Application Development
Backend implementation often involves the use of various - even very specialized - technologies to map the various aspects of a product. Implementing business logic across multiple technologies and systems requires an extremely structured and planned approach.
API-Design and Development
In order to make the services of a backend accessible to the frontend, but also to other consumers, the backend must expose one or more structured, documented and understandable interfaces. By means of these API implementations, data can be obtained or made accessible, processes can be triggered, or procedures can be executed. The way in which an API is executed and the concept it follows have a significant influence on how complicated its integration is.
Service Integration
If extended functionalities or information from third-party systems are required, these are usually connected to the back end via interfaces. In the process, the third-party systems expose an interface that is consumed by the back end. This means that the backend may have to implement different API protocols and paradigms as a client.
Test Development
In order to produce low-defect releases, the respective versions of the backend components are intensively tested. This is usually done automatically in the course of a continuous integration scenario. Depending on the technology and project character, various test strategies are used - from unit tests to integration and regression tests to API tests.
Operations Priming, CI/CD
Complex building and deploying processes are often necessary to bring a backend application consisting of several components into a ready-to-use state and to distribute it into production. In order to be able to distribute releases in a controllable and automated manner, continuous delivery or continuous deployment mechanisms are usually implemented.
Select a phase or method for further details …
Find out if we can successfully design your project together.