Q&A: 10 Questions with Design Evangelism
November 18, 2022
Last fall, members of our Design Evangelism team got together to answer your Slack questions about design philosophy, color guidelines, keyboard shortcuts, and much more. Here are a few highlights from that conversation, including guidance about the HIG, tips on reducing clutter, and a very important message about the tab bar.
Do you ever feel like your design isn’t quite right, but you’re not sure why?
All the time! In fact, “Feeling like the design isn’t quite right” can sometimes seem like an everyday mood. When this happens, there are a few strategies we find helpful, and the first is: Phone a friend! Sometimes it takes another person to gut-check why we’re feeling uncertain about a design, and it’s always great to engage in a conversation and critique. Plus, this not only requires you to explain the problem (which alone can help you identify what’s not working), it also allows you to personally step away from it — at least for a moment.
How do you know when to start cutting features to make your app less cluttered and more user-friendly?
This is a great exercise for a whiteboard or sticky notes. First, write down all the features/areas of your app. Then, bucket them into what fulfills the goals your users will have. If something feels superfluous, consider whether you need that feature. There's a balance between what you need visible all the time, what can be a few taps away, and what doesn't need to be there at all. (It's also a helpful way to prioritize the most important functionality of your app — which can help you better organize your app's hierarchy!)
Is it considered best practice to limit device orientation on iPhone?
You should really leave device orientation up to users. We love when apps support both portrait and landscape and would only recommend limiting orientation in certain app scenarios, such as when movement or device mounting would make orientation-switching feel distracting.
What are some guidelines for colors and shades?
Using color for actions is a subtle way to brand the interface without being distracting or intrusive. Start by selecting a main tint color, establishing your workflows and actions, then sketching those out with the tint color representing actions. (You’ll notice our first-party apps all have one key tint color; for instance, Mail is blue and Podcasts is purple.) When you’re working on high-fidelity visual designs, use a palette that complements that color.
Is it necessary to include tab bar labels for common tabs like Home, Search, or Profile?
In many cases, labels are recommended for clarity and accessibility. Home, Search, and Profile are generally sufficient for communicating meaning on their own, but they’re exceptions to the rule. Many icons are not as widely understood. Tab bar labels create a stronger distinction from toolbars, which don’t have labels. Plus, removing the labels doesn’t provide much benefit to users. It doesn’t save any space, nor does it significantly reduce visual information from the interface.
How should I think about keyboard shortcuts that feel intuitive and don’t interfere with system shortcuts? When should I use one modifier over another (for instance, Option vs. Shift vs. Command)?
In general, the go-to modifier key is Command because it’s easiest to reach with your left thumb. And speaking of, here are a few more rules of thumb:
- The fewer modifier keys, the better.
- Using the first letter of the action name helps people remember the shortcut.
- From an ergonomic standpoint, keys nearest modifiers and easily reachable using one's index and middle fingers — Q, W, E, A, S, D, O, and P — tend to be more successful as shortcuts.
Want to dive in a little deeper? You’ll find lots of good information in the HIG.
How large are the specified margins for the iOS and iPadOS safe areas?
On iOS and iPadOS, the layout margins are 16pt in the compact width size class and 20pt in the regular width size class. But we typically think of safe areas as distinct things that work in tandem with margins. Safe areas are highly dynamic and change with device orientation, screen size, and a variety of other factors (like whether navigation bars, toolbars, or tab bars are displayed). You’ll find lots of information in the HIG.
When designing for lists, how can I stop rows and cells from feeling overcrowded?
Think about progressive disclosure and hierarchy. What information do people need at each level of your app? When cells feel overcrowded, question the purpose of each element. Maybe a photo or icon isn’t beneficial, or maybe the secondary text can be a description on the detail view.
Do you always try to adhere as much as possible to the HIG, or do you try to do something different with every design?
Great question! We do try to adhere to our foundations and follow our own design patterns for the benefit of consistency and understanding. (We also try to use system components because they're so efficient to build with.) But that being said, we're also willing to push on the HIG where it makes sense — if it means an overall benefit for users. We're pretty adamant that the HIG shouldn't be a set of rules, but very good suggestions. And we evolve it constantly based on what we're seeing in the community and how we want to push our own aesthetics and interactions for the future.
Is it good practice to hide the tab bar when navigating to sub-pages?
(It’s OK to cover it for brief periods when a modal sheet is displayed. Otherwise, hiding a tab bar can make people feel lost.)