Mobile First Design makes more sense because it forces you to create with attention to detail and purpose. It’s what separates the designers who prioritize function, from those who just try to make things look pretty.
There’s nothing wrong with pretty ✨ don’t get me wrong, but it’s the last step in the design process, not the first.
Since 52% of the webs traffic is mobile, size truly does matter. And as many already know, in terms of a digital product’s usability, when you’re working with smaller hardware it requires more skill to get the job done.
First, Let’s Define What “Mobile First Design” Even Means
Mobile First Design –– A design methodology wherein the smallest screen size is considered first, and subsequently prioritized in each design decision, creating a core basis of what is truly essential, from which the details of your design can expand to fill a larger medium. ⌚️ » 📱 » 💻 » 🖥
This is my own, more precise & accurate definition of Mobile First Design, though it is most commonly defined as:
A design philosophy that aims to create better experiences for users by starting the design process from the smallest of screens: mobile. Designing and prototyping your websites for mobile devices first helps you ensure that your users’ experience is seamless on any device. –– InvisionApp
But since Mobile First promotes purpose and precision, I’d like to be as clear as possible about my thought process in regards to Mobile First.
Why You Should Care
It’s a lot easier to add new stuff to a design, than it is to trim things down. This is true in terms of not only Design, but also for the Development process. It’s also, just to put it bluntly, much less of a pain in the ass.
Even the mental model of creating Mobile First is easier to grasp in terms of responsive design. It follows natural human patterns far better than not-mobile-first and will become more intuitive as you become familiar.
Worst Case Scenario isn’t as Bad 💥
Something that I don’t see mentioned often when it comes to MFD is that when projects get derailed, (delays, disagreements, etc.) and you’ve got an un-finished MVP pushed up to production, it is MUCH better to have a mobile-intended design show on desktop than it is to have a desktop-intended design showing on mobile.
“But I wouldn’t have an un-finished MVP pushed up to production why would anyone do that?”
Life is chaos.
If you’re not prepared to radiate excellence despite that one idiot steak-holder that you can’t say no to, then you’re not prepared to work in tech.
Ok, so you can still technically work in tech, you just wont climb.
There’s one key difference between a derailed Mobile First project and a derailed Desktop First project is that in the Mobile First scenario, your product is guaranteed to function, even if it looks a little odd. The same cannot be guaranteed for the latter.
We as professionals in our craft, seek to build contingency plans into our processes wherever possible. This isn’t just about craftsmanship, it’s also about covering your ass.
How Mobile First Design Makes Your Designs Straight Up Better
Have you ever scrolled through a bunch of designs and for some reason certain ones have an almost un-definable “betterness” to them? The typography flows better, the images synergize with their surroundings, the sections fit together in a way that feels like everything is exactly where it should be, etc. …
If you’re a seasoned designer you already know where I’m going with this.
Proportions. Attention to Detail.
Nail those (lol harder than it looks 😉) and you’ll never have work in short supply.
Freedom, Like All Aspects of Life, Has a Spectrum of Quality
When you start with a mobile screen around ~376px it limits what you can create substantially. As creatives, too much freedom can spell disaster in the form of; decision paralysis, over-designing, making things too busy, loosing track of objectives, and just generalized weirdness.
The Mobile First philosophy gives you an initial constraint, with the subsequent screens’ design constrained by your initial mobile screen design. There’s a lot less room for spiraling.
To put it Professionally™, you are reducing the risk of Design Debt, as defined by UXDesign.cc –– “In simple terms, design debt is all the good design concepts or solutions that you skipped in order to reach short-term goals.”
And just like student loans, it can be very hard to get rid of. And it WILL follow you.
You’ll Start Thinking Differently
When you are forced to stare at a phone-sized-canvas as Step #1, you’ll start thinking like a real UX Designer. You’ll quickly realize that you need to define usability objectives.
Useful Questions to Ask:
- What is the most crucial, and/or commonly used piece of functionality I need to design?
- How many clicks, and/or thumb movements does it take for a user to achieve their main objective?
“Users must be able to add an item to their cart in three clicks or less from any starting location”
“Users must be able to view their bank account balance as soon as they log in”
“Users must be able to comfortably re-arrange files with one hand”
You get the idea.
Those objectives you define are where design-constraint gradiates into the beginnings of a design framework. Your design framework. From your own brain. Pretty Metal 🤘🏻🎸🔥
You’ll start considering who your users are, what functionality needs to be included, and what is actually critical for users to be able to do with ease. On mobile.
What if I’ve Been Designing Desktop First & Am Having Trouble Switching to Mobile First Design?
You’ll want to choose a common phone size a few generations back as your starting point. As a guide, a liberal mobile portrait screen size range is about 320px – 414px.
In an age when it’s expected for everything to at least be functional on every screen size, & where there are a seemingly infinite number of screen sizes, responsive design can seem a little intimidating for both designers and developers unfamiliar with it.
Especially if you’re new.
Don’t Overthink it
The good news is, it’s not hard. If you start with the smallest screen size first, it makes your whole process go much smoother. The traditional method of designing for a standard desktop screen first is obsolete, and in fact more difficult than mobile first.
[galaxy brain meme]
Some Simple Rules to Get You Started
- Push back on any ridiculous “make the logo bigger” requests, in an assertive and professional way. This will make your mobile nav take up wayyy too much space.
- Start with the nav bar/header first, and make sure you really go all in on the mobile navigation functionality. It’s a pain in the ass and you’ll be glad it’s out of the way later on. Then design the footer/bottom bar.
- Focus on typography. Make sure you don’t use text smaller than ~16px unless strictly necessary. Account for long words that break onto a second line, in the largest font you’re using. Use 2 fonts only. You’ll thank me later. So will your developer.
- Pay attention to content length. Don’t make your users’ thumbs sore.
- Pay attention to how easy it is to reach buttons/links/other clickable elements. What if someone with small hands or arthritis or someone who doesn’t want to take their hand all the way out of their sleeve in cold weather, or whatever other finger-movement-limiting conditions may occur.
- Make sure anything that needs clicking, is big enough that someone won’t struggle to hit it, and not too close together to avoid accidental clicking. Here’s an MIT Study on this along with Someone Else Explaining What it Means.
- Make sure you indicate a thing is clickable whenever reasonably possible, or where clickability may be unexpected.
- Make sure you hand-off your design with a list of explicitly defined breakpoints. Your dev will ask for them, or worse, they wont and they’ll guess.
If you’re new to design overall, these are still very useful but this is not a complete list of general design fundamentals.
For more beginner-geared content you can check out:
Rules You Can Break 🙃
Sometimes we just need to color outside the lines a bit. Don’t beat yourself up about things not being perfect, or if you can’t strictly adhere to the aforementioned guidelines for whatever reason.
Projects, like life, never go as smoothly as planned. So don’t panic if your design process hits turbulence.
Rules are meant to be broken. So here’s a list of acceptable losses:
1. You can start on the desktop/tablet design before the mobile design is complete. 🧩
Sometimes inspiration strikes, or an overly complex feature is axed for mobile but needs to be designed on for desktop asap, or you may have even encountered the not-completely-unheard-of scenario of needing to design for two or more screen sizes at the same time due to co-dependent functionalities.
It’s ok. The only truly crucial rule is that mobile usability is never sacrificed over usability for larger screen sizes. Because that will come back to haunt you and sooner than you think.
2. The core functionality does not have to be included on mobile. 📵
If you’re building something like an analytics dashboard or some other complex thing that simply can’t be appreciated in all it’s glory on a small screen, it’s ok to not include the full functionality on mobile.
You should still try your very hardest to make as much functionality as possible work smoothly on mobile. If you get stuck on a decision, just close your eyes and imagine you’re using the thing you designed. If you hate it, or even worse, can’t picture it, go back to the drawing board.
If all else fails, create a representation of what the full larger-screen-required functionality will be for mobile. Almost like a sales pitch/brochure/tutorial.
People who use technology often do so knowingly to their own detriment. You don’t want to give a user the option to have a bad experience. If it’s between making a user wait until they’re at their desk, or having them throw their phone out of frustration on their commute while trying to use a complex tool, which do you think is preferable?
Sometimes having no user experience is better than having a bad user experience. Bad experiences last in peoples minds, you want to set your users up for a good first impression.
3. Mobile First doesn’t always mean Phone First. 🧐
Mobile First Design just means your starting point is the smallest device that the website/app/product will need to work on. This can mean a small tablet, or smartwatch, or any number of things, including regular old laptops (which are technically mobile devices).
The craft of software design has become so diverse that “Mobile First” can even mean the smallest screen size is your laptop, and the largest screen size is an 80 inch smart TV. The possibilities are endless.
Choose the starting point that makes sense for your use case.
4. Often, the mobile version of a design can serve as an ideal tablet version and does not require a tablet version to be designed.
Ok, so I know I just heavily insinuated that you ALWAYS need to account for all screen sizes, but that’s the beautiful thing about Mobile First, often the gaps will fill in themselves (for simpler designs, like standard websites).
In the example above, there are no elements that are complex enough to need explicit mockups for tablet because:
- The navigation only has a few items that don’t get clipped on tablet portrait sizes.
- The content is either just text, or stack-able items like icon + caption sub-components.
There are few areas of design where you’re better off allowing the developer to use their judgment to fill in the gaps, but in most standard web/app projects there is little to no difference between the tablet and desktop versions of a screen.
When it comes to tablet, in most cases it’s best to fix any small inconsistencies for tablet in the QA process after the initial implementation of the design.
Why? Because you don’t want to-redo work. The developer will have to create a mobile version first, then a desktop version. This means that the instructions coming from you (the designer) to the developer may need to at some point include instructions for how to handle certain things in the tablet version.
You can either deliver that information via a few lines of text in an email, PMS, messenger, etc. or you can spend time mocking up a whole version for tablet with maybe one or two elements needing to be slightly different.
This means that your developer needs to wait for you to create an entire third set of mock-ups, instead of just getting started on the desktop version as soon as they’re done with mobile.
In terms of front-end-development, adding a break-point (screen size) in-between two already coded break-points is much easier than it is in the design leg of the process.
This costs you time, witch will likely cost your team time, creating more chances for the project to be derailed.
So, don’t waste time on creating a third version of a mockup if it adds no value to the project. That time and mental energy is best spent refining, and iterating on features that elevate the delivered product.
Mobile First Design saves you headaches, time, and makes the end product a lot better. It adds vital structure and foundation to a software design project that serves as insurance against project pitfalls.
This is not meant to be a rigid structure to adhere to, but a shift in mindset and methodology.
Thank you for reading 💙💜💖✨😊