How to deliver better user experiences as a Swift developer?

Swift is all kinds of fun but have you ever tried UX? Of course you have. Everything you use results in a user experience. Following that logic: everything you create and going to be used by others will result in UX, too. But what is it really, and where do designers & developers fit in the picture? Let’s find out.

User Experience Design

There are tons of articles about all the different types of designers, and I could write my own, too, but let’s skip that for now. The only thing I’d like to mention is that I personally don’t like the title “user experience designer” ‘cause it can be misleading. Companies with little to no experience with design professionals expect you to magically figure out the best UX: ‘cause that’s what you do, right? Wrong.

User experience is a phenomenon happening to anyone using a tool. Any tool. Do you post on Twitter? It’s UX. Do you read your mails on your iPad? It’s UX. Do you drink coffee made by an old metal coffee maker? UX. Did you just buy a new chair from Ikea and you have to put it together? Same. Did you just sit to your brand new chair to enjoy a good cup of coffee? Still UX. ☕️

But can I design these things? Can I say you’ll do all these things in this specific order from start to end and you’ll like it? Nope. Can I map possible ways of that happening? Yep. Here we go.

User Experience “Design” is about understanding the needs (you want to drink coffee in a comfortable chair every morning before going to work), and then giving tools to fulfill them. Of course I want you to achieve your goal as easy as possible, so I’ll try to understand how you do things now, and how can I change those things to improve your situation. Then I’ll figure out a way and define an “expected user experience” and set up things for you to get it. After you’re there, you’ll get the real user experience, which might be a lot different from what we’ve expected. The goal of UX design is to get the expected UX as close as possible to the actual UX.

Comfort is not the only aspect of UX, of course. Whatever you create, you want to make it understandable, learnable, memorable, consistent, accessible and safe.

It’s nice if it looks good, too...

UX != Comfort: Introduction to Accessibility

As stated before, building a good user interface is challenging. Let’s say you’re working on an app, site, service or whatever and you want to use the help of a framework. There are many UI frameworks and templates on the web, so you won’t have a hard time finding one for you. Might take some care to find the right one for your users.

Accessibility (a11y in short) is one of the most important aspects of UX. 10-20% of the world’s population has one or more disabilities. According to this summary, 7% of UK, US and Canadian web users have dexterity difficulties; 8% of them have some kinds of color blindness; and 3-4% of them can’t see well enough to read, which is increasing over time. People often state a11y as something for users with special needs, but don’t we all have our own “special” custom preferences? We organize our worktable to reach everything easily, we group our apps on our iPhones in a specific order, we turn on dark mode to have a better reading experience and a lover power consumption... A11y is not so different and a lot of mobile accessibility considerations are actually pretty simple: minimize the information to fit small screens; use a clear wording especially on actionable items; provide a reasonable touch target size and spacing; place controllers to where it’s easy to access; use the right background-foreground contrast (there are tools like this one to help you with it); don’t rely on colors only: using green, yellow, and red dots to give status feedback might be a simple and clear idea for you, but for someone they are just shades of grey (here’s a cool browser extension to help you see what others see); gestures should be as simple as possible and it’s good if you can add a work-around feature to simulate them with on-screen menus or even keyboard operations as more and more mobile devices support keyboards, as well.

Fortunately, iOS has a great a11y support, and I can very much recommend this article about SwiftUI accessibility, as well. Long story short: by adopting SwiftUI you’ll be on the right path to give an accessible UI for all your iOS users (not regardless of the design, of course). UIKit is not without a11y options either, but I’ll keep the technical part for Tib. 🙂

There are many more principles but the ones listed below are a good start. You can apply them on web applications, as you need to make them mobile-ready anyway. But even if you took care of it all, you can still get it wrong. Let me show you an example.

The Power of Visual Design

Let’s say you’re on a webpage with a list of “infinite” elements loading to scroll (like a newsfeed). There’s a fixed footer on the bottom of the page, containing some persistent and dynamic (hidden) actions. You can select items from your page and “delete all” by a bulk action button appears in the footer. Easy right? 👌

Now let’s say you cannot use touch or mouse, only a physical keyboard. You press tab to navigate, jumping from one UI element to another, but your list is just loading more and more data, so you cannot reach the footer, which means you cannot reach your actions. It’s easy to fix, of course, you just replace the load-to-scroll option with a “load more” button, so you can focus it and jump to the footer without loading more items. But if you miss it, you can potentially prevent some of your users from performing an action.

Let’s see this example from another perspective. You select the items you want to remove and the “delete all” button appears, you deselect them and it disappears, so you can connect the dots. But what if you don’t see this visual feedback? What if only the screen-reader tells you the “delete all” button is in focus? Would you know it’s only for the selected items or would you expect it to purge all your data? As you can see, the copy you use matters, too. While you see “delete all” is connected to the selected items, “delete selected” will be clear for those who can rely only on their ears, as well. While a basic UI can be good for most of your users, an accessible UI is better for everyone. So don’t forget to take care of it.

Designing the UI before coding can help you to cover these cases so you don’t have to waste your time implementing multiple versions of a faulty UI. The most popular frameworks have component libraries for design tools like Sketch or Figma so you won’t have a hard time matching your code to your design. Larger companies focus a lot on maintaining and documenting their own custom frameworks and UI libraries (altogether: design systems) to have a faster workflow and a more consistent UI fulfilling all UX requirements. But I’ll keep this one for a future post. 😉

UX Beyond UI

We’ve talked about the “touch and feel” of our tools, now let’s have a look behind the curtain. The best UX is invisible, they say and I dare to say we all prefer simplicity over beauty or fun, at least when we’re about to perform a task. It doesn’t matter how cool your UI is, if the service is bad, or doesn’t give the user what they want. But if the tool you provide does it’s job well, and helps the user to get things done effectively, they might not care much about the outlook of your interface (remember swapping iOS6 to iOS7 😏).

Simplicity on the UI means complexity in the background, though. Just think about search engines: it’s a really simple UX, you just type stuff to the search field (or even to your browser’s URL bar), and things magically appear on your screen. Here you don’t care about beauty, or fun animations or anything, what you care about is speed and accuracy: you want to find something and you want it now.

We all know how frustrating is it to see the loading animation for more than… like 3 seconds. Actually, there are studies saying users will abandon your site if the loading time is more than 3 seconds, which can be alarming. It’s without saying that a visual designer cannot do much about that. It’s one of the many cases when UX highly depends on the effort of developers, and it’s a great responsibility! We all want to get our jobs done easily, but sometimes choosing the short path means our users will have to walk the longer one. I know there are many factors (deadlines, legacy code, dependencies and so on) during a project tying our hands, but if you have the chance to give a solution to a problem, don’t hesitate to do so just because there’s an easier way. Your users will thank you later. 😊

Well, thank you if you made it to this point! I hope you enjoyed this sneak-peek of UX, let me know if you’d like to read more, I’m happy to share what I know. 🤘