Since 4 July, our online service "Grundsteuererklärung für Privateigentum (Property Tax Return for Private Property)" has been available to support submission of the return with which to determine property tax values. For the best possible user experience with as few obstacles as possible, the focus in the development of the service – as described by our colleague Katja in the blog article "Next stop: 'Property Tax'" – has been placed not only on user-centricity, but also on data economy and producing as simple a solution as possible. We therefore decided to use so-called magic links for the registration process and creation of user accounts.

When we started the development, we originally assumed that owners would submit their property tax returns in one single step. In the course of the usability tests we conducted on the prototypes we had developed, however, we quickly discovered that users would like to be able to take a break in the preparation of their property tax return and then resume the process at a later point in time. The main reasons for this were usually the need to obtain lacking documents and information from government authorities or other co-owners.

The following questions cropped up for us:

• How can we make it as easy as possible for users to "push the pause button" and re-enter the online service at a later point?
• And in terms of data security: how can we ensure that users log out when they leave the tool, thereby blocking access to their data, and have to authenticate themselves when they log in again in order to regain access?

At first glance, the answer seems simple: by means of a classic user account. But one that comes with a special feature that revolves around the fact that the property tax return – unlike many other recurring tax returns – only has to be submitted once. This served as the basis for our assumption that such an account would only be used or needed for a limited number of logins as well as merely for a few hours to a maximum of several weeks – depending on the availability of the information needed to complete the return. Once the property tax return is sent away by mail, no further action is required. Users would then leave the account dormant – according to our hypothesis – until it is automatically deleted after four months of inactivity.

Common practice in creating a user account is still a combination of an email address and password. With the ever-increasing number of user accounts that Internet users are creating online nowadays, however, the number of passwords that need to be remembered is also snowballing. If not stored in the browser or other password managers, passwords are usually forgotten with lengthening intervals of time. (Unless they have been written down with pen and paper.) A popular avoidance tactic here is to reuse a single password for multiple accounts. A 2021 analysis showed that among people who had had more than one password stolen in the previous year, 60% of registration data had been reused for multiple accounts. Coming up with, assigning and remembering (secure) passwords demands a great deal of responsibility and technical finesse on the part of users as well as operators to ensure that attacks aimed at stealing access data are prevented.

Alternatives to this approach include the assignment of one-time passwords – users receive a password that is only valid for one-time use and have to enter it in the interface – or the provision of a so-called magic link. In view of the special requirements applying to an account involving our "Grundsteuererklärung für Privateigentum (Property Tax Return for Private Property)" service, our team finally decided in favor of implementing magic links. The decisive factors in this decision were the security of account access and making the user experience as obstacle-free as possible. In keeping with our agile and iterative approach, this does not mean that one-time passwords will not be explored as a possible alternative over the course of operation, however.

Magic links are a very easy-to-use means of achieving secure authentication from a user perspective. They are similar in terms of their basic principles to the password reset functionality of a password-based service. In the case of the latter, a link – very similar to magic link – is sent to users allowing them to assign a new password one time. In the case of a magic link, there is no need to assign a new password. Instead, the user is logged in directly – but only if the same device and the same internet browser are used. For security reasons, a magic link only works on the browser in which registration was carried out previously. The big advantage of magic links is that users do not have to think up or remember passwords.

This is because, once forgotten, the navigation involved in resetting a password is usually complex:

1. Click on "forgot password"
2. Enter the email address and submit the order
3. Switch to the email box
4. Click on the "reset password" link
5. Assign a "new", secure password and confirm its entry
6. Enter the email address and the newly assigned password on the login page

Magic links significantly streamline the login process:

1. Enter the email address
2. Send a login link
3. Switch to the email box
4. Click on the login link

A reduction in the number of steps alone, however, is not necessarily perceived by users as a simplification in actual practice. Especially not when the expected behavior of a software changes.

The questions that preoccupied us were hence:

• How will users react when the system guides them back to the personal area of our online service – as if by magic?
• How does the use of magic links change perception of a user account?
• Is this a better alternative to the classic email password combination due to the nature of "short-lived" user accounts?

Instead of looking for answers to these questions, we could of course have implemented the password reset feature in its conventional form. In this case, the magic links feature would have ended up on our list of potential additional functionalities and then been considered in comparison with other possible improvements over the course of the project.

The tight schedule and the deadline set by the Federal Government for submission of the property tax return by the end of October, however, left little space for the development and implementation of additional functionalities. We therefore decided to address the unresolved issues in the context of a spike. In agile development, a spike is a procedure that seeks to collect as much information as possible over a limited period of time. These are used, for example, to clarify issues surrounding the complexity of a problem. Based on the answers obtained, a better decision can be made as to whether a suitable solution can be implemented in the available time, whether the benefits outweigh the time and effort and whether other dependencies or technical implications may be involved.

After considering the pros and cons of "magic" identification indicated in the spike, the team collectively decided to implement magic links and discussed the next steps needed to incorporate the functionality into our first release, the minimum viable product (MVP).

With a view to user experience, the following challenges involved in the handling of magic links could be extrapolated in particular from emails received by our customer support:

• A majority of people use different browsers on their own computers or smartphones. The default browser that the operating system specifies and that opens automatically when the link from our email is opened is not always used in everyday practice. This results in an error message if the security requirements of the magic link – the same browser being used to request the link and to log in – are not met.
• Users do not realize that the link is only valid for one session and must be reapplied for to log in to the application again.
• Sometimes the emails with the magic links only arrive after a delay. In the meantime, users may have ordered a new link several times. The fact that only the most recent link from the most recent email is valid is not self-evident, however.
• Users do not feel like they have an account and are unsure in the first place if they can log out and log back in later.

From a technical (security) perspective, we can say that the process and the decision to work with magic links have proven their mettle. From the perspective of users, however, it must be conceded that the concept is still relatively unknown and therefore requires a great deal of initial clarification and explanation. We had underestimated this aspect at first. Additional notes on the website and information in the help area of "Grundsteuererklärung für Privateigentum (Property Tax Return for Private Property)" now ensure clear communication.

The insights gained will be directly incorporated into potential future use of magic links for other DigitalService applications. With over 150,000 users already registered in the first four weeks, the acceptance of this alternative approach to creating and using a user account is also evident.