Design terms, explained without the jargon.
Wireframe
A basic layout of a screen. Think of it like a floor plan. It shows where everything goes, but there's no colour or detail yet.
Prototype
A tappable version of your app that you can use on your phone like it's real. It's not built with code, but it feels like it is. This is the main thing I deliver.
High fidelity design (Hi-fi)
The final look of every screen. Colours, fonts, icons, images, spacing. What your app will actually look like when it's built.
Low fidelity design (Lo-fi)
A rough, early version of your screens. No polish. Just layout and structure. Getting the bones right before we invest in the detail.
MVP (Minimum Viable Product)
The simplest version of your app that still solves the core problem. It's not half arsed. It's smart. Launch small, learn from real users, build from there.
User flow
The path someone takes through your app. Open the app, sign in, do the thing, come back tomorrow. I map all of these out so nothing gets missed.
Figma
The design tool I use. Industry standard. Your developers will use these files to build the real thing. You get all of them.
Developer handoff / implementation notes
Detailed notes that tell a developer exactly how to build each screen. Spacing, behaviour, interactions, edge cases. The better these are, the faster and cheaper your build. Because I've got developer experience, mine cover things most designers miss.
Stakeholder interview
A proper conversation at the start where I learn everything about your idea, your business, and your users. This is the foundation. Everything else is built on it.
App Store assets
Your app icon is included in every project — designed to work at every size, from a phone home screen to the store listing. The promotional screenshots you see on App Store and Google Play listings are available as an optional extra you can add anytime.
Front end
Everything the user sees and touches. The screens, the buttons, the layout, the colours. If it's on screen, it's front end. This is the part I design and lightly code as part of every project.
Back end
Everything that happens behind the scenes. Storing data, processing payments, sending emails, checking logins. You never see it, but it's what makes the app actually work. This is what your developer builds after the design is done.
Server
Just a computer somewhere else in the world. When your app saves data or loads information, it's talking to a server. You don't own it or manage it. It's rented from companies like Amazon, Google, or similar, and your developer sets it up.
API
A way for your app to talk to other systems. When your app pulls in a map, processes a payment, or sends a notification, it's using an API. Think of it as a messenger between your app and another service.
Native app
An app built specifically for iPhone or Android and downloaded from the App Store or Google Play. It lives on your phone, can send push notifications, and generally feels the smoothest. Most apps I design are intended to be built as native apps.
Web app
An app that runs in a web browser instead of being downloaded from the App Store. You open it like a website, but it behaves like an app. Cheaper to build, works on any device, but doesn't have full access to phone features like push notifications or the camera.
Database
Where your app stores its information. User accounts, orders, messages, settings. It's a structured filing system that lives on a server. Your developer chooses and sets this up during the build.
Deployment
The process of putting your finished app out into the world. For native apps, that means submitting it to the App Store or Google Play. For web apps, it means putting it on a server so people can access it. Your developer handles this.
User persona
A made-up profile of someone who'll use your app. Not a vague demographic, but a real-feeling person with a name, a job, and specific needs. Based on real research, not guesses. These keep design decisions grounded in reality instead of assumptions.
Feature backlog
A running list of every feature idea for your app. The good ones get ranked and built into version one. The rest are parked with context so nothing gets lost and you can revisit them for future versions.
Brand style guide
A cheat sheet of your app's colours, fonts, icon style, and visual rules. It keeps everything consistent during development and gives you a foundation for marketing materials, websites, and anything else that needs to match your app's look.
User roles / user types
Different kinds of people who use your app. Like a customer, an admin, or a manager. Each one sees different screens and has different permissions. More user roles means more complexity and more screens to design.
Core flow
The main thing your app does. The one key path a user takes — like placing an order, booking a ride, or submitting a report. Getting this right is the single most important part of the design. Everything else is secondary.
Scope
How big your app is. How many screens, how many features, how many user types. Bigger scope means more time and more cost. One of the first things I figure out with you is the right scope for version one.