WeCheck
WeCheck builds financial and rental products for landlords, tenants, and property professionals.
I joined as the company’s first Product Designer, working across product strategy, UX, UI, and the design system. Over time, the work expanded from individual user flows into a connected ecosystem of tenant screening, rental guarantees, property management, reports, and financial products.
Ecosystem
A rental process rarely involves a single user or a single action.
A landlord can add a property, invite a tenant to complete a screening process, review the resulting tenant report, add the tenant to the property, and later purchase a rental guarantee.
For the business, these experiences were also connected. Tenant screening - Double Check - was an important entry point into the broader product ecosystem and created a natural path toward additional financial services.
The challenge was to make this connected system feel simple without hiding the information users needed to make important decisions.
The challenge
Many of WeCheck’s products are built around processes that are complex by nature.
Tenant screening, rental guarantees, and financial services can require personal and financial information, eligibility checks, verification, multiple decisions, and actions from more than one person.
The challenge was not simply to reduce the number of steps. Many of them were necessary.
Instead, I focused on reducing the perceived complexity of the process - breaking long journeys into smaller, understandable tasks, asking for information only when it became relevant, maintaining context between steps, and making the next action consistently clear.
At the same time, these products required a high level of trust.
Users needed to understand why sensitive information was being requested and what would happen next. The initial instinct was often to explain more, but putting everything upfront resulted in dense screens, long paragraphs, and unclear priorities.
This created two connected design challenges:
How do we make a process with many required steps feel simple and manageable?
And how do we provide enough context to build trust without adding another layer of complexity?
Learning from real product behavior
Design decisions were informed by a combination of behavioral data and direct feedback from across the company.
We looked at product analytics and Hotjar behavior, recurring questions reaching customer support, conversations with customers and internal teams, business requirements, and patterns from competing products.
Rather than treating each source independently, I looked for recurring friction across them.
Three principles repeatedly shaped the work:
Reduce what users need to understand at once.
Complex information should be introduced when it becomes relevant.
Make the next action obvious.
Supporting information should not compete with the primary task.
Design connected patterns, not isolated screens.
If the same problem appears across products, the solution should become reusable.
Double Check - the core journey
Double Check allows landlords to invite a tenant to complete a screening process before moving forward with a rental relationship.
From a product perspective, the flow connects two different users and several different stages:
Landlord creates the request → Tenant completes the screening → Landlord receives the report → A rental decision can be made → Additional services such as a rental guarantee become relevant.
The experience therefore needed to work on both sides.
For landlords, sending the request needed to feel quick and actionable.
For tenants, the process needed to communicate why information was being requested, what would happen with it, and how far they were from completion.
Explanation to hierarchy
One recurring issue was the amount of explanatory content inside the product.
Adding information made sense from a business and support perspective: the more users understood, the fewer questions they might have.
But in practice, placing too much explanation at the beginning of a flow made the interface harder to scan and reduced the prominence of the main action.
Instead of removing important information, I reorganized it.
Primary actions and essential context remained visible.
Supporting explanations moved closer to the moment they became relevant.
Longer processes were broken into clearer steps so users only needed to focus on the current task.
The goal was not to show less information.
It was to create a clearer order for understanding it.
Turning screening into a usable report
Once a tenant completed Double Check, the landlord received a report containing the information required to evaluate the rental relationship.
The challenge shifted from collecting information to organizing it.
A report could contain multiple types of data, but not every detail deserved the same visual weight.
I structured the experience around progressive levels of information:
Overview
The most important information needed for an initial understanding.
Key details
The data most relevant to the landlord’s decision.
Deeper information
Additional context available when needed.
This approach allowed the report to remain detailed without turning every piece of information into a competing focal point.
Designing property management
As the product expanded, landlords needed more than individual rental flows.
They needed a place to manage properties, tenants, screening requests, statuses, and actions over time.
This changed the design problem significantly.
Mobile flows are often focused on completing one task. A management product needs to help users understand many things simultaneously:
what needs attention, what changed, which property or tenant is affected, and what action is available next.
The web experience therefore relied more heavily on hierarchy, status systems, repeated actions, and reusable data patterns.
Instead of designing one screen at a time, I approached the product as a system of connected objects:
Properties → Tenants → Screening → Reports → Guarantees → Statuses and actions
This became an important part of making WeCheck scalable beyond individual transactions.
Creating reusable product patterns
As more products and flows were added, inconsistencies became increasingly expensive.
Forms, status indicators, actions, feedback states, navigation, and financial interactions appeared across different parts of the ecosystem.
I helped establish reusable UI and interaction patterns that could support both mobile flows and more complex web products.
The objective was not only visual consistency.
A shared system meant users could apply knowledge from one part of the product to another, while the product and development teams could build new experiences from established patterns instead of starting from scratch.
Outcome
A major part of WeCheck’s evolution was moving processes that previously depended on customer-service involvement into digital product flows.
As more of these actions became available through the product, up to roughly 50% of work that had previously required customer-service involvement moved into digital self-service.
The impact was both operational and experiential.
Users gained more independence, while the product became capable of supporting more of the rental journey directly.
For me, the project evolved from designing individual interfaces into building a product language for an increasingly complex ecosystem.