Not Just Email & Password:
The inherent complexity of an application-based onboarding
Skyland Family is a membership-based investment platform for family offices and wealthy individuals.
While industry best practice is to reduce friction at signup, any complex registration form that requires applicant evaluation comes with trade-offs. For a community founded on trust and integrity, carefully considering every prospective member is paramount.
My role:
- Discover, collect, and centralise the crucial data points for every member application scenario: Private Individuals or Family Offices, Foundations and Verified Partners (such as developers, banking partners, real estate agents)
- Identify patterns for a lean information architecture and efficient execution;
- Analyse, prototype, test, and iterate on user flows;
- Hand off the final designs to the development team;
- Maintain the backlog, plan the sprints.
It looked simple enough at first:
Why this approach failed:
Precisely because the pattern was so familiar, creating a username and a password triggered the “my account has been created, I am in” perception, which was false.
I witnessed users try to log in repeatedly, thinking that being stuck on a screen that instructed them to continue the application process was a bug. They expected to immediately access the investment platform, regardless of the copy on the screen.
It was, of course, not a bug but the core dysfunction of the overall signup flow.
Key distinction:
The password creation step carries a strong signal: I have an account, I am in. Placing it after approval meant that the signal fired at exactly the right moment, precisely when a person could close the signup loop and finally access the platform.
We also didn’t need to store the unnecessary credentials.
↓
Signup flowchart for a Wealth Owner / Family Officer:
Internal stakeholders and their needs:
- Member Manager — needs comprehensive information to verify identity and track down missing information;
- Philanthropy Coordinator — needs specific details about complex legal structures (foundations, trusts).
- Business Developers — need to evaluate partner applicants (project developers, investors, wealth managers) against commercial criteria.
- Top Management — needs a robust overview to exercise the right of veto.
The main challenges of the project:
- Several types of memberships entail complex flows for one feature;
- Different stakeholders have different needs;
- Backend complexity.
Language as a design decision
Many legal terms in Germany and across the DACH region lack accurate English equivalents. A linguistic patchwork within a single form seemed to be terrible UX.
Research, however, proved my intuition wrong: even English-speaking members were familiar with and even preferred precise German legal terms over ambiguous approximations.
Registering as a philanthropic organisation had by far the most complex flow, because it required the applicant to provide accurate legal details regarding:
- the foundation, its track record and credibility;
- the founder or grantor;
- the person applying.
Here is how I reduced friction:
Surprises and learnings:
- Stakeholder vs UX best practices. Member managers have legitimate reasons to request more information, as additional data points mean fewer gaps and less back-and-forth. But every form field is a cost the user bears, before they can even get anything in return.
- A complex “source of truth”. Some information appeared in the CRM twice, because what prospective members wrote about themselves was not always accurate or constructive. It matters where the information came from: direct disclosure, a self-assessment, or a subsequent correction.
- The Norman Door problem. Usability testing is both humbling and perplexing. Watching someone navigate a form that seemed “simple” and “clear” to us was very insightful. One should not rely on tooltips or copy to clarify an unconventional pattern.