Rele: Connecting Design to Development
An engineering handoff guide for the v0.2 mobile MVP.
Project: Rele mobile app
Focus: Design documentation, implementation priorities, and interaction requirements
Deliverable: Engineering guide with supporting screens, flows, and specifications
Stage: MVP planning and handoff
Project: Rele mobile app
Focus: Design documentation, implementation priorities, and interaction requirements
Deliverable: Engineering guide with supporting screens, flows, and specifications
Stage: MVP planning and handoff
About the project
Rele is a social platform that encourages casual sharing, local discovery, and real-world connection. Its proposed mobile experience includes communities, personal profiles, content creation, messaging, and a marketplace. After outlining the user journeys, I needed to make the design requirements easier to communicate to engineers. Screens could show what the app should look like, but the handoff also needed to explain how interactions should behave, which features depended on others, and what belonged in the first release.
My role
I defined the product requirements and directed the preparation of the v0.2 engineering handoff. My contribution focused on communicating intended behavior, identifying important states and exceptions, and connecting the proposed interface to implementation priorities.
The guide brought together user flows, screen references, layout specifications, accessibility requirements, and initial engineering tasks. It also identified decisions that were still open so they would remain visible during development.
The challenge
The main challenge was documenting a product with many connected features while keeping the first build manageable.
A community membership could depend on approval or payment. A published post could have different visibility and interaction settings. A business profile needed to distinguish identity verification from permission to sell.
These relationships were not always visible in a mockup. Without written guidance, engineers would have to interpret behavior that the design had not fully explained.
Establishing what to build first
I organized the proposed scope into implementation priorities and paired those priorities with initial engineering tasks.
Core experiences needed foundations such as authentication, navigation, reusable interface components, and access rules. More advanced capabilities, including external publishing integrations and expanded creator tools, introduced additional dependencies.
Documenting those relationships helped turn a broad feature list into a more structured starting point for development.
Connecting flows, screens, and behavior
The handoff used consistent references to connect each user flow with its corresponding screens and actions.
For an interaction, the team needed to understand where it began, what the user could do, and what should happen next. Where relevant, the guide also described the condition that had to be met before someone could continue.
This created a way to trace a requirement across the experience and discuss a specific behavior without relying on a screenshot alone.
Explaining the states between screens
I paid particular attention to situations where the interface needed to explain an incomplete action. For the marketplace checkout, the guide distinguished a confirmed order from a pending or failed payment. A pending payment should not encourage someone to pay again before the original transaction is resolved.
Community access required similar clarity. Requesting membership, waiting for approval, and entering a community were separate states, each with a different meaning for the user. Documenting these transitions made the proposed behavior more explicit.
Making privacy an implementation requirement
Rele’s privacy options needed to work consistently across profiles, posts, and communities.
The handoff separated audience visibility from interaction permissions. Who could view a post was a different decision from whether someone could comment on or share it.
It also specified that restricted content should not automatically become public through an external sharing connection. These requirements helped communicate that privacy depended on the underlying access rules as well as the controls shown on screen.
Documenting accessibility and consistency
I included specifications for spacing, component dimensions, touch targets, typography, and light and dark themes.
The mobile references used a 390 × 844 design canvas, while the guide called for checking narrower screens and enlarged text. Interactive targets were specified at a minimum of 48 × 48, with visible navigation alternatives to swipe gestures.
The guide also documented contrast and status communication requirements. These specifications established expectations for implementation; they did not replace accessibility testing of the working app.
Keeping unresolved decisions visible
Some capabilities were still being explored, particularly advanced creator features and third-party integrations.
I kept those areas marked as future scope or open decisions rather than presenting them as completed product requirements. External connections also needed to account for provider permissions, eligibility, and unsuccessful responses.
This helped distinguish the intended experience from the details that still required technical investigation or a product decision.
The outcome
The project resulted in a 36 page engineering guide for Rele v0.2, supported by user flows, screen references, design tokens, and structured behavior specifications. The handoff provided a concrete starting point for estimating work, discussing dependencies, and reviewing implementation questions. At this stage, the result was a planning and communication deliverable; its effectiveness would need to be evaluated through engineering feedback and the working product.
What I learned
This project helped me think beyond the appearance of an interface and describe the rules that make it work. I learned to examine the moments between screens: what the system is waiting for, what gives someone access, and what happens when an action fails. Making those details explicit became an important part of communicating the design.
