Consents as trust
When the brief was "build a consent screen," I followed the evidence instead — and found that the real problem had nothing to do with the screen.

Project Intro
Consent collection was part of the Panorama project. Getting customer consent was critical for engagement with Panorama’s financial evaluation tool.
The leadership’s goal was to simplify the consent process to a single checkbox. However, the team was unclear about how this solution would function or be implemented. There was considerable uncertainty regarding whether the single-checkbox approach would be approved, so we needed to develop a backup plan.
My Role
There was no explicit UX task for this, but I took responsibility for:
- Bringing clarity to how the solution might work,
- What existing research says about consent, and
- Broader customer attitudes toward consent-giving in banking.
I scoped this deliberately: understanding what the journey needed in order to deliver relevant, accurate data to customers — not solving consent as a company-wide problem. Broader questions, like a consent management platform or a unified marketing-consent strategy, stayed out of scope, for someone else to pick up.
The business goal is to increase the % of consents by bundling them into a single checkbox. However, this contradicts UX principles of giving customers control, even though a single checkbox simplifies the “boring” legal stuff.
I researched whether the single-checkbox approach would be viable. To do that, I reviewed existing user studies in the bank and broader trends in consent-giving in the financial market. I also reached out to the team managing consents to understand current consent rates.
Customer journey: when to introduce and in what form?
Before proposing anything, I wanted to understand why customers held back from consenting in the first place. Existing research pointed to five recurring barriers: not seeing what they would get out of it, mistaking the request for marketing rather than something useful, not knowing how their data would actually be used, wariness about being contacted by third parties as a result, and a more general lack of trust in how the exchange would be handled. A single checkbox does not address any of these directly — it just compresses the moment where a customer would otherwise get to weigh them.
Users prefer to know what they get out of the particular consent before they say yes. Therefore, bundling all into one would worsen the experience.
This was not just a hunch. A 2023 KPMG consumer survey found that 68 per cent of people are concerned about how companies use their data — yet 75 per cent said they would share it anyway if they trusted the organisation and could see a clear benefit. Research on consent phrasing showed the same pattern: framing built around “help me make better financial decisions” consistently outperformed framing built around “receive offers and promotions.” For a Nordic banking audience specifically, the effect held even more strongly — broad, bundled requests underperform, while two or three specific, purpose-bound permissions earn both higher opt-in and better long-term retention.
If we wanted to succeed with collecting permissions, we needed to phrase them in such a pattern that clearly communicates their benefit to the customer: “Help me make better financial decisions” rather than “Receive offers and promotions.”
I considered two journeys:
- Single check-box: where should such screen be placed? What should be communicated, and what happens beyond that point.
- Back-up plan — separate consents: splitting up consents by need. All customers by default already have at least the Concern consent, which would allow us to show some of the data.
Working with existing frameworks
Consent collection flow was already available in our contractors’ capabilities. It was important to evaluate how much the solution fits our needs and how much rework would be needed to meet requirements.
Existing framework offered a simple view with actions. A single sheet of text would be difficult for our customers to read through and understand.

Intro text would need to work very hard to convey the message of the benefits of consent. We would risk people either dropping off or overlooking it and simply clicking through.
A single screen that has to do all the convincing

This is the concept shown above — a single automated screen that states the value of each connection in plain language before asking the customer to say yes.
The design itself was an attempt to answer those doubts before they could form. Each value proposition named a specific concern rather than asking for blanket trust — accounts aggregated “securely,” tax data shared so the financial picture “reflects reality,” group data used “safely and transparently.” The screen that followed carried the same idea further, showing customers exactly what was happening as each connection initiated, rather than leaving the moment after consent as a black box.
Multi-step backup solution for collecting consent

A single-checkbox solution carried significant uncertainty about its feasibility; therefore, I looked into existing solutions already implemented in the application. Undoubtedly, advantages would have been minimal development time and consistency with the rest of the application. Moreover, splitting the consents would give customers more clarity, but multiple steps make the process tedious.
Weighed against the trust finding, I made the case for the multi-step approach to the working group. A single page that leads with value, like the version I sketched, still risks compromising trust due to a lack of granularity. Splitting consent by need cost a few extra taps, but it gave the people responsible for the decision defensible ground: customers who actually understood what they said yes to.

Time to value over full consent collection
I explored a more advanced version of the same idea. Instead of asking for all consent up front, even in steps, the product could request each one only when it's actually needed — for example, when a customer opens a tax-related feature, not before. I mapped this as a full flow: the system checks what consent a customer already has, shows whatever data is available without it, and only interrupts the journey when a specific feature genuinely requires something missing.

How will we know we have done a great job?
I was seeking to find out what the current levels of consent-giving were in online channels. I reached out to the data team and those managing marketing consents, but no one has been able to provide me with a concrete number. So based on that, I needed a success indicator closer to the design I was working on.
As I could not find a single number, I proposed that our leading indicator be the number of consents given in our journeys. Increasing this would indicate value to business outcomes.
The real problem was never the checkbox. It was trust — customers disengage the moment they are asked to agree to something before they understand what they are getting in return. A single checkbox did not make that problem worse or better on its own; it only removed the room to explain the value first.
Journey scope, set against the broader consent need this project deliberately did not try to answer.

Outcome
I represented the voice of the customer in meetings on the journeys and shared my findings with the working group. I also provided input to our vendor, who was developing a consent solution for Danske Bank’s new app.
Testing consent collection at the beginning of the journey reinforced the research findings — people trusted the journey less when they were asked for consent upfront, confirming that timing and framing mattered more than the mechanics of the checkbox itself.
The project was handed over to another team before the final solution shipped, and I never got to see whether the multi-step approach held up in the numbers. That is the part I would still want to know — whether trading a bit of completion rate for transparency actually paid off the way the research suggested it would.