WWDC 22 Digital Design Lounge — Writing for Interfaces

Writing for interfaces - WWDC22 - Videos - Apple Developer
The words and phrases you choose for your app matter. Whether you’re writing an alert, building an onboarding experience, or describing...

Tips

How do you use words to explain the purpose of your app?

Tab bar labels often capture the purpose of the app, when they're done well. In my opinion, anyway. 😅

Seems to me that the words describing purpose of an app start on the App Store - not in your app. I suppose that includes release notes.

That’s a great point. Think about the writing beyond just what’s inside the app.


It's a really good point. By the time people are launching an app for the first time, they've already begun the experience with it, with the app name, app icon, the screenshots in the App Store, the description, etc.

The voice should definitely feel cohesive, no matter where someone encounters your app!


You have to decide where you want to focus your efforts. But it’s all a reflection of your app, so release notes should at least be clear and helpful.

I noticed you said that a destructive action should be on the left and red text. I never knew that - where is this sort of thing in the HIG?

We have writing guidance sprinkled around the HIG in various locations. This guidance is on the Alerts page: https://developer.apple.com/design/human-interface-guidelines/components/presentation/alerts.


Identify destructive buttons. If an alert button results in a destructive action, like deleting content, specify the destructive button style to help people recognize it. There's more about it here: https://developer.apple.com/documentation/swiftui/buttonrole/destructive.

Other than users and learners, any other suggestions for referring to the people using our apps?

What is your audience? We often just use “people” but if you can be more specific, like “family member” or “subscriber” that’s a good way to go.


Think about what people using your app would call themselves.

We try to avoid the word “users” when we refer the people who use our apps, and prefer something that sounds more human, like "artists",  "collaborators", "participants", etc. depending on the app and what people are trying to do. 🙂

Are there any examples of combining different tonalities within one app? Or should one just stick to one?

The voice of your app is something you want to remain consistent, so that folks get consistent messaging inside your app. But, as you point out, the tone can certainly modulate. When you welcome somebody, you might sound excited. But when that person has a credit card declined, you may want to sound more serious.

Similar to how your voice is always you, but your tone changes depending on context and who you're talking to.

In other words (no pun intended, hiyooo!), it's very common — if not important — to adjust your tone throughout your app. The tone should reflect the situation.

As an example, coaching from the Activity app on Apple Watch is celebratory when you close a ring. But it's more matter-of-fact if your progress is lacking.

Just wondering though, would you recommend Onboarding for apps? I’ve heard before it interrupts the user’s usage of the app, but I’ve also heard that it makes users feel more welcome. What do you think?

This is such a good question. I don't think there's a single answer to it.


It's going to vary based on the complexity of your app or how simple its premise is. We find what often helps is to incorporate onboarding elements or moments into the first-time experience for someone new.


Maybe I'm saying the same thing, but the best onboarding doesn't feel like "onboarding".


There’s no one answer to this! My favorite onboarding experiences are the ones you do right within the app itself. Like those early levels of a game that teach you how to play it. Or a chat app that uses the chat to get you set up.


Alto's Adventure! You're just dropped into the game, and you're playing, and it's teaching you along the way.

For full screen modals with no interaction, is Apple's preferred dismiss control an X in a circle in the top right corner (as is referenced in the Explore Navigation Design for iOS talk) as opposed to a grab style control at the top middle (indicating to pull down to close)?

Totally great question. we get it a lot. We have an answer for you in the HIG: https://developer.apple.com/design/human-interface-guidelines/components/presentation/sheets.

Position Done and Cancel buttons as people expect. Typically, a Done or Dismiss button belongs in a sheet’s top-right corner (in a left-to-right layout) or top-left corner (in a right-to-left layout). The Cancel button belongs in a sheet’s top-left (in a left-to-right layout) or top-right (in a right-to-left layout) corner.


This has been an interaction pattern in recent releases, moving away from the elevated sheet and toward the full-screen presentation with the close in the top right.

Seems common for interface copy to be too verbose before it's edited down. Are there examples that come to mind where the UI was the opposite, too terse and needed more explanation?

There are may examples of this, I'm sure. One that comes to mind is when people input personal information, like when ordering something for delivery to their home. Sure, you could just indicate that you received the information, but by restating what you received (so the customer can ensure it was entered correctly) and maybe even stating that the info won't be used for nefarious purposes (eg. it wont be sold to advertisers), you create a level of comfort that more economical language might not afford.

Think about when you tell a server at a restaurant that you want a certain dish, but with extra pickles and hot sauce but no tomatoes and can you please switch the fries for a salad. Some servers won't write that down. And while that's impressive to see, it's also nice to hear when the server repeats it back to you so you know the meal will come as you asked.


Love that metaphor. Another thing we do often is link out to support articles for people who want to learn more about a particular subject. That way the information is there if you need, but it's not in the way.

What would be the best way to dismiss a full screen modal that has content? Would it be a button along the lines of ‘Done’ at the bottom, or is it still a cross in the top right as mentioned earlier?

There’s some good insights in the HIG on the Sheets and Modality pages.

https://developer.apple.com/design/human-interface-guidelines/components/presentation/sheets

https://developer.apple.com/design/human-interface-guidelines/patterns/modality

https://developer.apple.com/videos/play/wwdc2022/10001/

If you add a new feature to an app, is it a good idea to showcase that new feature when the user does a certain action (i.e. completes a task etc.) or is that bad user experience as you’re interrupting their session?

This goes back to context. If that feature is relevant or helpful at that moment, then yes, go ahead and talk about the new feature. But if it’s not relevant to that moment, think about where else it would feel more contextual.

I make a photo editing app and I often wonder how I should deal with technical terms. One example that comes to mind are blend modes (screen, overlay, multiply, etc.) as those things are foreign concepts to the average person. Do you recommend sticking to such technical terms and providing explanations via graphics, for example?

Ooh good question. It really depends on your audience - are they professional photographers? Then they might understand more technical terms. You can also help define things with secondary text.


If these are terms of art, and it sounds like they are, it can be best to stick with them. Avoid jargon, or making up terms that might end up confusing everyone. That said, if your audience is less technical, maybe define the terms so people can learn them.


+1 to what both said here. We aim to democratize access to technology with much of our hardware, software, and services at Apple; so we aim to have our language be understood by as many people as possible. But with a few of our apps, we have a specific audience (eg our creator tools, like Apple Music for Artists, that focus on specific audiences), and therefore we want the language to be in the vernacular of the users—otherwise it may feel like we've shipped a watered-down professional feature.

Since it's not aimed at professionals, show it to friends (or strangers) and see if they understand what's written. And as Jen and Kaely pointed out in their talk, consider reading it out loud to yourself as well.

Structure

I wonder what the arrangement for options in an alarm means. For example putting major option on the left or top. Is it recommended to change the order, e.g. from major-on-left to major-on-right, for languages using different reading order?

Yes, typically you’d want to order more important things above or to the left of less important things. And for RTL languages, check out this page in the HIG: https://developer.apple.com/design/human-interface-guidelines/foundations/right-to-left. Also this video: https://developer.apple.com/wwdc22/10034.

Siri

Should I still add an ‘Add to Siri’ button to my app with the new SiriKit/shortcuts functionality, or is it completely obsolete?

Good question. You don't need to remove it, if you've got it. But on iOS 16 forward, you can begin to move away from it by creating and supplying App Shortcuts, rather than requiring people to set them up.

I haven't fully looked into the new SiriKit interactions… Does it just mean that if an Intent is available, iOS knows this and will automatically integrate it with Siri/shortcuts?

I think you've essentially got it, but I would watch the App Intents video and the Design App Shortcuts video as well.

Collaboration

How do you see the different roles of the HIG's writing guidance, and the Apple Style Guide (https://help.apple.com/applestyleguide/#/apsg1eef9171)? Is the style guide more for contexts outside of apps and long form writing?

Great question. One way to think about it, is that your product is a major part of your brand.With that in mind, your product may have more specific guidelines to follow so that you can make your interface feel familiar — and subsequently, intuitive. These kinds of patterns are outlined in the the Human Interface Guidelines.Your brand, however, may encompass more than just what appears in your product. Your website, emails, marketing collaterals, events, and even the App Store descriptions mentioned earlier, these are all examples of surfaces where your voice extends beyond your app. For us, that's where the Apple Style Guide kicks in, helping us to adhere to a wider set of grammar and syntax to ensure we have consistency at every customer touchpoint.Think about this balance for your app, too. How can your app have clarity and consistency throughout, and how can that narrative continue outside of your app to complement what you — and your users — are trying to do?

HIG            ASG
          🤝
     continuing
 the conversation

Preferences

What's your favorite thing to write?

I find it interesting to write for a subject matter I don’t know much about. I get to dive into researching a whole new area and get in the mindset of someone using that technology. It's fun to think of how to make things as clear as possible. 🕵️‍♀️


I really like writing setup flows. There’s a real balance between helping people get started quickly and making sure they have the information they need.


Setup flows are definitely a fun challenge! Thinking of how you introduce things simply and get someone started in the best way possible.

Tips and education are a big part of what we consider! But there's also the balance of not having too many modals that get in the way of the experience.

Mistakes

I’ve found a small mistake in the HIG, where should I report this?  The Feedback assistant doesn’t seem to have a appropriate category.

Would love the feedback! We are working on adding a HIG category. You can use the Apple Design Resources component for now. 😉

Have you ever accidentally shipped out a typo with an OS release?

"An Apple spokesperson declined to comment." 😉


It happened onec

Future

If I want to read the new HIG end-to-end, when should I plan to do that so everything will be in there? I know yall are working on more goodies.

The HIG is a living document, so it’s always getting updated in big and small ways. Between now and the fall, the updates will (most likely) be small. In the fall, the bigger updates will land.

Another way of answering your question is: You might as well get started with that read-through! It has been great to get feedback on the redesign, so don’t be shy about that, either.


We're already planning for changelogs in the HIG coming some time this summer!


One more update for those of you who stayed in the theater past the final credits: We'll be adding writing guidance to the recently re-designed HIG this fall. We're excited to get that to you soon.

Show Comments