User experience design with collaborative UX design

Mobile apps are now almost a dime a dozen. There are currently over two million apps available for download in the respective stores for both iOS and Android. Every new app therefore has to face up to this huge competition and only has a chance of being accepted by users if it meets the very highest standards.

This also means that a good app idea alone does not make a successful app. It is therefore essential to think carefully about how exactly the app should be structured, who exactly the users are and what opportunities and risks the existing market holds.

Our experience shows that a project can only be successful if the following three perspectives are adequately considered by the entire project team at every stage of development:

• User: What needs, problems and expectations does he or she have?
• Business Goals: What economic, social or environmental goals are being pursued with the application?
• Technical feasibility: How far can we go to the limit of what is technically possible and at the same time ensure stable operation for users and scalability?

We also find time and again that people often focus on specific solutions too early on in the project. However, it is essential to first precisely understand the problems and needs of the users and to develop various solutions based on this. In other words, every successful project requires a well thought-out preliminary project from which the app concept ultimately emerges.

At Bitforge, we work with a method that is very much based on collaborative UX design.

The Collaborative UX Design approach is basically nothing more than a well-stocked toolbox. We have a selection of suitable tools for each step in the preliminary project, which we carefully select before the project begins. In seven workshops (more or less, depending on the project), we work with our customers to develop our app concept step by step. This ensures that we know exactly what we are developing, how and for whom. And that before the first line of code is written.

The following four basic principles guide our actions from start to finish:

• People-centered: We see users as people with specific needs, problems and knowledge.
• Collaborative: We develop all content together with our customers.
• Hypothesis-based: We merely make assumptions and validate them with user research.
• Agile & iterative: We divide projects into small steps and work in two-week sprints.

That was all a bit abstract, so let’s move on to the concrete part.

We divide our preliminary project into the following seven steps:

The scoping workshop is first of all about sharpening the core of the assignment. We answer the following questions together:

• Problem statement: What are the problems we want to solve for whom?
• Framing: What are the framework conditions, risks and stakeholders of the solution? How do we measure our result?
• Benchmark: Who is the competition? And what do they offer?
• User research What assumptions do we make? Which ones are critical and need to be validated? How do we check the critical assumptions?

Methodologically, we often work with maps – i.e. with post-its on the wall or, in the current corona mode, with the online tool Miro.

An example: To answer the “why and wherefore” question posed above, we create a problem statement map together. This shows us which problem we want to solve, who is affected by the problem and within which boundary conditions we are operating:

After the first workshop, we set to work on our own and methodically review our (critical assumptions). We use a wide variety of methods – from a panel survey to group discussions, diaries, guided usability tests with clickable prototypes and remote tests with lookback and testflight.

With the results of the user research in hand, we sit down with our client and discuss the results. Based on the results, we define our most important personas and check which information from the problem statement map is still valid.

Only now do we move on to collecting ideas. Using different, sometimes playful approaches such as 6-3-5 or Design Studio, we create, evaluate and assess various solution ideas together.

In the concept workshop, we visualize our solution approaches for the first time. We focus in particular on user stories, user scenarios and the user journey. As there is always some confusion about these terms, here is a definition:

User Story

A user story is the formulation of a user need and always consists of the elements [Rolle], [Feature] and [Begründung]. A fictitious example of a shopping app:

“As a [registrierter User], I want to be able to use different [Wunschlisten anlegen] so that I can [meine Lieblingsprodukte schnell finde].

User scenario

A user scenario shows the context in which the app is used by our personas and describes the persona, its goals, the time at which it performs a certain action, where the interaction takes place and why it does so. In the case of our shopping app example, a user scenario could look like this:

Sven Shopper is looking for a suitable shirt for his best friend’s upcoming wedding. As he doesn’t like shopping, he wants to be able to put together a selection of shirts as easily as possible so that his girlfriend can advise him. Every time he travels to work on the train, he searches the app for fashionable bargains and stores them in watch lists sorted by color so that he can easily find them again.

User Journey

The user journey shows which steps the user goes through in order to reach their goal. In other words, we do nothing other than divide the previously created scenario into individual sub-actions. It is important to record every single interaction with the app. The user journey thus serves as a template for the app’s user interface.

In the next step, we create prototypes for the first time, which show possible solutions. These are usually clickable prototypes. We usually create these with Figma and they offer a first impression of how an app solution could look and be operated.

The prototype created is extensively tested and checked for possible conceptual weaknesses. We usually work with usability tests: we invite users into our test lab and set them one task after another. This allows us to determine where our users still have problems and where the app concept still needs to be optimized.

As the last step before the start of “real” app development, we define what our MVP should be able to do and what possible subsequent releases could look like. To do this, we prioritize features and define when they should be implemented on a roadmap. We also define KPIs that we use to measure the success of the app.

At this point, our preliminary project is complete and we begin with the actual development of the app.