Shift Nudge - Interface Design Course - Pro - Tactics - 1

No-stress Design Experiments

It can be overwhelming to get started on the visual design of a new project. You want it to look so good, but often times the first thing you put down on the canvas is not very good.

It can be an emotional experience to try so hard to make a good design and have a strong opinion that it’s coming up short and just simply doesn’t look good.

Good design can sometimes be subjective if you aren’t fully aware of the full project’s landscape—including but not limited to the team, the stakeholders, the brand, the desired look and feel, etc.

That’s where this “no-stress” process comes into play. This is an easy process to follow that sets you up for design success. It arms you with the necessary information to make good decisions on behalf of everyone involved.

It goes something like this:

  1. Ask questions
  2. Determine design direction
  3. Focus on components instead of the full design
  4. Lead conversations over presentations

It’s important to note that this is note some 1, 2, 3, 4 paint by number approach that will be nice and tidy. You may do all of these at the same time, over and over. It can be messy, but use this as a general direction to keep things on track.

1. Ask Questions

Ask lots of questions about the problem you are tasked to solve with design—anything you can’t confidently explain to someone else about the project you’re designing for.

It’s your job to understand it fully and know what assumptions you’re making before designing anything. ASK LOTS OF QUESTIONS.

Who are the stakeholders? Stakeholder is a fancy term for the person who has skin in the game. Is it the CEO? Project Manager? Creative Director? Is it a client? Do they have a boss that will approve or deny the designs? You need to know everyone who will be involved and any potential person that might have an influence on the design or the opinions of anyone in charge.

Who makes the final call? Do all of the stakeholders agree on the specific problem they’re trying to solve. Do they all agree on the reason for bringing on a designer? Do they have strong opinions about what it should look like? To make it look better, yes… that’s ALWAYS one of the reasons, but we need to make sure we understand the actual problem.

Sometimes it’s easy to understand, other times, it’s more complex. Do your homework on everyone involved!

Is there an existing brand? Can it change some? If not, why not? Ask questions. =)

Sometimes this can materialize in the form of reference material presented to the client or team early on. What if our designs were bold and “chunky” like Pinterest? What if our designs were colorful and friendly like Crayola? What if our designs were toned down and simple like Notion?

Having the answer to these questions will help point you in the right direction. Knowing the opinions of those involved, coupled with adjectives and reference material can be the secret sauce to getting started.

2. Determine Design Direction

Assuming you’ve got most of your questions answered, you can start thinking about design direction for the project.

This will include:

  • What have you learned so far that will help you choose a typeface or a typeface style?
  • What have you learned so far that will help determine the type of layout that should exist? Lots of negative space? Text-heavy blog pages? Card-based modules? Sticky navigation? iOS app? Responsive web app? Hamburger menu? No hamburger menu?
  • What sites or apps exist that seems to have (or come close to) the same type of “style” that you’d like to have for your project?
  • Pulling screenshots and possibly making a deck to present in an quick visual research meeting

This is when you will flesh out your “Art Direction” and set a visual path for the finished product.

3. Focus on Components

There are great benefits of designing individual components in isolation vs. “the actual thing.” Think of this as a small sketch of a detail that will eventually be used in a large painting. You can take the pressure of the blank canvas syndrome by designing components and pieces of the thing you’re working on—out of context of the full designs.

RED – Design experiment file

Here’s an conceptual design I put together by taking screenshots from and reimagining a nicer layout for their extremely expensive cameras.

Note that I’m focusing on a combination of various components both in isolation and in context with each other. It’s not a full redesign, but it’s shows an example of how this direction could work if it were to be pursued.

Design little pieces and make a mess—only organize it slightly when you’re ready to present either in-person or via screenshare.

More Project Examples


4. Conversations over Presentations

Let your experiments lead to a conversation about the design vs. a big official presentation.

Leading your first design review for the project can be intimidating, but set expectations by saying you want to make this a conversation about possibilites vs. a strong recommendation that you are presenting.

Come equipped with a few different styles, but also ideally with something you are leaning towards. Try your best to detach your own personal ego from the designs and sit on the side of the team critiquing and critique alongside them as if you didn’t even design them.

Make it clear that there is nothing her to “approve” but rather your trying to get the design needle pointed in the right direction by showing concepts early and getting feedback on general direction.

This will build trust with the people you’re working with and they will be less likely to have strong negative opinions, as they may if you design in secret for a long period of time and do a big unveiling.

Watch this homework review video below to hear a good rant about no-stress design experiments and the value that design dead ends provide. :+1:


Design a small concept project that’s for a dream client of yours. Do your best to answer the questions posed in the No-stress process.

  1. Ask questions (but in this case you’ll have to make assumptions and educated guesses because you won’t necessarily have anyone to field your questions.
  2. Determine design direction. Use adjectives. Grab reference material. Experiment.
  3. Focus on some key components rather than an entire full and complete design. You can definitley use sections or mobile screens to contain some of your designed assets, but it’s more important to focus on a soft approach to what “could be” versus “this is what it is”
  4. Write a paragraph or two of text that explains your decisions based on the information gather in steps 1-3. If you’ve never done this before, it can be challenging to put your design decisions into words. Don’t let it stop you though. Lean into the uncomfort. This is a huge part of “selling” your designs to the team or client.

Low-Fidelity Designs

First of all, this is a highly debated topic. You will hear lots of people say that wireframes are a waste of time and lots of others say they can be beneficial. My opinion lies somewhere in the middle.

I prefer the term “low-fidelity” designs vs. the term “wireframes” because the latter term has gotten a bad rap. Also low-fidelity seems to speak a little more to the true nature of what I believe wireframes should have been all along.

By using “low-fidelity” design we can effectively remove the majority of decisions around Typography, Color, Style, and Imagery. It gives us a standard vanilla “system” to use by default so we can focus on functionality first instead of the decorative-type elements.

But why would we want to do that?

When to use Low-Fidelity Designs

Creating low-fidelity designs can sometimes speed up the design process. Here are a few scenarios where low-fidelity designs might be a great starting point:

  • The project is big and complex
  • The projects’s team is large and there are mutliple stakeholders
  • The team is small, but the fuctionality is difficult to understand
  • A development team is waiting to know what to start building
  • There is confusion about functionality

Example projects where wireframes were used

When NOT to use Low-Fidelity Designs

And not to be left out, here are a few circumstances where low-fidelity designs might not be useful:

  • There is already a solid UI direction and foundation
  • The functionality is straight forward, but the UI isn’t great
  • The team is small and all generally agree about the functionality
  • The primary focus is on creating a new look and feel vs. determining functionality

Example Projects where NO wireframes were used

Here’s a little wireframing starter kit that contains Typography, Colors, and a default Style.

I personally love to wireframe using card-based layouts with painfully obvious borders. This takes advantage of the Law of Common Region. Remember the goal of the wireframe is to be extremely clear from a functionality perspective.

Twitter thread from Noah Levin, Design Director at Figma


Design a movie ticket purchase flow with low fidelity wireframes—mobile or desktop size you decide. Use the styles from the Figma file above or make your own slight modifications, but keep it super basic and simple.

Don’t spend much time on Typography, Color, Style, or Imagery. Rather focus on layout and functionality here.

  1. Screen one – List of movies playing in your area
  2. Screen two – Detail screen of movie
  3. Screen three - Select seats
  4. Screen four – Payment information
  5. Screen five – Confirmation

Mobile-First Responsive

Mobile-first, responsive design is a gargantuan topic. It includes, but is not limited to business strategy, customer experience, UX design, UI design, HTML, CSS, probably some sort of Javascript framework, lots of multi-device testing not only design, but also the live code.

There could be multiple courses created on each one of the sections mentioned and that would still only scratch the surface.

I want to cover the three most important topics on the matter that deal specificially with interface design for responsive websites.

Many of these tactics spill over into native iOS and Android design as well, especially now that there are many hybrid React or other JS-based frameworks that serve code to the web, the iOS device, and the Android device.

Here are the topics

  1. Fundamental understanding of how responsive sites work and their constraints.
  2. Examples of Why and How to design mobile-first
  3. Examples of Why and How to design desktop-first

Understanding Responsivity

To design better responsive interfaces, it’s best to have solid grasp on what’s possible within the browser. Run the pen below to see an example of changing the exact same content in a number of different layouts with a very minimal amount of code.

Let’s breakdown what’s happening in the example above.


This view shows the natural tendency of HTML on the web—left to right and top to bottom. There is a natural flow to the and it will wrap content as the viewport size allows. If you scale your browser window down, you can see the items inside of Codepen begin to wrap to fit.


This view shows a grid of items. You can decide if it’s three-wide, four-wide, or more. What used to be challenging to accomplish in the browser a decade ago is now quite simple with thanks to advancements in CSS like display: grid and display: flexbox properties.

↑ Top

This view shows an example of making the 1 module a full width block, similar to a top navigation on a standard website.

← Left

This view shows an example of the 1 module becoming a full height column on the left side of the viewport.

→ Right

This view shows an example of the 1 module becoming a full height column on the right side of the viewport. It’s worth noting that this is breaking out of the standard flow of HTML, from left to right. This is not necessarily a bad thing, it’s helpful to know what’s happening here though.


This view shows an example of the 1 and 8 modules become fixed elements on the page that remain in view at all times. This also breaks the standard flow of HTML. Again, not a bad thing, just noting what’s happening.


This view shows an example of all modules spanning the full-width of the view port, very common in mobile views or large table views that require a lot of space.


This view shows an example of how all of the blocks shown in the full screen view can also apply to smaller elements inside of an individual component. You can have multiple nested versions of these layouts within other layouts. The possibilities are really endless once you know the format.

It’s important to note that any of those examples above can be used in combination when designing and building a responsive website. Remember that websites are living, breathing things (metaphorically speaking of course) and the more you familiarize yourself with those concepts the better suited you’ll be to make good responsive design decisions.

Mobile → Desktop

It can be really helpful to think of your mobile views as mini-containers that create a larger desktop experience. Some of these mini-containers might need to expand the full-width of the desktop and change from a list view to a grid view.

Click Run Pen below (or view on Codepen) and scale your broswer window below 640px to see the grid convert to a list.

Using CSS media queries like this is no problem for a skilled front-end developer. Once you understand some of the basic principles you will unlock a lot more potential for your static designs.

Below is a similar example, but instead of going straight from a list to a grid when the browser gets larger, we are positioning a fixed width menu on the left-side while the content window 8 is still flexible. When the browser window gets smaller than 640px, the left column is hidden from view and tucked beneath a new Menu button. Click this button will give you access to the full-width rows that were once available in the left column.

One of the most imporant things to remember about responsive design is not only what happens between the extreme browser edges, but also between the edges of any particular component. All of the same stretchy, flowy, list-like, and grid-like layouts can be applied to the internal pieces of any particular component.


Fluid-width layouts coupled with media-queries are the CSS secret sauce that makes responsive design work. The code looks something like this…

If the browser is SMALLER than 640px {
	- Make the title 20px
	- Hide the navigation and put it behind the "menu" btn

If the browser is LARGER than 640px {
	- Make the title 40px
	- Show the navigation by default since there's room for it

Ok, that’s actually not what the code looks like, but that IS what the code actually does. You can make different design decisions at different breakpoints. 640px in the example above is considered a breakpoint.

The actual CSS code for something like that would look like this.

/* this sets the size for any <h1> tag in an html web page */
h1 {
	font-size: 20px;

.menu {
 display: none;

/* this size overides the one above when the viewport gets **larger** than 640px */
@media only screen and (min-width: 640px) {
	h1 {
		font-size: 40px;

	.menu {
		display: block;

And now you know how to code responsive websites.

Just kidding, but you do know that within those little brackets it’s possible to create alternate versions of the layout with a just few lines of code.

If you’re not that familiar with front-end code, then it will always be beneficial to have conversations with the developer, or a developer friend, who can answer questions about the technical feasbility of the thing you’re designing.

Communication is key.

Mobile-first (apps)

Mobile-first is my all-time favorite way to design applications, especially when there is more functionality involved than just clicking around a few HTML links to navigate a static website.

Benefits of Mobile-first design

  • Forces the prioritization of content from top to bottom
  • Allows for gradual progressive enhancement for larger screens (hover effects, etc.)
  • Complex information must be boiled down to simple flows due to space constraints
  • Can be more efficient to design for mobile than for larger screens
  • Designing for the most common scenario is always a good idea. Everyone has a phone in their pocket, but doesn’t always have access to a computer.


Back in 2013, I started very seriously getting into mobile-first design and this project was one of the most complex I’ve worked on, still to this day.

View large multi-page PDF of these wireframes

We were able to agree on functionality and layout of features because the mobile constraints forced those conversations. Only after this, did I explore what expanding these components would look like.

In the designs below you can see the same component scaled to multiple widths, showing what could/should happen to each element at different breakpoints.

View PDF

AIUX Mobile-first wireframes

AIUX was the very first course I created back in 2014 that taught “Systematic Responsive Design for the Responsive Web.” It focused heavily on using Adobe Illustrator as a wireframing tool and mixed in principles for wireframing and UX design.

In addition to the course content, I also wireframed, designed, and built (with the help of a developer friend) a course platform to host all of the content. Something as good as Notion didn’t exist back then.

View the responsive wireframe PDF for the course platform

During the AIUX course I talk through and wireframe an entire e-commerce shopping experience from scratch, using a mobile-first approach and on keyscreens, expanded to medium and larger screens.

NOTE: I do not recommend the AIUX course anymore becuase I was really bad a doing video then plus I no longer recommend AI (Adobe Illustrator) for doing UX work.

You can scan across the screens below from left to right to see how pieces of the mobile design where repositioned into a new grid structure for two larger screen sizes. In the portrait view of the iPad you can see the imagery section is positioned in the left side of a 2-column layout, while everything else is postioned on the right.

With the larger view (above 1024px or so) we convert to a 3-column layout to bring the “Add to Cart” button to be more prominent in the top right spot.

NOTE: Column changes shown in this example is a very low level of effort from a front-end development perspective. The more you know about front-end constraints the better you’ll be at making responsive design decisions.

You can Download the full set of AIUX project wireframes and take a look at how the mobile-first approach was used and only on keyscreens were there desktop designs created for reference on layout changes across devices.

Analog Garage, Thermal Monitoring

Sometimes a project is so complex that it’s simply not possible to jump into visual design. There needs to be whiteboarding, conversations, suggestions, spreadsheets, presentations, and only THEN can you jump into visual design armed with the knowledge of what you’re actually designing for.

This particular project was the design of a dashboard that displayed information regarding temperature readouts of thermal cameras monitoring manufacturing machinery. The cameras monitored heat-spike anomalies that could be extremely dangerous or deadly if gone unchecked. So it’s safe to say we needed to do our due diligence before design a nice gradient.

Soooo many whiteboard sessions

This is the other half

Those whiteboards and conversations eventually turned into a spreadsheet for clarity’s sake.

Spreadsheet of the Information Architecture (IA)

That spreadsheet then turned into mobile wireframes and clickable prototypes.

Download the Mobile-first wireframes designed in Adobe XD

Those wireframes then turned into mobile interface designs, finally!

Download the Analog Sketch files

Then and only then did we feel confident scaling up to larger desktop sizes now that we had our priorities in order for the full experience.

Desktop-first (marketing sites)

Now to completely contradict everything you’ve just read about mobile-first design.

Don’t get me wrong, I’m a huge proponent of mobile-first design as a general philosophy (for defining functionality and forcing priority), but when it comes to marketing sites, I find mobile-first designs to be quite challenging.

Marketing sites can be an exercise of pure creativity and doesn’t often give me enough room to explore and push ideas around. It’s a different type of design challenge.

I’ve faced this same challenge over and over again and have decided that I’m a “desktop-first” kind of guy when it comes to marketing sites. This works for me because I’m also fully aware of the limitations and possibilies of most layouts when it comes to mobile and responsive and everything in-between.

One Big and One Small

For most of my marketing site designs, I like to design one large size and then usually one mobile size that I check while designing with a mirror app, like Figma Mirror.

Sketch, XD, Studio, and Framer have their own mobile preview versions too.

At the time of this writing I typically go for a 1440px wide layout as my default desktop size. That will make sure that it works nicely on a 13" MacBook Pro. You can always scale things up a bit in code if you need to for larger screens.

For a mobile size, I tend to use whatever phone I have in my pocket (eg. 375px wide for iPhone 11) so I can confidently mirror the designs and make sizing decisions while viewing things live.

Site design for Flowkit 1.0

For a desktop site design like this you can see that it’s not so clear as to what exactly would happen on mobile. Even though I was going to code it myself, I needed to have a plan for what would happen so I designed smaller version of each graphic to include on smaller screens. The final mobile version ended up being different than what is shown below. I’ve found the most static responsive designs can only get you to around 80% complete or so, then the last 20% really needs to be decided in the browser.

↓ Download the Flowkit 1.0 site design files.

Site design for Flowkit 3.0

Flowkit 3.0 website updates. For these site updates, I designed the bare minimum in Figma and then jumped straight into code and finished up the design there using hand-coded CSS.

View the Flowkit 3.0 design files in Figma

Site design for Contrast

When there are certain elements, like the big background shapes in the example above, I’ll design a small mobile version so I can explore some layout options that would be more time-consuming to do with code. This is a good example of needing to figure mobile first, before going into production.

↓ Download the Contrast site design files.

Site design for Switch to Studio

Sometimes I have a good idea what will happen on mobile, like the Switch to Studio site above. I’ll save myself some time by jumping straight into code without designing an actual mobile version. I’ll fine tune the mobile version using CSS.

↓ Download the Switch to Studio site design files.

Site design for MyMonero

I only designed a desktop version for the MyMonero site and explained what should happen on mobile to the developer and this worked out totally fine. This is also a possiblity, but you should always communicate early and often with the people you’re working with to find out what is required.

↓ Download the MyMonero site design files.

Site design for Marten’s Marine

This was a pretty big marketing site project for a client in Signapore so I had to be more orgnanized and methodical with all of my files, etc. Long distance communication can breakdown quickly, so I designed the large version and small version of every screen on this one. But again, I did start with the larger versions first to give myself room to explore.


↓ Download the Martens Marine site design files.

Site design for Streamline Icons

This is another site I coded myself, so I designed the desktop version first and jumped into code. It’s not uncommon for me to design the site around 80% complete or so, and then finish the rest while testing everything in the browser.

View the Streamline 3.0 site design in Figma

Site design for the Shift Nudge Beta

Here’s another example of where I jumped straight into code after designing the desktop version. After spending sooooo much time spinning my wheels in general, I was pretty eager to get this thing coded up and ready. You can see the Archive page in the Figma file for older concepts and components I ended up not using.

View the Shift Nudge beta site design in Figma



I’ve got a few assignments for you on this one:

  • Review all of the Codepen examples above if you haven’t already.
  • Visit the URL of all of the sites linked above and slowly and methodically scale your browser smaller and larger to see the design change at different breakpoints.

For your mobile & responsive design homework. Using either low-fidelity design or actual colorful and nicely designed interface design…

  1. A mobile (roughly 375px wide) view of something that has at least 3-5 individual sections. It could be a detail page of your favorite product, or a pricing page of software, or anything else you can come up with.
  2. Design a portrait-mode iPad view (786px wide) that shifts into at least two columns or more depending on the sections.
  3. Then create a larger view (1440px or wider) and decide whether you need another column or just wider columns from the previous version.

iOS Design

The absolute best way to learn about iOS design and functionality is to actually own and use an iPhone. This will help you become very familiar with the operating system. I understand owning and using an iPhone isn’t going to be possible to everyone, but if you want to get into designing iOS apps there’s really no better way.

As with a lot of the topics in this course, iOS design is a very broad subject and could easily be an additional 80 lessons in and of itself. My goal is to give you a broad strategy for designing iPhone apps.


App Icon

There is often a strong link between the app icon and the launch image. It’s definitely an area that can be used to put branding on the forefront.

Here are some important things to remember:

  • Make the icon simple
  • Don’t include words or text unless it’s absolutely essential and if you think it’s absolutely essential, really question why that is. Most icons that include text would be better without it. Don’t forget that each icon contains text underneath its icon.
  • Test the icon against different types of wallpaper. Dark, light, colorful, etc.
  • Don’t forget about the possibility of providing User-selectable App Icons in the preferences section of your app.

Refer to App Icons

Read more about App Icons on the iOS HIG

Launch Image

When you tap an app icon to launch an iOS app, there is often a slight delay before loading in the full app’s content. To minimize the pain this causes, Apple provides what they call a “launch image” that serves as a temporary view for a user to see after the app has launched, but before the content loads into view.

Apple is quite opinionated on what type of information should be shown in the launch image. They recommend a very minimal shell-type screen that is nearly identical to your app’s first screen. They recommend no text since it can’t be localized, and they also recommend no logos.

I would estimate that 99% of all apps go against their last recommendation. Stated below for convenience.

Don’t advertise. The launch image isn’t a branding opportunity. Don’t design an entry experience that looks like a splash screen or an “About” window. Don’t include logos or other branding elements unless they’re a static part of your app’s first screen.

Twitter’s launch experience goes way beyond the standard “launch image”

Launch image from Instagram is a large version of their logo on a white background.

Facebook’s launch image is similar to Instgram. Light branding on a white background.

Apple’s default Mail app uses a faux interface version of the main view to serve as their launch image. This makes the app feel like it loads faster and is definitley more appropriate for a utility-based app like email.


Read about the different navigation structures here. (Hierarchical, Flat, Content-Driven or Experience-Driven)

Navigation bars are used at the top of the screen. They provide context and controls for the content that’s currently in view.

Standard title on left. Large title on right.

Tab Bars

Any apps that have multiple sections to navigate between could really benefit from using 3–5 items in the navigation bar.

Lots of apps have tried new and inventive ways of providing navigation, but ultimately return to the tried and true simple navigation bar.


One of Facebook’s original navigations was a grid view of all of the different sections.


Facebook eventually redesigned their grid view navigation to a Hamburger side menu.

At the time of this recording, they’ve finally settled on the default recommendation from Apple that’s remained unchanged for the last decade—a simple row of icons at the bottom of the screen.

Twitter’s iOS app with 4 simple icons for home, search, notifications, and direct messages.

Snapchat added “Friends” and “Discover” icons in the lower left and right after a long stint of having no discernible navigation other than swiping left and right.

Snapchat is now considering adding a proper tab bar for easy navigation.

More of Snapchat’s new navigation.

In short, most apps that try experimental navigations typically end up redesigning to include the easier and more accessible tab bar navigation, so why not just start there from the beginning!? :sweat_smile:


Modal funcationality for composing a new email. These types of modals always come from the bottom and provide a way to cancel.

Same type of modality in the Hey email app.

Modals work best when their are actions associated with the final result. Eg. Sending an email as shown above, or adding filters to a view online products.

Some apps make the mistake of navigating side-to-side for things like filters and then the user must then navigate back to the main view without a clear understanding if they are applying filters or not. When using a modal, there is a clear action to dismiss the modal—Send, Filter, Save, etc.

iOS ~14 Bottom Modals

Apple was making use of bottom-positioned modals before iOS 14, but even more so now for quick actions. This is afterall the easiest place for thumbs to reach while holding a phone.

Direction in Apple Maps

Quick actions in Homekit

Quick Apple ID sign in to KAYAK

Quick Apple ID sign in for a Spin scooter

Permission Requests

It’s important to note that on iOS apps, you are only allowed to request permission access once per app install, so many apps will design a faux permisson request.

Some example permission requests:

  • Allow Notifications
  • Access to Location
  • Access to Camera & Microphone
  • Access to Photo Library
  • Access to Contacts

Custom designed faux permisson request that can be shown multiple times without triggering the offical modal that allows. Tapping “Allow” here will trigger the actual request.

The standard iOS 13 system permission request modal.

It’s also very important to make sure you account for and design what will happen if someone taps Don’t Allow either intentionally or accidentally.

Some apps may require access to certain information to function properly, while others may not. The example below are some screens I designed for Smartline, which required access to Contacts to function properly. It was critical that there was an easy to understand process for why the app needed access in the first place and what would happen if the one-time permission request was denied.

Remember, no dead ends!

Once Contacts were enabled, the user could then progress through the app and begin using it.

For example the iPhone Pro 11 has a 1792‑by‑828‑pixel resolution at 326 ppi which can be confusing information to deal with and use in a practical sense when using a design tool based on pixels. It’s much easier to set your artboard to 375 x 812 to design a @1x frame for the iPhone 11.

This is why 17pt font translates to 17px at @1x, whereas 17pt font at @3x would translate to 51px.

Most design tools are setup to create @1x frame sizes for mobile design by default. Make sure you do the same!

Light & Dark Mode

It’s important to note that this is optional functionality for any iOS app you design, but more and more users are expecting this functionality. You can programmatically allow your app to go from light to dark mode and vice versa using the iOS system settings, or you can allow the user to go back and forth at their discretion (recommended).

Twitter does a great job allowing users to control the dark mode settings. You can choose dark mode indepently of device settings and vice versa. They also provide two different dark mode themes. The modal is accessible from the small lightbulb icon in the lower left of the navigation panel.

Twitter does a great job allowing users to control the dark mode settings. You can choose dark mode indepently of device settings and vice versa. They also provide two different dark mode themes. The modal is accessible from the small lightbulb icon in the lower left of the navigation panel.

Opacity & Blur

Search view with dark wallpaper

Control center with dark wallpaper

Search view with purple wallpaper. Notice how the color bleeds through, but is obscured enough to still have legible text.

Control center view with purple wallpaper.

Search view with bright orange wallpaper.

Control center with bright orange wallpaper.

iOS is built to handle this type of image blur and opacity. Definitely consider using this unique style when adding different design elements to your iOS apps.


Read more about the Apple fonts here.

  • SF Pro – Most commonly used font for iOS
    • SF Pro Display – For text that’s 20pts or larger
    • SF Pro Text – For text that’s below 20pts
  • SF Compact
  • SF Mono
  • SF Pro Rounded
  • SF Compact Rounded
  • New York – Serif font

Here are the most common type sizes found in default iOS

iOS_Font_Sizes.pdf (24.1 КБ)

**Use the correct font variant in interface mockups.** When you use San Francisco for text in standard controls like buttons and labels, iOS automatically applies the most appropriate variant based on the point size and the current accessibility settings. In interface mockups, use the following text sizes to choose the correct size and adjust the spacing between letters as needed.

For SF, use Text for text that's smaller than 20 points; use Display for text that's 20 points or larger.

For NY, use Small for text that's smaller than 20 points, Medium for text between 20 and 35 points, large for text between 36 and 53 points, and Extra Large for text that's 54 points or larger.


Toolbars are an often forgotten feature of iOS apps. They replace the bottom tab bar for single-view apps that allow common actions to show at the bottom.

Apple has taken a very strong stance on using tool bars for actions instead of floating action buttons (FABs) Fabs are most common in Material Design.

Standard toolbar on a photo detail in iOS photos. Share, Favorite, and Delete.

Toolbar from iOS Mail. Filter by Unread on left and Write New Email on right.

3rd party apps have begun to integrate the Material Guideline FAB (floating action button) on iOS. It’s more of a personal opinion as to whether or not this should be here.

Another example of the FAB from the Fantastical app.

Form Controls

It’s always a good idea to start out with native controls for things like forms, etc. and then decide whether or not custom designed controls are necessary.

Some context for when you may decide for custom controls:

  • You are designing a hybrid app that will be the same experience across both iOS and Android
  • There is a very strong reason for using something custom instead of using native controls
  • The development team is OK with creating custom controls instead of using default ones


Screenshot for Sizing Reference

Designing for mobile sizes on a large desktop monitor can be very deceiving. You might use 10-12px font in your design tool for you iOS interface, only to realize that those size are way to small for a usable interface, and compared to default sizes of 17px for standar line items.

Other items like avatar sizes, icon sizes, button sizes, etc. can all be referenced quickly from taking screenshots of native iOS apps and placing them in your design file.

Just make sure to scale them down to the appropriate size before using them for reference. A screen shot from an iPhone 11 Pro will come into Figma at 1125 x 2436 which should then be sized down to 375 x 812.

See belowk for an example where I’ve used the default “Contact” view in iOS as a reference for the avatar size in other apps.

Default Contacts in iOS 13

Smartline App – Contact

Steady App – Profile


Visit the Apple HIG (Human Interface Guidelines) and bookmarking it for future reference. If you have the time and are interested, the content that they’ve produced is really well done and it would be wise for you to read-through and familiarize yourself with their design principles.

Read the Apple iOS HIG

Redesign the main view of the Hey email app from Basecamp using strict iOS principles, specifically around the tab bar navigation. Try to keep the same spirit of style as if Basecamp designed it.

Tab bar items to include.

  • Imbox (or Inbox if you’re like me and really don’t like that word)
  • The Feed
  • Paper Trail
  • Reply Later
  • More

Optionally, show the More screen and include the following a list view:

  • Set Aside
  • All Files
  • All Labels
  • My Stuff
  • Other Stuff

Use the screens below for reference.