Design System
The design system is a kind of modular system that catalogs all visual design elements and describes how they are to be used in the implementation of the app and its possible subsequent upgrades.
As the name suggests, it is systematically structured: It starts with the basic components (tokens) of e.g. colors, font/icons, spacing and their gradations in e.g. size or shading. Together with format attributes (area, contour, roundness, …), these form standard components such as buttons and input fields, which in turn are displayed in modules such as menu bars or input masks and later in templates for entire screens. Furthermore, the design system defines rules for the responsive behavior of the layout and its components for different screen sizes, as well as rules for accessibility.
For synchronization in collaboration with the developers, we rely on a basic tech stack of Figma integrations and are ready to expand this together with handoff solutions such as Zeplin.
Discovery Workshop
We consider a workshop with you to be a valuable part of the early analysis phase. Together with you and your experts, we develop a common understanding of the initial situation and the current business idea and project goals.
We look at the problem(s) and collect as much information as possible about them in order to record them in the form of problem statements. We identify important unknowns and how we can generate the missing knowledge.
Finally, we plan the next steps, the distribution of tasks and prioritization and record the key points in the project briefing.
Expert Evaluation
In addition to user feedback, project briefing and company goals, decisions on UX/UI design are made on the basis of our expertise. This expertise is based on our many years of experience as well as generally established design psychology guidelines to which we refer, such as the ISO 9241-10 standard on dialog design, the UX heuristics according to Jakob Nielsen and Gestalt principles.
Flowcharts
The paths that a user takes within a digital product, which decisions (forks in the road) are made, are represented in flowcharts. On the one hand, the abstract representation helps us to concentrate on the essentials without being distracted by forms of visualization and, on the other hand, to iterate with little effort.
We distinguish between task flows, which describe the direct and most efficient path of a single task, while user flows show the possible paths of a feature in its entirety.
Information Architecture
The information architecture forms the basic framework of the application. Similar to the architecture of a building, a digital product is divided into different areas (entrance area, specialist departments, etc.). The structure can vary depending on the weighting of the areas or the functional design of the app. Card sorting helps us to compare different variants of the architecture by noting the respective areas or their contents on a card and then placing and grouping them accordingly.
Iterative Process
The iterative process always aims to present as many different solutions as possible as early as possible in the project and with as little effort as possible in order to then test and evaluate them from a business and usability perspective.
Depending on the problem or maturity level of the project, different methods of presenting the variants to be compared can be used, from structured descriptions to flowcharts and hand-drawn sketches, over wireframes to high-fidelity. The individual concepts are evaluated taking into account, for example, project goals, user feedback and our expert evaluation.
With this strategy, the iterative process ensures the early identification of suitable solutions and thus the usability of the later implemented project.
Market Research
We want to understand who is offering a similar product, what their users are writing about it and what features make a difference. For this purpose, quantitative comparable data as well as qualitative characteristics are collected and documented. The most interesting findings are then highlighted and incorporated into the project briefing in consultation with you.
Personas
Personas represent fictitious people in the form of a kind of profile, whose characteristics, demographic features and user behavior we derive from the findings of user research. They serve as a guide during the development process, representing the users for whom we are developing the product.
Prioritizing
Every project planning requires the prioritization of the individual work steps, which we coordinate with you depending on the topic. We use a Kanban board for a general overview of the course of the project, while we prioritize using the value vs. effort method and include an urgency factor if necessary.
Product Analysis
When we want to create something new and supplement or optimize something that already exists, we want to understand what we are dealing with.
We examine and document your existing digital product or product vision in the form of screenshots and notes on a digital whiteboard. This provides us with an overview and a basis for our initial joint communication, which we can quickly refer back to at any time as the project progresses.
Project Briefing
In the project briefing, we record the most important points about the project. We document the initial situation, the problem, the results of the user and market research, our goals and our plans for how we will achieve them.
Individual points in the briefing usually change over the course of the project due to new findings. At the very beginning, we draw up the first rough version together, which is then reviewed and updated at regular intervals, for example following a discovery workshop and as a milestone in the analysis phase.
Prototypes
Prototypes bring our designs to life and thus form the basis for usability testing. Graphical interfaces are animated in such a way that the testers can carry out individual interactions with them, similar to a fully functioning interface.
Usability Testing
The design experts constantly recognize and evaluate usability issues during the iterative process. In addition, specific usability tests are carried out at planned intervals and as early as possible in the project.
A common method for this is clickable prototypes, which are tested by potential users on the screen. We receive feedback from the testers in the form of interviews and/or questionnaires, as well as our observations during the test. Another method is so-called A/B tests, in which a vote is held between two or more solution variants.
The findings of the tests are again evaluated by us and are then incorporated into the project objectives in consultation with you, or are incorporated into the usability concept or interface design.
Use-Cases
One and the same product is often used for slightly different purposes in different contexts, which we outline in user scenarios. These cases must later be reflected in the functional scope of the product and are therefore a central component in the definition of the app. So-called edge cases describe those applications that occur rather rarely and therefore serve a niche.
The weighting given to individual application scenarios is decisive for the usage concept and the subsequent functional scope of the product. They are defined in the project briefing, but their importance and implementation can be questioned, redefined and prioritized through usage tests.
User Journey
The user journey is a mapping method in which – similar to the user flow – we outline the individual steps that users have to take to reach a certain destination (e.g. buying a ticket or applying for a public service). The focus here is less on the detailed underlying structure and more on the superficial touchpoints and their psychological effect on users, as well as possible hurdles and opportunities to improve or eliminate them.
The method helps to recognize these aspects, communicate them to all stakeholders and not lose sight of the big picture over the course of the project and when focusing on details.
User Research
Are the “end users” at the end, or are they at the beginning? The more we know about our existing or potential users and their usage behavior and usage context, the more specifically we can design according to their requirements.
To this end, we seek to talk to end users from as many different user groups as possible in the form of semi-structured interviews, context of use analyses or diary studies. In addition, online questionnaires allow us to collect an even broader range of data.
From this, we derive the most interesting findings – similar to market research – in order to be able to optimally adapt the solution to the area of application and the needs of the users.
User Roles
Most interfaces are operated by different types of users. For example, while one user group interacts with a service in a more superficial way, there may be others who require a deeper level of functionality, while administrative users have more authority or can work from a backend view of the interface. At the same time, it should be noted that admin users in particular should be able to view the app from the perspective of all roles via switching functions in order to be able to provide appropriate assistance and detect errors.
These roles are determined during the analysis phase and recorded, for example, in the form of personas for the further course of the project.
Wireframes
A wireframe serves as a preliminary, simplified model of the user interface design. We create a purely functional layout using a standardized wireframe library designed in an abstract, sketchy style.
In this wireframe, the placement, size and content of the elements are represented, while specific design details are intentionally omitted. In this way, we ensure that we focus on functionality throughout the refinement process and avoid any influence of personal design preferences during the evaluation.