
Product Design Exploration
A concept of insights feature built on top of the existing Activity flow
An independent design exploration inspired by the public Vipps app
Vipps knows more about my habits than I do.
Every coffee, every rent split, every late-night takeaway — it's all logged. The data is there. But the app never tells you anything about it. To answer the simplest questions — do I send more than I receive? which businesses show up every month? — you scroll manually through a list and do the math yourself.
That gap is what this project started from.
Challenge
Vipps is intentionally low-friction. New feature must respect that.
Embedding insights into the existing activities screen
Design approach
Minimum intervention, Maximum seamlessness
To achieve this I explored an insights layer embedded in Activity. The system follows a four core principles:
Patterns over advice
Financial advice carries emotional weight. "You spent a lot on coffee" is a judgment, even when framed neutrally. Vipps is trusted because it doesn't make you feel watched. The feature had to observe without commenting.
Progressive disclosure
There's a difference between a tool that gives information when you ask and one that puts it in front of you regardless. The first feels like a feature. The second starts to feel like surveillance — even of your own data.
User control
Even people who said they'd use the feature regularly considered the ability to turn it off important. The control matters as much as the content. A feature you can ignore when you don't need it is one you trust when you do.
Visual consistency
Vipps has a quiet, confident visual language. Anything that looked imported from a fintech dashboard would feel wrong immediately. Every screen reuses existing colors, typography, and interaction patterns.
Together, these four principles defined a clear design space: show users what's already there, let them choose when to look, and make sure it feels like Vipps did it themselves.
How it Works
This feature is built as a single insight system powered by existing activity data
Insights are generated from existing transaction data, aggregated over the last 30 days and interpreted through three lenses: general patterns, people exchanges, and business activity — all powered by the same underlying data system.
Insights Feature – Conceptual Data Architecture
General Insights
View provides orientation on patterns, not analysis
When payments usually happen, whether activity is mostly person-to-person, general usage rhythm etc.
People insights
Helps users recognize recurring dynamics without judgment
Rather than interpreting relationships, the system presents neutral transaction data — who you send money to and who you receive money from.
Business Insights
Highlight businesses that appear frequently in activity
I intentionally avoided framing these as “recurring payments,” since many repeated business payments are habitual rather than scheduled.
Validation
Concept was shared with Vipps users
I shared the concept with five regular Vipps users — people who use the app at least weekly, none of them designers. I walked through the screens with each person individually and asked them to think aloud. Three things came back clearly across all conversations:
The insights felt understandable
No tutorial needed. The language and layout did the work on their own.
The feature felt like Vipps
Not imported from a fintech dashboard. Something that could already be there.
Optional visibility was considered essential
Everyone wanted the off switch — even people who planned to use it regularly
Key Takeaways
Closing Reflection
This concept has a real limitation: it's designed around what feels right, validated with five people. That's enough to test a direction — it's not enough to ship.
If this were moving toward a real product, the next step would be a functional prototype with real transaction data to test whether the insights actually read as meaningful. Pattern recognition feels intuitive as a concept; whether the specific patterns Vipps surfaces would feel relevant to a broad user base is a separate question that only real data can answer.
What I'd do differently: I'd involve users earlier in defining which questions they actually want answered — rather than assuming the three lenses I chose (general, people, business) are the right ones. I chose them because they felt logical. A round of exploratory research before designing would have given that structure more grounding.
What I'd keep: the constraint to not give advice. That felt right from the beginning and every piece of feedback reinforced it. In a space where so many fintech products try to coach users toward better behavior, "just show me what's there" is a genuinely different position — and I think the right one for Vipps specifically.





