A Brief into Design Thinking on Signing Data Processing Agreement

A Brief Into Design Thinking On Signing Data Protection Agreement

2021｜Type: Original｜Tag: Experience

Backgound

Following the PIPL (Personal Information Protection Law of the People's Republic of China), the DMP (Data Management Platform) has released the Data Protection Agreement to strengthen the supervision of the use of personal information by advertisers. Currently, the platform fails to affirm the Data Protection Agreement to advertisers which requires advertisers to actively confirm whether or not to sign it. This issue is easily challenged by the regulatory authorities and advertisers.

In order to fulfill the data protection of advertisers and improve the user experience of the platform, design strategies for signing the Data Protection Agreement need to be emphasized. Failure to sign the agreement or canceling the agreement will have a negative impact on the advertiser to use the platform, but when it comes to data application compliance, we believe that disclosure of the agreement on the platform is necessary and mandatory, direct and obvious.

Principle

Direct. Advertisers signing up on the platform is straightforward and the signing status is visible.
Timely. When the signing status changes, the advertiser can perceive it in time, and the advertising platform can take effect in time.
Precise. The agreement is precise in terms of the user's personal and platform capabilities.

Elements of design

In summary, we can consider agreement signing on platforms in terms of touchpoints, modes, processes, interfaces, and states.

Touchpoints: the key factor

Clarify the key factors affected by signing up based on the content of the agreement. Uploading the audience files, and connecting the data sources of the first party on the DMP platform are strong connections to the key factors.

All the touchpoints of these key factors across the platform and even across the business, including the DMP platform ad delivery platform, and so on.

Make it clear where users can read the agreement, sign, unsign, and re-sign the agreement. Overall we believe that users need to be prompted and guided when platforms are involved in the key factors affected by the agreement. Whether and how the signing up of the agreement affects the online system, we believe that it can be handled differently according to incremental data and stock data.

As an example, uploading the audience files, which are scattered throughout the various features of each platform to provide a selection of the audience files:

The Audience File Selector in Dropdown

For increments data, new ones cannot be created in the process is recommended. The reason for the disable button should be clear and be complemented by a global alert and a signed entry in a reasonable place.
For stock data, no permission to submit changes in the process is recommended. Stock items should be given a clear reason for disable actions, along with data compliance on Data Disconnected, Data Zero, and Data Empty. Data visualization and emotional design are also involved here.

Impact of Unsigned Agreements in Uploaded Audience Files

Patterns: First time to sign, agreement renewal

First time to sign: The agreement pops up in time when the user logs in to the platform.
Agreement renewal: Update tips pop up in time when the user logs in to the platform. (not yet involved)

Process: Sign and unsign

Sign: It needs to be clarified that the agreement is a user check action proactively and the platform can't imply users with a checkbox checked in default.
Unsign: Unsigning the agreements leads to subsequent impacts, and it needs to be clarified whether the user really unsigns by confirmation, so as to exclude the triggering of a manual error.

Signing Pop-ups and Reconfirmation Pop-ups after Cancellation of Signing

Besides, we can also introduce the issue date and duration to let users feel the security brought by signing the agreement, and we still have imagination on emotional design.

Application of Emotional Design

Interface: Status disclosure and rollback

The status of the signing contains important information such as which user in which role, at what time, signed or not, and on which agreement. Considering the structure of roles, it is possible to understand whether the subject is an account or an individual. Currently, DMP is signed by an account. For this reason, we need to disclose the status at the account level.

Disclosure: Need to explicitly disclose the status to a reasonable layout.
Rollback: Provide logs of signing and unsigning. (not yet involved)

Status: Disable system

Based on the user's behavior on the platform and the life cycle of the behavior, combining the user's disable actions on DMP, the disabled system can be understood as follows:

Product version: The features are not enabled in some versions of the product, which makes the feature unavailable.
Users, roles, and accounts: The features that are not available may be caused by insufficient authority of users, insufficient assignment of authority to roles, or accounts being affected within the scope of authorization.
Point scheme: The platform is pre-built with whitelisting, points, and rights mechanisms that are not available to users who do not fulfill the full mechanisms.
Online system: the volume is too large or too small to be used. For example, it takes up resources if it is too large, and the model cannot be used if it is too small.
Computation Tasks: Features that need to be submitted to an online computation task and whose state is not available while the computation is in progress or fails. For example, the computation of the report of audience files.
Quit Mechanism: Avoid wasting resources by setting the quit rules according to the limit, such as expiration, offline, physical offline, and so on, and the results are not available. For example, no actions within 6 months lead to invalid, and 10 days without positive effect leads to offline automatically.

On the whole, we believe that any actions within the duration of signing are affected by the status. In designing the subsequent effects of unsigned agreements and canceled signed agreements, it is still feasible as follows:

Product version: whether the agreement is equally valid between different versions, or whether there are different agreements to be signed additionally based on the level of cooperation. It is recommended to remind users to pay attention to the differences in the content of the agreement due to the product version.
Users, roles, and accounts: Whether the signatures of different users under the same account are equally effective, whether the signatures of different accounts under the same subject are equally effective, and how to take effect the authorization involving different scopes. It is suggested to remind users of the subject of signing and the effective scope.
Point scheme: Whether the original point scheme is only effective within the scope of the agreement and whether it needs to be modified as a result. It is suggested that users should be advised of the rights and benefits that are affected.
Online system: Within the scope of the agreement, is there an impact on the incremental data, and how is it handled for the stock data? It is recommended that the user be prompted as to which features of the online system are affected.
Computation Tasks: same as above.
Quit Mechanism: same as above.

Considering the influential level of the disabled system, its hierarchy of it can be deduced. The DMP current stage of the product version and the point scheme in the disable system are front-end imperceptible, that is, the level can be:

Layer 1: Users, Roles and Accounts. Disable actions generated by whether to sign the agreement from the authorizer side or the authorized side.
Layer 2: Disable actions generated by the online system, computation Tasks, and quit mechanism based on what is available in the first layer.

Last but not least

This article takes a look at agreement signing from a designer's perspective on the need for rapid response data compliance.

There may still be many imperfections, such as the user's personal information and how it is affected, and so on.
Under the requirements of data compliance, top-down design thinking has been put forward in both data governance and product experience.

In terms of experience design, there are two points that are worthy of thinking and exploring, namely the sorting out of key factors and the hierarchy of the disabled system. Both of them provide imagination of design thinking directly. The former focuses on the business, the latter on the framework. As the data compliance works out, there is still room for further design thinking.