Data Checkout Process: Designing a Standardized Data Request via Idento.one

1
Usable Security
How to design a data checkout process via the third party
idento.one?
Frances Antwi-Donkor, 1590827
Jannik Schütte, 1216831
Leonie Griesenbeck, 1526972
Sören Steinhanses, 1277542
31.03.2021
Lecturer:
Prof. Dr. Gunnar Stevens, Fatemeh Alizadeh & Timo Jakobi
Orgnisational Unit:
Wirtschaftsinformatik / Datenschutz und IT-Sicherheit

2
Inhalt
Course introduction................................................................................................................................. 3
Idento.one............................................................................................................................................... 4
Methodology and Tools........................................................................................................................... 5
Basic idea................................................................................................................................................. 5
Personas, Scenario and “How might we” - Questions ............................................................................ 5
Design phase ........................................................................................................................................... 7
Designing the process (Company side) ............................................................................................... 7
Designing the mockups (Company side) ............................................................................................. 8
Designing the process and mockups (Customer side)......................................................................... 9
Expert interview .................................................................................................................................... 10
General information.......................................................................................................................... 10
Showing the designs.......................................................................................................................... 11
Feedback about the whole process................................................................................................... 13
Reflection and prospective.................................................................................................................... 14
Literature............................................................................................................................................... 16
List of figures ......................................................................................................................................... 16

3
Course introduction
The course started with reading, summarizing, and discussing papers concerning the General
Data Protection Regulation (GDPR) and important privacy phenomena like Awareness or the
Privacy Paradox. Simultaneously the students had the task to do data checkouts at different
services in use.
Our group did the checkouts on different platforms, from social networks to online shops to
"personal" services. The experiences varied significantly between the different checkouts.
Some felt very complicated, while others worked out very easily.
The social media platforms where we requested our data were Facebook, Instagram,
Whatsapp, and Snapchat. As they are all owned by Facebook, the process of the checkouts
was pretty similar. The only problem we faced was that the button to request the data could
not be found easily. This was the same issue with Google, Amazon, and Spotify. However,
these all the platforms already mentioned, had in common the format in which the data was
provided. This was done digitally and done on time. The results either were downloadable as
zip files containing JSON-, CSV- or PDF-files, or they could be viewed in the app/browser
directly, which was a more convenient way.
Besides the already named companies, we did the checkout at HelloFresh, AllesRahmen,
Check24, Futbin, MMoga, About you, Adidas, Skype, Udacity, Dazn, Adobe, Paypal, Payback
and Apple. Furthermore, we requested our data from a College and a Hospital.
Some of these companies answered with follow-up-questions, either for further authentication
or to understand what we want, because they were not that familiar with the right of information.
One service provider even requested a picture of the requester with his ID-Card, which would
have given the service provider even more data than necessary. Another service just replied
that they did not collect any personal data.
Most companies provided personal data similar to the social media companies: As PDF, CSV
or JSON. Surprisingly, Check24 and About you sent the requested data in hardcopy. This
contained many papers and was difficult to read through everything. The response of the
different companies to our checkout requests was between 2 hours and a month.
To sum up, there are multiple ways to do the checkout and to access the data. The data formats
also vary, some in hardcopy whilst others were softcopy. We had difficulties finding the right
person/email to contact. Another problem we identified were follow-up questions regarding
either authentication or explaining the whole process to the company we were requesting data

4
from. That leads to the conclusion, that a standardization of the checkout process would be
valuable but also that it can be challenging.
Following our investigation into how data is requested, the students had to decide on a specific
problem and try to design a solution for it. Our group worked for idento.one, who’s vision -
beyond others - is to standardize the checkout process by handling the requests as a third-
party.
Idento.one
Idento.one is a platform that wants to assist its clients in managing their personal data in a
secure place on the internet, where the mentioned data is protected from theft. Idento.one acts
as a medium between clients and companies.
Idento.one offers both, users and companies, a secure cloud service where users can easily
store and manage their received data, whilst companies can upload data requested by their
clients.
At the start of our project, we identified our potential tasks. These tasks were:
1. Identification of the users
2. The process involved in choosing a company to request data from
3. The process of the request
4. How to upload the data the company - generates
5. How users can efficiently access the data
As the identification was already elaborated by idento.one, we decided to develop tasks two
and three as no data will be uploaded or needs to be accessed if no request is made.
After deliberation and understanding the project's scope and time constraint, we decided that
we would mainly focus on the task of the process of the data request. This step appeared more
critical for the success of the whole idea.
Figure 1 The illustration above describes the process of a user making a data request
through idento.one, the company receives this request and uploads it to the secure cloud
for the user to retrieve.

5
Methodology and Tools
To communicate with the people from idento.one, we used skype. With it, we made phone
conferences, shared updates, and exchanged information. We used the "How might we" -
question method, literature, personas, and storyboarding to specify our ideas. For doing our
mockups, we used the designing tools Figma, Adobe XD and Mockplus . To get an idea of the
quality of our idea and mockups, we conducted two expert interviews. The expert interviews
were held remotely via Zoom and took around 20 to 80 minutes.
Basic idea
Before developing Personas, Scenarios, requirements, and “How might we” - Questions, we
had to have a basic idea of how the process should be. As it will be explained more accurately
in the designing phase section, we agreed on designing an email as the medium to request
the data from companies. The email should ask the enterprises responsible to upload the
personal data in a secure cloud provided by idento.one. How this email should look like, what
it should contain, and how the following process looks will be identified and explained in the
following sections.
Personas, Scenario and “How might we” - Questions
We developed two personas with different levels of knowledge and experience regarding the
GDPR and technology in general. These were placed in the scenario of being the responsible
employee in their enterprise to answer data checkout requests. Both receive an email from
idento.one with a request to provide the user's data in the way offered by idento.one. We then
identified their needs and expectations and tried to develop a process that satisfies both types
of personas in the design phase.
The first person is Maria. She is 35 years old and works as a Data Protection Office Assistant
of a big fashion online shop. She is very tech-savvy and owns some smart home devices, for
which she has already done a data checkout.

6
Figure 2: Persona „Maria“
The second person is Günther, who is 54 years old. He works in a big car repair shop as a
secretary, where he has to allocate appointments, digitize reports and reorder equipment. The
only digital services he uses in private life are his 4-year-old smartphone and a television. He
has heard about the GDPR before, but he only knows that it has brought stricter privacy laws.
Figure 3: Persona "Günther"
Based on these personas, we identified four main requirements for our email: it should be
trustworthy, useful and easy to use, informative and comprehensive.
Trustworthy: Receivers should not classify the mail as a spear-phishing mail and should be
willing and feel safe to follow the request and go to the cloud to upload the data.
Useful and easy to use: Receivers should easily understand what they need to do to answer
the request. The goal is, on the one hand, that no further interaction with the requester is
necessary. On the other hand, the process should not be more complicated than what the
employee usually uses to provide the data.

7
Informative: Receivers like Günther should find all the information they need, to know what he
has to upload and that he does not need to use an external information service.
Comprehensive: Receivers should quickly understand who requests the data and where/how
to upload it. Advanced receivers like Maria should not need to search long for needed
information.
Based on these requirements, we then developed three "How might we"- Questions which we
tried to answer in the design phase:
1. How might we achieve an email that is perceived trustworthy and leads to uploading
the data?
2. How might we explain to people who do not know about the law or do not understand
what to do?
3. How might we achieve a process that is useful and quick for advanced users?
Design phase
As already mentioned, the goal of idento.one is to develop a tool that supports requesting,
providing, receiving, and accessing personal data. Our goal is to provide a trustworthy, easy
and comprehensive experience of requesting and providing personal data via the third party
idento.one. In the Idento.one section, we worked on tasks both on the customer and the
company side. We would like to state that our primary focus lay on the company side, and we
briefly worked on the customer side. For that reason detailed information about the design
phase of the company side will be given in the following paragraph followed by the design
phase of the customer side.
Designing the process (Company side)
We thought about what would happen after the customer has sent a data checkout request to
a company. Based on the paper of Alizadeh, Jakobi, Boldt & Stevens (2019) and compared to
other methods such as receiving a letter or a phone call, we decided that an email would be
the best choice. It is a common way to request information today, and in the context of
requesting data digitally, a letter would not be appropriate. It does not rely on the time the
recipient gets as compared to a phone call which needs to be answered synchronously and
cannot be accessed again.
From the start, there was a trade-off between ease of use/efficiency (usability) and security,
which is a common design problem in HCI (Lazar, Feng & Hochheiser, 2017). In our first
version, usability - especially the ease of use - was in focus. We decided to send an email to
the customer containing a link and a key. The company would only have to click on the link,

8
enter the key into a pop-up within the browser and start uploading the data. After concerns
were raised by our lecturers, we decided to revise this process and find a more secure way of
handling this process. Our second version contained more steps which made it lengthy to use
but had a higher security standard. With this in mind, we designed a new process:
1. The company receives an email that contains a customer key and a link to the
idento.one website where that key needs to be provided (figure 4).
2. On the next page, the company has to request a One-Time-Password (OTP) valid for
10 minutes. The password is sent to the email address found in the idento.one
database (figure 6 and 7).
3. The company has to use the OTP to get access to the cloud folder and is able now to
upload the requested data.
4. When the company has finished uploading the personal data, a click on a button is
necessary to confirm in an opened pop-up that all data is uploaded (figure 9).
The link leads to a part of the website of idento.one to produce a secure feeling as it is also
accessible by searching on Google for example. Making it accessible via Google should not
lead to a lack of security because two keys are needed to access a cloud that only exists and
is accessible for 30 days. It is only accessible for thirty days after the initial request, because
according to the GDPR, companies have to provide the requested data within this time range.
Using OTPs is common today and helps prevent unwanted access via people who spear mails
(Babkin & Epishkina (2018). We decided to set the validation time to 10 minutes. The developer
that implements this process should also consider limiting the amount of tries to prevent brute
force attacks.
On the other hand, the company has to have enough time to get the password and type it in.
As mentioned earlier, the cloud will be closed to the company after 30 days or by confirming
that all requested data is uploaded. That shall minimize the time a third party can hack the
cloud with uploaded data in it.
To minimize giving personal data to a third party, the email will contain as little information as
possible about the customer but enough for the company to identify their customer, e.g., the
name and a partly hidden email address of the customer. No personal data is revealed in the
two steps between the email and the cloud (figure 5,6,7). However, in the cloud the customer's
name is fully stated, to ensure the company is uploading the data to the correct cloud storage
and to make sure that only the requesting person's data is uploaded (figure 9).
Designing the mockups (Company side)
The goal was to design an email so that a company's data protection officer can easily
understand the content and create trust so that they are willing to upload the data in the
idento.one cloud.

9
For the graphical interface, the first clear requirement for us was to use idento.one’s corporate
design1
. For that, we asked for colour codes of idento.one and used their logo. Besides that,
we researched how to gain trust via email. As we did not find much literature about this subject,
we used literature/web content about mobile commerce (e.g. 5) and digital design in general2
.
Following Agarwal & Venkatesh (2002), design aesthetics are essential to developing trust. Li
and Yeh (2010) confirm that ease-of-use has a significant impact on mobile trust, design
aesthetics influences the ease-of-use itself. To identify how to achieve design aesthetics, we
used Schultz's (2005) statement that "an image header, decorative font, and colourful
graphical buttons can positively affect user's positive impression of the site." Furthermore, we
used an email Design Guide3
to achieve a professional design. Based on that guide, we
separated the header and footer, put the essential information on the top, and aligned our
content, defined sections, and more.
Regarding the content, we used the information from the email Design Guide and decided to
structure the mail into three sections. The first section included the general salutation and the
brief introduction text. It also contained the most relevant data needed about the requesting
customer and the steps that needed to be performed. A company that is familiar with (third
party) data checkout requests can now leave the mail and start performing the steps. For semi-
experienced to inexperienced company users, we added the second part ("Welche
Informationen und Daten können wir für den Nutzer anfordern?") in which the receiver can
inform himself which data has to be shared. The third section of the mail contains the three
most essential questions that might come up when dealing with a third-party data takeout,
explaining when, how, and why that takeout happens. Simple language is used to ensure that
even smaller companies with no data protection officer can understand the matter and the
legal situation. To create a sense of security the third section contains information about the
used encryption technology.
Designing the process and mockups (Customer side)
Our work began at the point where a user is already registered and verified by idento.one. He
is at a point where he wants to make a data request at a company that stores data about him.
He somehow needs to be able to select a company efficiently and intuitively. We collected
ideas on how it would be most intuitive, efficient, and easy to find the needed company. We
ultimately decided to form a dashboard with the company search results displayed in clearly
arranged boxes (see figure 11). At the start-up of the dashboard page, the most popular data
1
https://unternehmer.de/management-people-skills/259724-corporate-identity-definition (last access
30.03.21)
2
https://uxmag.com/articles/designing-to-build-trust-the-factors-that-matter (last access 30.03.2021
3
https://mailchimp.com/email-design-guide/ (last access 19.03)

10
takeout companies are displayed. Once a letter is entered into the search bar, the list refreshes
immediately. It displays all matching results, ordered by popularity, to ensure that the ones that
are more likely to be selected always appear on top. If the user does not know the exact name
of the company he wants to send a request to, he can select different categories to filter the
search. If the company is not part of identos database, the user can suggest it to them by
giving them a name and a contact address. After selecting a company, a pop-up appears
containing a summary about the company, the steps to be followed, and the email that will be
sent out in his name (see figure 10). After this the process on the company side begins.
Regarding the graphical interface we again used the corporate design of idento.one.
Expert interview
Nielson's usability engineering lifecycle is one method among many that states that for a
usable product, users need to be included in the design phase (Nielson, 1992). As none of our
group members ever had to answer a data checkout request, we had to find people who would
be potential receivers/users of the developed mail and process.
We conducted two expert interviews, one with an employee of a joint practice and one with an
employee of a multi-channel retailer. For simplification and increasing the readability, we will
call the practice staff participant A and the retailer staff participant B and use the male form. In
the beginning, we asked some general information concerning the enterprise and the data
checkout requests. Then, we showed the designs and asked for thoughts, feelings and their
hypothetical behaviour. At the end, participants were asked to make a conclusion about the
presented process. The interviews were conducted by a interviewer and a moderator.
General information
Both participants were aware of the rights of customers/patients to request their personal data.
Both were responsible for answering data checkout requests - A is one of a team of six. Also,
both have external Data Protection Officers, which are consulted in unclear cases.
Participant A's practice received only two to three requests right after the introduction of the
law, and participant B receives two to three every month; data deletion requests is more
common.
Participant A’s patients can request their data either via an app or in person, but all requests
are still answered in paper format. All data which is digitally saved as a PDF is then printed
and either gets sent to the patient or has to be picked up. The latter happens if the data is too
big to be sent via mail. However, the practice would currently undergo a digitization process.

11
Requests to participant B are sent in different ways. They arrive either via email, by letter, or
even in branches of the retailer. Data requests are sent either to the customer service or
directly via email for data safety. The participant developed with the external Data Protection
Officer a standard formula of which data has to be provided, which contains the personal data,
where it comes from, and which format they are saved. No matter how the data checkout
request is made, it is passed on to participant B. He first tries to identify the requesting person
as a customer, which is sometimes difficult as some might use another email address or
another postal address. In this case, participant B has to contact the requester and try to get
additional information. Vital information to find a customer would be, e.g., a postal address, an
email address, or/and a customer number. After identifying the customer, participant B
searches in all tools and databases for relevant data of the customer as the purchase history.
Showing the designs
There are no clear answers to every question noted in the questionnaire of the expert interview
(see Appendix page 22 and 23). This is because timewise and dialogue-wise, some were
skipped or answered in another section. Some answers were not quite valuable, and some
may have gotten lost as the interview was not recorded.
Remarks to figure 4 (see Appendix)
Shortly after opening the email mock-up, participant A recognizes the email similar to a Data
checkout request email he has received before. He confirms that he has received a third-party
checkout request after an inquiry but could not remember the enterprises' name. He asked the
doctor's whether he would be allowed to upload the data in the wished cloud, but the answer
was that he should use the ordinary way via paper. He would know which next steps he should
do but also mentions that most colleagues would ignore the mail or pass it as they would not
understand the content. Participant A would follow the requested next step after consultation
and agreement with the boss and the data protection officer. He hopes that he does not have
to compress the data in the next step but can upload pdf-files.
In participant B's first reaction, he stated that it seems to be a lot to read, but all the information
given was perceived as useful. To identify the user, participant B stated that the given
information could be too less, as for example not all customers are registered with an email
address but only with a postal address. Participant B stated that their company has a problem
identifying the person requesting the data in around 30% to 40% of the cases, and therefore a
clear identifier like a customer number would be highly appreciated. If not, it would either mean
a lot more work to find the user or not be able to identify the user correctly. In this case,
participant B would like to have the possibility to contact the person who requests the data.

12
The part of the mail that warns the company user of potential phishing emails seems not to
create trust as intended but leads to insecurity.
Participant A finds this step easy and understandable, as he expected. He also confirms that
he would perform the next step. For this, he expects that he has to confirm that the cloud is
allowed to access data stored on the computer.
After reading the mail, participant B would proceed to the next step but asking himself if the
One-Time-Password means that he would need to register somewhere now. He would not be
willing to register. Additionally, moving to the next page, participant B would have liked the
identification code to be taken over to the next page automatically.
Participant As' first impression is good. He feels safe that only he has access to the cloud.
The next page is perceived as understandable as well, and there seemed to be no unclarity
about what to do next.
The following One-Time-Password verification raised some concerns regarding the internal
process of handling emails on the side of participant B. It was stated that he, depending on
what email address the request was sent to, might not be the person receiving the incoming
OTP. Therefore, it is very likely could happen that he does not receive the password before it
expires. Additionally, entering OTP seemed to be considered as unnecessary as a password
was typed in already beforehand. What would happen next was clear
Participant A is familiar with OTPs and classifies them as standard for many services. He would
enter the password in the field provided for this purpose. After that he would expect that he
reached the point where to upload the data.
Participant B shows uncertainty where to fill in the password. He says that normally he would
let the browser open and fill in the OTP there but based on the link in the email he was unsure
whether that link leads him to the same place.
Participant A rates this explanation as comprehensible and reasonably explained. He would
perform the next step.
Once the OTP was entered, participant B had no problem proceeding and expected to be able
to upload the requested information to the cloud. He hoped that it would be possible to upload

13
the data in a format of their own choice so that there is no need to adapt to new technologies
and input methods. What was unclear was what would happen after uploading the data, mainly
if it was checked in any way. The concern was raised by the need to confirm that all data is
now correctly uploaded and cannot be changed afterward. The question that arose was who
would be responsible for a possible mistake made regarding the provided data. Participant B
additionally would appreciate it if there was a proofing confirmation mail that the upload was
successful and that the data was provided because of the obligation to provide evidence on
the side of the company, that the requested data was provided within the deadline.
The mock-up meets participant As' expectations, and he finds it comprehensible.
Participant B suggests this position to ask the uploading person to certify that only data
referring the requesting customer was uploaded. He also again raises the question whether
after certifying he gets any kind of confirmation.
Feedback about the whole process
Participant A answers that it appears professional and safe, in a way that no third person gets
access to the data. He likes the fact that the process gets closed manually.
As mentioned before he would answer the request after consultation and agreement with the
data protection officer.
Furthermore, no more use of paper and the need to print everything, and simple handling are
positive aspects from him. He would feel safe following the process and prefers this process
to his original one.
For participant B, at first sight, the process is considered extensive and uncommon, as he
mainly receives very short and straightforward requests. The positive aspects were that it is
pretty and professional looking. Participant B states that there would be some trust concerns.
Therefore, he would first need to check the company that mail is coming from via Google. Also,
he needs to ask the Data Protection Officer about the validity and trustworthiness. Giving
personal user data to another company and not to a person directly leads to insecurity. Data
could normally only be disclosed to third parties within strict limitations (e.g. only hashed
values). Therefore, the permission of idento.one to be allowed to request user data should be
more prominent, after participant B. In general, participant B would answer the request by
idento.one, but mainly because data protection is handled very cautiously by the company.

14
Reflection and prospective
Our group work was uncommon for us, as we worked for the enterprise idento.one/Orbiter.
The widespread problem of communication difficulty in group work has unfortunately also
affected this cooperation. Sometimes, it was not that easy to get feedback, and the company
seemed unaware of the cooperation's time limit. Nonetheless, the held meetings were
productive, and we received very positive criticism about our work from the company.
Also, inside the team, the communication was sometimes difficult, due to language. The group
of four only contained one native English-speaking person. More than once, it came to
misunderstandings regarding the discussed concepts and personal exercises. These were
time-consuming but were overcome by further discussions.
In our group work, we decided to face a design problem that primarily affects an enterprise's
employees responsible for data checkout requests. The difficulty here was that we still
designed for private users. It is expected that it would be the most effective if they only need
to click some buttons to send the request and have nothing to do with it until they get a
notification that their data is uploaded in a cloud, where all their answered checkout requests
are stored. This rough process for the private user was also drawn to us by idento.one. That
led to that we did not in the first place think about what a receiver of such a data checkout
request needs to simplify the process on his side. Our objective was to get him to answer the
user's request in the way we provide it to him by putting ourselves in a company-side user
position. What we thought about mainly was based on hypothetical thinking as we never were
in the position of answering such a request. In the chapter Personas, Scenario and "How might
we" - Questions, we defined some requirements that appeared to match the requirements
identified in the expert interviews.
Nevertheless, especially in the interview with participant B, some more crucial and practical
needs were said. The two most important needs are; first that in a big company with several
email addresses and probably different people who answer the requests, the concept with the
OTP does not work as some official channels take too long to get the OTP within a time limit
to the right person. Secondly, companies must provide evidence that the request was
answered with all data within the time limit. Our concept did not consider such a requirement
at all.
As one who read the chapter of the expert interview will have recognized, the whole process's
feedback was quite contradictory. For the participant answering data checkout requests until
today in paper format and only three in three years, classifies this process as quite positive,
practical, and safe. On the opposite, the employee answering digitally three requests per
month mentions many concerns and requirements. Both would follow the process after talking
with their Data Protection Officer. From what can be concluded, even if the process feels safe
for participant A, there are some privacy concerns. Participant B would only follow it because

15
of the duty to answer every data checkout request and not because he finds the process easily
usable. Combined with participant A's statement that most of their colleagues would ignore the
email or pass it to someone else, it has to be concluded that the email is not as easily
understandable and comprehensible as planned. However, it should be mentioned here that
both participants had no trouble with understanding the process and following it.
Another interesting point of the interview with participant B was that he did not understand why
the loop with the OTP would be necessary. That supports our first approach of only needing
the identification key.
In further investigation, it should be considered whether the first approach matched with the
manual closing of the access to the cloud be an interim solution. Furthermore, a concept needs
to be developed for the obligation to provide evidence. For that it first needs to be investigated
whether the company only needs to confirm that she has uploaded something within the
timeframe or also what.
Another point that shall not be forgotten is the necessary identification criteria for the company.
Here one could consider input fields on the user side to provide data like a customer number,
which, however, could lead to further challenges. Also, the possibility of quickly getting in touch
with the requesting user or idento.one for further inquiries needs to keep in mind.
All in all, it can be concluded that in an optimal setting, all companies, services, and public
institutions would be registered by idento.one. In this case, it would be ensured that all requests
reach the right counterpart, all actions could be followed from both sides, and a company could
specify needed information to identify the user. Even further thought, companies would provide
stored data directly to the user. However, as this is a very improbable mind game, one needs
to step back and be realistic. Maybe even the developed process is a step too far. It could be
imaginable that for the beginning, idento.one only provides an email template for the user,
which he can use to send a request manually with a generated cloud key where the company
shall upload the data.

16
Literature
Agarwal, R., & Venkatesh, V. (2002). Assessing a firm's web presence: a heuristic evaluation
procedure for the measurement of usability. Information systems research, 13(2),
168-186.
Alizadeh, F., Jakobi, T., Boldt, J., & Stevens, G. (2019). GDPR-Realitycheck on the right to
access data. Mensch und Computer 2019-Tagungsband
Babkin, S., & Epishkina, A. (2018). One-time passwords: resistance to masquerade attack.
Procedia computer science, 145, 199-203.
Lazar, J., Feng, J. H., & Hochheiser, H. (2017). Research methods in human-computer
interaction. Morgan Kaufmann.
Li, Y. M., & Yeh, Y. S. (2010). Increasing trust in mobile commerce through design
aesthetics. Computers in Human Behavior, 26(4), 673-684.
Nielsen, J. (1992). The usability engineering life cycle. Computer, 25(3), 12-22.
Schultz, 2005.Schultz, L. Effects of graphical elements on perceived usefulness of a library
List of figures
Figure 1 The illustration above describes the process of a user making a data request through
idento.one, the company receives this request and uploads it to the secure cloud for the user to
retrieve......................................................................................................................................................
Figure 2: Persona „Maria“....................................................................................................................... 6
Figure 3: Persona "Günther" ................................................................................................................... 6
Figure 4: Request sent to a company (Appendix) To open in Browser use
https://viewstripo.email/d671a2c3-29b5-488d-bdfc-f2ffcb15be7f1611237315548........................... 17
Figure 5: First browserpage (Appendix)................................................................................................ 18
Figure 6: Second browserpage (Appendix) ........................................................................................... 18
Figure 7: Mail with OTP (Appendix) ...................................................................................................... 19
Figure 8: Welcome pop up in cloud (Appendix).................................................................................... 20
Figure 9: Closing process popup in cloud (Appendix) ........................................................................... 20
Figure 10: Popup when sending a request (Appendix) ......................................................................... 21
Figure 11: Dashboard ............................................................................................................................ 21

17
Figure 4: Request sent to a company (Appendix) To open in Browser use https://viewstripo.email/d671a2c3-29b5-488d-bdfc-
f2ffcb15be7f1611237315548

18
Figure 5: First browserpage (Appendix)
Figure 6: Second browserpage (Appendix)

19
Figure 7: Mail with OTP (Appendix)

20
Figure 8: Welcome pop up in cloud (Appendix)
Figure 9: Closing process popup in cloud (Appendix)

21
Figure 10: Popup when sending a request (Appendix)
Figure 11: Dashboard

22
Einverständniserklärung Experteninterview
Projekttitel: Usable Security
Erforscher: Leonie Griesenbeck, Sören Steinhanses, Jannik Schütte, Frances Antwi-Donkor
Moderator: Leonie Griesenbeck; Dokumentation: Sören Steinhanses
Name des Teilnehmers:
Vielen Dank für Ihre Zeit und Ihr Einverständnis, an diesem Experteninterview teilzunehmen. Aus
ethischen Gründen ist es erforderlich, dass die Befragten dem Interview und der Nutzung der von
ihnen bereitgestellten Informationen ausdrücklich zustimmen.
Diese Einverständniserklärung dient, um sicherzustellen, dass Sie den Zweck der Befragung
verstehen und dass Sie mit den Bedingungen Ihrer Teilnahme einverstanden sind. Bitte lesen Sie das
Informationsblatt und bestätigen Sie mit Ihrer Unterschrift, dass Sie mit den folgenden Punkten
einverstanden sind:
• Relevante Informationen des von Ihnen gesagten werden dokumentiert
• Der Zugang zu den gesammelten Daten wird auf die Forschungsgruppe beschränkt und wird
ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben.
• Die Schlüsse und Ergebnisse, die aus den Experteninterviews gezogen werden, werden in
einem Bericht zusammengefasst und der Universität und dem Unternehmen Orbiter/Idento zur
Verfügung gestellt
• Auf Anfrage können wir Ihnen eine Kopie der Dokumentation zukommen lassen
Bitte kreuzen Sie eine der folgenden Aussagen an, mit denen Sie einverstanden sind:
Ich möchte die Notizen, die während der Forschung gesammelt wurden und sich auf meine
Teilnahme beziehen, einsehen
Ich bin damit einverstanden, dass ich direkt zitiert werde (anonym)
Ich bin damit einverstanden, dass meine Daten für diese Forschung verwendet werden
Mit der Unterzeichnung dieses Formulars stimme ich folgendem zu:
1. Ich nehme freiwillig an diesem Projekt teil
2. Ich verstehe, dass ich nicht gezwungen bin, an diesem Prozess teilzunehmen, und dass ich
jederzeit aufhören und mich abmelden kann.
3. Die Notizen des Interviews dürfen wie oben erwähnt verwendet werden
4. Ich habe das Informationsblatt gelesen
5. Ich erwarte keine Zahlungen oder Vorteile aufgrund meiner Teilnahme
6. Ich kann eine Kopie der Notizen anfordern und sachliche Änderungen daran vornehmen, um
die Effektivität der erhobenen Daten zu gewährleisten.
7. Ich konnte meine Fragen stellen und verstehe, dass es mir freisteht, auch in Zukunft Fragen
im Zusammenhang mit dieser Untersuchung zu stellen.
Name des Teilnehmers Unterschrift/Datum des Teilnehmers

23
Informationsblatt/Briefing
Vielen Dank, dass Sie Interesse an der Teilnahme an unseren Experteninterviews haben!
Um von Anfang an einen möglichen Druck rauszunehmen: “Experte” bedeutet in dem Sinne nicht,
dass Sie sich mit der Materie perfekt auskennen musst sondern, dass Sie durch Ihre berufliche
Situation in deiner Position wären, eine Datenanforderung, wie sie in unserem Projekt gestaltet wurde
zu erhalten. Uns geht es darum zu sehen, ob das was wir gestaltet haben zu der von uns
gewünschten Handlung führt oder eben nicht.
Wir sind eine Gruppe von vier und studieren entweder Mensch-Computer Interaktion oder
Wirtschaftsinformatik und machen dieses Projekt und die Umfrage im Rahmen unseres Kurses Usable
Security an der Universität Siegen.
Die Daten, die wir in diesem Gespräch erheben, werden anonymisiert gespeichert. Sie werden für
Forschungszwecke genutzt, sowie dem Unternehmen Orbiter, mit welchem wir in unserem Projekt
zusammenarbeiten zur Verfügung gestellt.
Wenn Sie damit einverstanden sind, werden wir Ihnen zu Beginn der Studie kurze Fragen stellen und
Ihnen dann Designs zeigen und Sie bitten Ihre Gedanken, Gefühle und Erwartungen diesbezüglich mit
uns zu teilen. Zudem würden wir Sie bitten Ihren Bildschirm zu teilen, damit wir sehen, was Sie sehen.
Sollten Sie während des Gesprächs abbrechen wollen, können Sie dies natürlich ohne jegliche
Angabe von Gründen tun.

24
Experteninterview Ablaufplan
Einleitung/Briefing
Vielen Dank, dass Sie an diesem Experteninterview teilnimmst. Das hilft uns sehr! Um von
Anfang an einen möglichen Druck rauszunehmen: “Experte” bedeutet in dem Sinne nicht,
dass Sie sich mit der Materie perfekt auskennen musst sondern, dass Sie durch Ihre
berufliche Situation in deiner Position wären, eine Datenanforderung, wie sie in unserem
Projekt gestaltet wurde zu erhalten. Uns geht es darum zu sehen, ob das was wir gestaltet
haben zu der von uns gewünschten Handlung führt oder eben nicht.
Wir sind eine Gruppe von vier und studieren entweder Mensch-Computer Interaktion oder
Wirtschaftsinformatik und machen dieses Projekt und die Umfrage im Rahmen unseres
Kurses Usable Security an der Universität Siegen.
Die Daten, die wir in diesem Gespräch erheben, werden anonymisiert gespeichert. Sie
werden für Forschungszwecke genutzt, sowie dem Unternehmen Orbiter, mit welchem wir in
unserem Projekt zusammenarbeiten zur Verfügung gestellt.
Wenn Sie damit einverstanden sind, werden wir Ihnen gleich erstmal ein paar kurze Fragen
stellen und Ihnen dann Designs zeigen und Sie bitten Ihre Gedanken, Gefühle und
Erwartungen diesbezüglich mit uns zu teilen. Zudem würden wir Sie bitten Ihren Bildschirm
zu teilen, damit wir sehen, was Sie sehen.
Sollten Sie während des Gesprächs abbrechen wollen, können Sie dies natürlich ohne
jegliche Angabe von Gründen tun.
Fragen:
1. In was für einer Art von Unternehmen arbeit Sie?
2. Ist Ihnen bekannt, dass privatpersonen seit 2018 ein Auskunftsrecht bezüglich
personenbezogene Daten haben?
3. Sind Sie in ihrem Unternehmen dafür zuständig diese zu beantworten?
4. Haben Sie schon einmal so eine Anfrage erhalten?
5. Wenn ja, wie/in welcher Form beantworten Sie diese normalerweise?
1. andere emailadresse, Kunde finden
Mockups
1. [Bitten den Link zur Mail zu öffnen]
Stellen Sie sich bitte vor, Sie würden diese Mail auf der Arbeit erhalten. In der Anrede
würde entsprechend der Name Ihrer Firma stehen und in dem Feld über den Nutzer
informationen zu einem Ihrer Kunden.
1. Was ist ihr erstes Gefühl, was sind ihre Gedanken?
2. Finden Sie alle relevanten Informationen?
3. Wenn nein, welche?
4. Was würden Sie tun?
5. Würden Sie der Bitte/Aufforderung folge leisten?
6. Was würden Sie erwarten wenn Sie auf die angegebene URL gehen würden?
2. [Bitten erstes Bild zu öffnen] (Personenbezogenen Schlüssel teilen)
1. Ist das was Sie erwartet hätten?
2. Was denken Sie?/Was ist ihr erster Eindruck?
3. Ist das für Sie verständlich? Fehlen Informationen?
4. Würden Sie den nächsten Schritt tun?
5. Was würden Sie erwarten passiert im nächsten Schritt?
3.[Bitten zweites Bild zu öffnen] (OTP anfragen)
3. Sind Ihnen OTPs geläufig?

25
4. [Bitten zweite Mail zu öffnen]
5. [Bitten zweites Bild wieder zu öffnen]
6. [Bitten drittes Bild zu öffnen]
7. [Bitten viertes Bild zu öffnen]
Zweite Fragerunde:
1. Was sind zum gesamten Prozess Ihre Gedanken?
2. Würden Sie darauf antworten?
3. Was finden Sie gut was schlecht?
4. Würden Sie sich sicher fühlen dem Prozess zu folgen?
5. Würden Sie diesen oder ihren gewöhnlichen Weg bevorzugen?
Debriefing:
Vielen Dank nochmal für die Teilnahme! Das hat uns sehr geholfen!
Ziel des Projektes und von Orbiter ist es als dritte Partei zwischen den Kunden und den
Unternehmen zu vermitteln um möglichst für beide den Prozess zu vereinfachen.

Data Checkout Process: Designing a Standardized Data Request via Idento.one

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Data Checkout Process: Designing a Standardized Data Request via Idento.one

Similar to Data Checkout Process: Designing a Standardized Data Request via Idento.one (20)

More from h-bauer2014

More from h-bauer2014 (14)

Recently uploaded

Recently uploaded (20)

Data Checkout Process: Designing a Standardized Data Request via Idento.one