Summary
You’ll have a single set of screens and flows that product, design, and engineering can read the same way, with the tricky decisions made early and recorded right on the work.
Most teams reach out when a feature needs to ship, but screens keep turning into opinions and half-finished frames. I’ll turn the feature into a set of decided flows, annotated screens, and a Figma library engineering can build from. Next I’ll confirm the journey, screen count, and review points.
I run the work through one shared place in Figma, with decisions written down where they’re made. I start by auditing what you already have and capturing notes, then map one key journey end to end. From there I move from wireframes to high-fidelity UI, and finish with components and tokens so the build stays consistent.
Who you are working with
I’m Maja Kristensen, a product designer focused on apps. I got into this work by shipping features alongside engineers, then watching good ideas stall because nobody agreed on what the screen meant. These days I’m brought in when an app needs one consistent direction, fast enough for a release cycle and clear enough for a build.
I’m picked when the risk is misalignment between Figma and engineering. I don’t hand over pretty frames and hope. I write decisions into the file, I annotate the edge cases that usually become Slack threads, and I keep reviews on a small set of screens so you can approve a buildable slice, not a vague direction.
Recent projects
Here are a few app projects where the goal was fewer opinions, faster sign-off, and screens engineering could ship without guesswork.
Portfolio
SaaS onboarding redesign. Rebuilt onboarding around one primary journey, then rewired empty states and error handling. The result was a shorter path to first value and fewer back-and-forth questions during build, because the flow and copy were decided together.
Billing and plan change flow. Redesigned the upgrade and downgrade flow with clearer plan comparison and confirmation steps. Support edge cases were captured on the screens, so engineering didn’t have to infer rules from a prototype or Slack messages.
Design system setup in Figma. Turned a growing set of one-off UI into a component library with tokens and naming that matched engineering usage. New screens started moving faster because common patterns were pull-and-use, not redraw-and-debate.
“The screens were easy to build because every decision was written down.”
Product manager, a mid-sized SaaS company
Audit notes pack
A Figma file with commented screenshots and a short written summary of what’s working, what’s inconsistent, and what will block the new feature if it stays as-is.
ONE JOURNEY FLOW MAP
A clear map of one key journey, including branches and edge cases. It gives product and engineering one shared picture of what you are building.
KEY SCREEN WIREFRAMES
Wireframes for the core screens in the journey, with structure and content priority decided before visual styling pulls the conversation sideways.
High-fidelity UI screens
Ship-ready screen designs for the agreed scope, with annotations for tricky interactions and states so engineering is not guessing from pixels alone.
COMPONENT LIBRARY AND TOKENS
A Figma component set and basic tokens that match the screens, so new UI stays consistent and future work starts from reusable parts, not copies.
CLICKABLE PROTOTYPE
A prototype used for stakeholder review and walkthroughs. It’s designed to answer, "What happens when I tap this?", before engineering starts.
What it costs
Pick the tier that matches how much of the app needs to change right now. Each tier includes the full flow from audit through high-fidelity screens and a prototype.
Priced items
Next steps
If you’d like me to hold time for this, the next step is a signed proposal and the booking invoice.
1. Sign this proposal to book the work. 2. Pay the 50% booking invoice within 14 days. 3. Send access to your Figma and app build so I can start the audit.
Signature
Fee summary
What do you need from us before you start?
Access to your current Figma files, the app build or a staging link, and one person who can answer product questions quickly. I’ll also ask for any existing analytics, support themes, and the success measure for the feature so decisions have a target.
ARE YOU DESIGNING FOR IOS, ANDROID, OR BOTH?
I can design for iOS, Android, or both. Before I start screens, I’ll confirm whether you’re using native patterns, a shared design language, or one codebase, because that choice changes components, spacing, and what “done” means for engineering.
How many screens are we talking about, roughly?
Most feature pieces land between 12 and 30 screens once you count states, empty cases, and errors. After the audit and flow map, I’ll give you a screen-count range for sign-off so you can plan the build without surprises.
HOW DO WE STOP THIS BECOMING ENDLESS ITERATIONS?
I keep feedback to two planned review rounds at wireframe and high-fidelity, with comments in one place in Figma. Each round ends with a written decision list so you can close topics and move forward instead of reopening them later.
Payment
To book app product design, I invoice 50% when you sign. I invoice the remaining 50% when the finished work is handed over. Each invoice is payable within 14 days.
What I need from you. Before I start, I need access to your current Figma files and the app build or a staging link. I also need one person who can answer product questions quickly during reviews.
Platform decisions. I can design for iOS, Android, or both. Before screens, you’ll confirm whether you’re using native patterns, a shared design language, or one codebase, since that choice changes components and specs.
Review rounds. My process includes two planned review rounds, one at wireframe and one at high-fidelity. I keep comments in one place in Figma, and each round ends with a written decision list.
Changes to scope
After the audit and flow map, I’ll give you a screen-count range for sign-off. If the range grows because the feature expands or new journeys get added, I’ll price the extra screens before I design them.
Timelines and pauses. Dates depend on how quickly reviews and decisions land. If feedback is delayed, the schedule shifts by the same amount. If the project pauses for more than two weeks, I’ll confirm a new slot.
Handoff and ownership. Once the final payment is made, you own the finished design work I’ve produced for this project. I keep working files in Figma so you can build from the same source engineering reviewed.
