We don't design apps for everyone
Cimnold builds mobile interfaces for clients who know what problem they're solving and need execution that matches their intent.
How the process actually works
Start with a problem definition session where you explain what users struggle with and what outcome you're measuring. We sketch structural options within two days and present them with reasoning attached.
Revisions happen in cycles — you test a version with real users, report what failed, and we adjust based on observed behavior rather than preference. The timeline stretches or compresses depending on how quickly feedback arrives and how often the core premise changes.
Adapting to constraints you didn't plan for
A fintech client needed onboarding redesigned after their compliance team added three mandatory disclosure screens post-launch. We restructured the flow to fold disclosures into existing steps without adding friction — completion rate recovered to 78% within two weeks. Another project involved a fitness app where users abandoned setup at the goal-setting screen. Removed the screen entirely, inferred goals from activity patterns instead, and retention improved by 34 percentage points.
The specific problem this solves
Users abandon apps because the interface demands effort the user didn't agree to spend. Registration asks for data the user doesn't have ready. Navigation hides the one feature they opened the app to use. Confirmation dialogs interrupt tasks that should flow without friction.
Reducing cognitive load
Every screen should require one decision maximum. When users face multiple choices simultaneously, completion rates drop regardless of visual polish.
Eliminating unnecessary steps
Map every screen to a user goal. If a screen exists to satisfy internal process rather than user need, remove it or merge it into a necessary step.
What separates this from template-based design
Templates optimize for visual consistency. We optimize for task completion under real conditions where users are distracted, impatient, and unfamiliar with your product category.
Behavior-driven iteration
Design decisions come from observing where users hesitate, misinterpret, or abandon — not from aesthetic preference or industry convention.
Context-specific patterns
Navigation structure changes based on how users actually move through your app, not how similar apps organize their menus.
What this approach doesn't cover
-
Brand identity development — if you need logo design, color palette creation, or brand guideline documentation, that requires a separate engagement with a brand specialist.
-
Marketing site design — this focuses exclusively on in-app experience. Landing pages, promotional content, and acquisition funnels fall outside this scope.
-
Implementation without testing budget — the method depends on iterating based on real user behavior. If you can't allocate resources for user testing, the process won't function as intended.
Who handles the work
Three designers with overlapping but distinct expertise. Each project gets assigned based on domain fit — fintech goes to someone who has designed payment flows before, health apps go to someone who understands regulatory constraints in medical interfaces.
Liora Vexler
Interaction designer
Spent six years at a banking software company designing transaction flows and approval processes. Specializes in interfaces where error prevention matters more than visual novelty.
Tamsin Okafor
UX researcher
Runs usability tests and analyzes session recordings to identify friction points. Background in cognitive psychology informs how she interprets user behavior patterns.
Dren Krasniqi
Visual designer
Translates structural decisions into polished interface components. Previously worked on accessibility-focused government portals where contrast ratios and touch target sizes were non-negotiable requirements.