A collaboration model for the Interhyp Home platform
How should a mortgage advisor and their client work on the same application, at the same time, without stepping on each other's changes? I spent five months researching, designing and testing an answer — and it became my Master's thesis, graded 1.0.
One platform, replacing three
Interhyp was merging three separate applications — Home, Sales and Credit — into a single platform, Interhyp Home, used by mortgage advisors, bank employees, clients and agents together. For the first time, these groups would overlap on the same screens.
The company had three goals for the new collaborative features: make every action in the platform transparent to everyone involved, keep the home-buying process simple, and keep the platform scalable as more user groups were added.
To keep a five-month thesis realistic, my supervisor and I narrowed the scope to two roles — the agent (a freelance mortgage broker) and the client — and to one step in their shared workflow: data entry, where both sides fill in and verify the same application data. It's the point with the most back-and-forth, and the most to lose if it's confusing.
Research question: How does an optimal collaboration model between the agent and the client look within the Interhyp Home platform?
Design thinking, in five months
Interhyp's stakeholders had fixed requirements and milestones; my university needed a rigorous, documented process. Design thinking satisfied both — it's iterative enough to revisit earlier steps when testing turns up something new, which is exactly what happened here.
Empathize
Define
Ideate
Prototype
Test
What "good collaboration" already looks like
I started with a competitive analysis across four kinds of collaborative tools — creative boards (Miro), documents (Google Docs), project management (Trello) and communication (Microsoft Teams, Slack) — to see how each handled the same underlying problem.
Across all four, five recurring patterns stood out as the features worth adapting: history / versions, notifications or activity feed, real-time collaboration, online / offline status, and comments. These became the candidate feature set for everything that followed.
Personas & context of use
Agents turned out to be less uniform than the initial brief assumed, so I built two agent personas and validated them with Prohyp's customer service team, who speak with agents daily.
Florian Schneider
Full-time, tech-comfortable, handles a high volume of applications and wants speed above all.
Volker Schmidt
Financing is a side task next to his main business; needs the platform to ask little of him.
Susanne Freundlich
First-time buyer, relies heavily on her agent and wants to feel informed, not overwhelmed.
Alexander Kluge
More experienced with paperwork, wants control and a clear record of who changed what.
40%only about 40% of agents actually matched the "Florian" persona — yet, according to Interhyp's customer service team, that group generates 60–70% of Interhyp's revenue. Designing for their speed and volume mattered more than designing for the average case.
Both rows tell the same story: satisfaction holds steady through the early consultation, then drops sharply the moment one side discovers the other changed something — "I did that?! But that's wrong, I have to correct that!" — with no way to see what changed, when, or why. That single moment became the design target for the rest of the project.
Six candidate features, one problem statement
Combining the competitive research with the journey map gave me six features to evaluate: activity history, notifications, real-time collaboration, online/offline status, comments, and version history.
The problem I defined from this: agents and clients edit the same data asynchronously, with no shared record of what changed, who changed it, or whether the other person is even active right now — and that gap is what turns a routine correction into a moment of frustration and lost trust.
From paper to a clickable prototype
I sketched each feature on paper first, then built clickable prototypes in Adobe XD on top of Interhyp Home's existing UI — the interface itself was already defined, so my job was to design how these collaborative layers sat on it.
Two rounds of testing, one real pivot
"Prototype as if you know you're right, but test as if you know you're wrong" — I took that literally and ran two rounds.
Round 1 — Internal expert review
4 participants: two UX experts, one developer, one product stakeholder. Caught structural issues early and got the design aligned with company requirements before it reached real users.
Round 2 — External usability test
5 participants from Prohyp customer service, who speak with agents daily and were asked to role-play as one. Remote, moderated, think-aloud sessions over Microsoft Teams with a clickable Adobe XD prototype — I observed rather than facilitated, so I could focus entirely on reactions, hesitations and mouse movement.
What the usability test actually found
I scored every issue on frequency, task impact, business impact and persistence, following Nielsen's severity model, then prioritized fixes with my supervisor and the stakeholders.
| Severity | Issue | Frequency |
|---|---|---|
| High | The history icon wasn't recognized without a direct hint | 5 / 5 |
| High | Items in the activity list weren't understood as clickable | 1 / 5 |
| Medium | Too much white space between activity items | 2 / 5 |
| Medium | Participants expected activity and version history combined into one place | 4 / 5 |
| Medium | Version history showed dates first; participants wanted to see what changed first | 1 / 5 |
| Low | Comment icons were too small to notice immediately | 1 / 5 |
| Low | Online/offline status needed to be adjustable, especially for agents | 4 / 5 |
| Suggestion | Requests to archive comments and email a summary to clients | 2–3 / 5 |
Assumption → observation → design change
The value of testing wasn't confirming what worked — it was the handful of moments where the data disagreed with my assumptions.
Activity history & notifications
Version history
Comments
Real-time & online/offline status
Recommendation & reflection
Based on the testing, I recommended Interhyp implement all five collaborative features for Interhyp Home's data-entry step, with the specific refinements above — the combined history panel, the more discoverable icon, adjustable presence, and comment archiving on the backlog. The thesis was graded 1.0.
If I ran it again, I'd test with real agents rather than customer-service staff role-playing as them, and I'd run a third round focused specifically on the two problems I suspected were caused by how I worded the tasks, not the design itself.
What stayed with me most: the biggest usability win here wasn't a clever interaction, it was making sure the loudest, most frequent pain point — "wait, what changed and why?" — had one obvious place to get answered.