Insights

---

Humanity-Centered-Design

Humanity-Centered-Design ist ein Ansatz, der die Perspektive im Erschaffen von Software auf eine höher angeordnete Ebene hebt. Hierbei besteht der Anspruch der Designer darin, Probleme im Kontext der Systeme, in denen sie entstehen, zu erkennen und daran zu arbeiten, den Umgang der Menschen damit zu verbessern. Dementsprechend wird der Blick von den bloßen Nutzenden der Anwendung erweitert auf die Gesamtheit der Personen, die von der Software betroffen sein können.

Dabei ist es wichtig, sich der verschiedenen Verzerrungen der eigenen Perspektive bewusst zu werden, die unter anderem durch die eigene politische, wirtschaftliche, geographische und soziale Situation maßgeblich beeinflusst wird.

Wichtige Grundsätze dieses Ansatzes sind hierbei das Fokussieren auf die Gesellschaft als Ganzes, das Erkennen von Kernproblemen, lang anhaltenden statt sofortigen Erfolgen, kontinuierlichem Verbessern und Testen sowie aktives Arbeiten mit den letztendlich Betroffenen.

Unser Projekt wird sich voraussichtlich mit Personen beschäftigen, die gewisse Einschränkungen der visuellen Wahrnehmung aufweisen. Durch den Ansatz des Humanity-Centered-Design ergibt sich dabei für uns im Speziellen, dass wir mit direkt Betroffenen der ePA und unseres Projektes arbeiten. Somit können wir die Wünsche und Bedürfnisse unserer Zielgruppe direkt im Arbeitsprozess einbinden und validieren unsere Arbeit nicht erst im Nachhinein.

Dafür möchten wir zum Beispiel Kontakt mit Blinden- oder Sehbehinderten-Verbänden aufnehmen, um mit unserer Zielgruppe in Verbindung zu treten.

---

Insights

Our project will likely deal with individuals who have certain visual perception limitations. Through the Humanity-Centered-Design approach, the following learnings arise for us:

1. Working with people affected by the ePA and our project and for this purpose, i.e. contacting associations for the blind or visually impaired

What is the challenge you would like to tackle?

The registration and activation of the ePA applications is difficult and sometimes not working at all. There are multiple steps to follow for creating an account and signing up for using the ePA. One of these steps included installing a separate app by a different company to authenticate via a government ID. If one has not went through that process before the ID will need some further configuration.

Additionally, at least one application of a major health insurance company is not working on an „old“ device with Android 8.

We are considering to use the desktop version of one specific ePA application for our project, but maybe we can find another mobile application, that we can use.

Why do you expect your engagement to be useful?
Why is that an interesting problem?

We want to create an easier process for activating the ePA. The current applications seem to be segregating non tech-savvy users. Especially elderly people could be overwhelmed by the process. This group of users can be considered as an integral part of the presumably targeted user group by ePA applications, considering Germany’s demography.

Furthermore, this segregation could be intensified by the application, which is only being able to run on the newest operating systems.

We did not find studies connecting higher age and older android versions, but the relative percentage of android users peaks in the older user groups.

Android devices generally have shorter update and maintenance coverage timespans. Therefore depending on newer OS versions for functional applications either forces users to own the newest devices or not be able to use the applications at all.

https://de.statista.com/statistik/studie/id/71707/dokument/smartphone-nutzung-in-deutschland/

Who are your intended stakeholders?
And who might be the indirect stakeholders?

Given the challenges, the stakeholders benefiting the most would be the direct users, especially with non tech-savvy backgrounds. Elderly people can be considered a significant part of this group.

Indirect stakeholders for our goals would be the people benefiting by a better acceptance of the application and a wider use. This group consists of all stakeholders with the health of users in mind like hospital staff, physicists and emergency service employees.

We do not fully know how the data of the different ePA applications is used for „science“. There could be other parties benefiting from a wider use of the applications as well, like pharmaceutical companies, that want to use the gathered data to earn more money.

Where is your user group interacting with your software?

The main user group we would like to focus on will use the software either on their mobile devices, which can be used in all locations imaginable, or on stationary computers.

When is the user group interacting with your software?

The situations for interacting with the software is the day-to-day process of having health issues. Direct users are expected to access their ePA for managing their digital receipts, documents for and from physicians and paperwork regarding health in general.

The expected time of using the applications is probably during the day, but in fact the users can try to access them anytime.

Reflexion

We did some initial individual research and gathered our findings. We then came together again for writing this blogpost and deciding on how to continue with the project.

We learned that the ePA system holds a high potential of failure or impracticality by the way it is implemented. The decentral and self-sufficient approach results in an ununiform spectrum of usability and performance of the different systems.

In addition, we read of problems with hacking at „Bitmarck“, one service provider of health insurance companies, which is at least one explanation for currently not functional service and ePA applications.

We are not quite sure about our one specific project goal and need to work on that in the future.

There are various possibilities we could concentrate on: the registration process, the availability on different operating systems and their versions or the focus on one specific user/stakeholder group and its needs or wishes.