You’ve been designing web apps for years, and you’re a total pro at it. Well done!

Now you have to design your first native app and you’re not quite sure where to start. Don’t worry. The good thing is most of your web design knowledge is transferable, but there are a few things you should keep in mind.

Respect Platform Conventions

Understanding the environment you’re designing for is fundamental. What are the patterns and interactions users expect? If you design an iOS or Android app using only web design patterns, people will be frustrated.

The best way to understand platform conventions is to use that platform for an extended period of time. If you’re an iPhone user, try using an Android for a few months, and vice versa. Don’t let the Apple vs Google holy wars get in the way of doing great design work.

I’m aware that it’s not always feasible to acquire a second device, so here are a few other options for learning more about a software platform:

Performance Matters

This is not to say that performance doesn’t matter with web apps, but people’s expectations are different. On native platforms, people expect fast loading, smooth scrolling, and an overall snappy feel.

Your design decisions affect performance in positive and negative ways. Work closely with your development team to make sure your design doesn’t compromise performance. If it does, change your design.

Your UI doesn’t have to be the same for every platform

Over the past few years, the design community has latched on to the idea that an app must look and function exactly the same for every single platform its on. The reason sounds something like this:

“If the UI is the same on every platform then our customers can easily jump from web, to iOS, to Android and not have to re-learn anything. This is a better user experience.”

The statement above is true if people only use your app. Sorry to break it to you but your app is probably not the center of people’s lives. That would be nice 😜.

Your app lives in the larger context of someone’s life. They are not thinking about your app as much as you are. They use it when needed and then move on.

In reality, people view their phones as a single experience. They may jump from app to app, but the way they see it they are just “using their phone”. Your app should fit nicely into that experience. Anything you do out of the ordinary will be noticed, and that’s not always good.

I think it’s more user-focused to use native patterns because it takes into account the totality of the user’s phone experience. They’ll understand the navigation structure because it’s similar to most of the other apps they use. They’ll know they can swipe to go back because every other app on their phone behaves the same way.

Not every app needs to, or should, surprise and delight. Most of the time people just want stuff that’s reliable and works well.

In Summary

Designing native apps is so much fun. Each platform has unique and powerful capabilities that are not available to web designers. Enjoy the experience of learning something new and don’t forget:

Go forth and design great native apps!

This is a list of resources for design systems. Hopefully, it will be as helpful to you as it is to me. This will be updated as I come across more design system goodies.

System Examples

These are examples of design systems that I reference frequently. Either for their content, structure, or general design.

Articles

These are articles I’ve come across that have made me stop and think. I don’t necessarily agree with everything here, but this is all good stuff.

Creating a System

Managing a System

Selling Design Systems

Accessibility and Inclusion

Design Principles

I’m looking at purchasing a Tom Bihn Synik 22. These are resources I’m collecting to help me decide if I should purchase. I’ll be updating this resource as I come across more info.

Written Reviews & Forum Discussions

Videos

Sofa was suffering from a tight-coupling problem between view controllers. I discovered this while trying to refactor my massive controllers. I stumbled upon the coordinator pattern, which ended up being a great solution.

A quick note

I’m a beginner when it comes to iOS development, and the coordinator pattern is an advanced one for me. I struggled with things that more experience developers would find trivial. There were moments where I thought I may have bitten off more than I could chew, but in the end it all worked out. I ended up learning a lot and improving the quality of Sofa.

The Problem

For 2019, I’m working on some pretty large features for Sofa and thought I better clean things up before diving in. I was running into the issue of tight-coupling while refactoring my ViewControllers.

Up to this point, I’d been using segues to handle navigation flow. This wasn’t a problem until recently. I wanted to fix my massive view controller problem, but having tight coupling between my ViewControllers was making this incredibly difficult. Luckily, Paul Hudson wrote about the a href="https://www.hackingwithswift.com/articles/71/how-to-use-the-coordinator-pattern-in-ios-apps">

After a quick read, it looked like the Coordinator pattern would solve my tight-coupling issues. So I dove into implementing it.

The Outcome

The coordinator pattern has been successfully implemented and is live in a href="https://itunes.apple.com/app/id1276554886">

This completely fixed the tight-coupling issue that was holding a lot of improvements back. While I’m really happy with the results, there were plenty of tricky details that I struggled with.

Tricky Details

Child Coordinators

For the coordinator pattern to work, you need to have a single code>

I wasn’t initially sure when to make a child coordinator vs just adding it to code>

If a view controller needs to present (not push) another view controller, it should be its own child coordinator.

This worked fairly well and forced me to not over-think things.

Delegation

Delegation was something that I understood at a high-level, but struggled to grasp the details of. Halfway through implementing coordinators, I realized, “Oh, this is just delegation.” It was a nice “ah-ha” moment, and ended up giving me a deeper understanding of how delegation works.

Protocols

Similar to delegation, protocols were another area of mystery for me. Having to create the code>

I ended up making one adjustment to the code>

code>

Presenting Modal views

The main navigation flow for Sofa is handled by a subclassed navigation controller: code>

Pushing views with coordinators was no issue, but I was getting stuck on how to present views modally. Luckily a href="https://twitter.com/oliverpfeffer">

Let’s look at the code>

First, we make it conform to the code>

code>

Next, we want to add a private var for the settings navigation controller. This will be used to push other views into this navigation controller.

private var settingsNavController: UINavigationController?

Finally, we put it all together in code>

code>

This may look simple, but in the moment I was incredibly confused 🤪

Removing views from memory

This is the most tedious and manual part of using coordinators. You need to make sure you’re removing the child coordinators you’ve created from memory. Since I had a few levels of child coordinators it took a lot of mental effort to implement and test. Overall, the effort was worth it for the final result.

Removing Unwinds

The amount of unwinds I was using prior to coordinators was tragic. SO. MANY. UNWINDS. In the end, most of the unwinds were resolved by using delegates instead. YAY for learning more about delegation!

Summary

I’m glad I invested the time to implement coordinators in Sofa. Overall, it took me about two months (6 hours per week) to complete. Sofa is now in a better position to handle more complex features, and it taught me more about key iOS concepts: delegation and protocols. Wins all around.

Resources That I Couldn’t Have Done This Without

I go over the reasons for making Sofa a free app.

I try to get a button working. Yes. A button.

I conducted research on the Sofa App Store page. I also discuss the process & tools used to conduct the research.

A video showing you the process I went through to design Quick Add in Sofa.

There’s a constant debate about whether or not designers should learn to code. While I’m happy to talk about that at length, I think it’s helpful to look at it from a different perspective.

What are you trying to accomplish? Are you trying to get a job, build up your resume, break into a new area of design, communicate better with devs? Learning to code really depends on what you want to accomplish.

In my case, I wanted to ship a product.

A Little Backstory

In 2015, I worked on the a href="https://medium.com/sofa-blog/sofa-1-0-is-here-73a37e19ce3c?ref=shawnhickman.studio">

At this point I didn’t em>

Then life got in the way. This was a side project for all of us and we still had full-time jobs. The two devs got extremely busy and couldn’t work on Sofa at the same capacity. The app sat there not being updated and it was painful for me. I had tons of ideas based on user feedback to implement, but was powerless to do so. This was a big driver for me to learn how to code.

Starting with Framer

Like most designers, I had dabbled in HTML, CSS and a little Javascript. It wasn’t until I used a href="https://framer.com/?ref=shawnhickman.studio">

Framer is such an amazing tool for designers to learn how to code. Being able to see the results of your code em>

From there I dabbled a bit more in Javascript but my heart was always in native iOS apps.

Moving on to Swift

I had tried to learn iOS in the pre-Swift days, but Objective-C was difficult for me to digest. When Swift was announced, I immediately thought “Hey, I might be able to learn that.” I wasn’t sure, but it gave me a little confidence.

This is the hard part. There are many resources for learning iOS development, but most are pretty terrible. The teachers make too many assumptions about what the student already knows. This is true even for courses designed for beginners. They tell you how to do “X”, but never tell you that you also need to do “A, B & C”. It ends up being incredibly confusing, intimidating and demoralizing.

The single best resource I’ve used to get started learning iOS development was from a href="https://twitter.com/MengTo?ref=shawnhickman.studio">

Design + Code taught me how to send data back and forth between views, change the design of the app with code and use Storyboards. Again, other courses do this, but they don’t explain it well to designers.

That course taught me the fundamentals of iOS development. From there I was able to explore and build a few prototypes. One was an early Sofa 2 prototype and the other was a collaborative whiteboard for iPads. I never finished either of them, but learned a ton in the process.

Building and Shipping Sofa 2.0 in 6 Months

In the summer of 2017, I got to the point where I couldn’t wait any longer to move Sofa forward. My teammates’ shedules were not letting up and it could be another year until they could contribute again. That’s when I decided to build 2.0 myself.

When I started I didn’t know exactly how I was going to do it, but I dove in and got started. I knew enough of the basics to get going.

While building, there where two resources I used constantly: Stack Overflow and YouTube. Yes, YouTube. When you’re learning something new, reading about it isn’t always enough. Seeing someone solve the problem you have is incredibly helpful. That’s where YouTube shines. I would type in whatever I was trying to figure and then start watching. There are a few YouTube accounts that consistently taught me how to do things:

I am eternally grateful to these people for putting out great content that was easy to understand.

From July to September, I worked on getting the basic experience of the app functioning. Then from September to December I had beta testers to help test assumptions and refine the experience.

With every week that went by, I was gaining more confidence. There were a few tricky issues to figure out and a few things I was scared of, like Core Data, but overall it ended being fairly straightforward.

I ended up launching Sofa 2.0 on December 6, 2017. Technically a little less than 6 months, but I was never good at math anyway. It’s hard to describe the feeling of working on something for a long time and then sharing it with the world. It’s scary, exciting, humbling and most all…fun!

During this time, my good friend and Sofa teammate, a href="https://twitter.com/oliverpfeffer?ref=shawnhickman.studio">

I didn’t do this alone

I am hyper aware that I didn’t and couldn’t do any of this alone. Framer taught me the basics of coding, Meng To taught me the basics of iOS development, and Stack Overflow, YouTube and Oli taught me deeper parts of iOS.

It’s not only the people who taught me code, it’s also the people who support me everyday. My wife, family, friends, co-workers, bosses, etc. I am extremely lucky to be surrounded by people who care about me and support my goofy passions. It’s something I never forget.

You can do this too

This isn’t just for designers, but for everyone. If you have a goal you’re driving towards, but currently lack the skills, don’t worry. Learning new things today is easier than at any other point in history. All you have to do is put in the time. It may not take as long or be as hard as you think 👍

If you’re interested in seeing the fruits of my labor, you can a href="https://itunes.apple.com/app/id1276554886?ref=shawnhickman.studio">

When we started working on Sofa, it was very different from what you see today. In fact, it wasn’t even called Sofa. It was called many things: Movie Night, Movie List, and Movie Pal just to name a few. I wanted to share a little bit of the story about how we got to Sofa 1.0.

When we started working on Sofa, it was very different from what you see today. In fact, it wasn’t even called Sofa. It was called many things: Movie Night, Movie List, and Movie Pal just to name a few. I wanted to share a little bit of the story about how we got to Sofa 1.0.

The Concept

Sofa was originally called em>

Then it became em>

Our First Builds

Once we felt like we had something interesting with em>

Early sketch of UI and icon ideas from Sep 2014

We kept the first fews builds to ourselves to test and refine. We wanted to see if the product was even interesting to us before we let others check it out. We liked it and invited family and friends to check it out.

Having other people use the app

Having other people use em>

At this point, em>

Evolution of the Sofa product name and logo

During the beta period we were constantly talking to and soliciting feedback from the testers. We slowly added new features that we didn’t originally intend to or think of, such as, a movie detail page, Discover section, people pages and sharing. We also fixed plenty of poorly designed workflows and bugs.

We were in beta for close to a year. While this may seem like a long time, keep in mind that we weren’t working on this full time. We all have day jobs and families to take of. Those em>

The beta period was extremely important for us. Not only to find bugs, but to shape the product. When something is so new, it’s hard to nail down what it really is or if it’s good for anything. The only way to figure that out is to get people using it.

Knowing when it’s time to launch

This was a tough one. There were a few times when I thought we were ready, but it turns out we weren’t. The moment I knew it was time to launch was when we were arguing over really minor features. The product was beyond good enough and we needed to see how more people would use it.

Post-Launch

Before launch, we had a product roapmap that stretched many releases into the future. This was dumb. We were planning where the product should go before people had even used it. While it was good for us to have ideas for new features, making hard plans was a waste of time.

We ended up totally revising our roadmap about a month after launch, and only planning a few releases into the future. This is good because we are able to make plans based on feedback, be more flexible to market changes, and focus on what really em>

The Importance of Getting Feedback

I can’t stress how important getting feedback was during this entire process. From the very early concept phase to the beta releases. Everyone’s feedback shaped Sofa into what is today and will continue to shape it in the future. If you are not constantly soliciting feedback for your work, it will never be as good as it could.

What did we learn?

strong>

strong>

strong>

Now what?

Ok, so we’ve shipped our 1.0. Now what? We have plenty of features in the pipeline, but we don’t want to plan too far ahead. This is all new to us. None of us has ever created a company or product before, so we are simply rolling with it. We are learning tons about product development, marketing, strategy, etc. We are probably going to screw up a lot, but man-o-man is this fun 😜

If you haven’t downloaded Sofa, you can grab it from the a href="https://appsto.re/us/Stz74.i?ref=shawnhickman.studio">

Let me start this off with this simple fact: I’m not a heavy Facebook user. Most of my digital time is spent in a href="http://twitter.com/poohbers">

It’s natural to compare Facebook’s flagship app and Paper, but I don’t see them as competitors. The flagship app is designed for a broad audience, and Paper is designed for a narrow one.

I took a backstage tour at Disney World a few years back, and something our guide said really stuck with me, “We try to tailor our experience to every type of person who comes to our parks.” On the surface it sounds simple, but think about how hard that is. People are so different from each other. They have different beliefs, tolerances, desires, expectations, etc. How do you design a single experience tailored to each of them? Maybe this is why we are seeing a big trend in the unbundling of apps. Once you gain a certain number of users, it becomes too difficult to keep them happy with a single experience. Hence, smaller focused apps aimed at making specific types of people happy.

This may sound obvious, but Facebook has a lot of users from all over the world. Can they design a single experience for a billion people and have them all be happy with it?

At this point you may be saying, “Yea yea, Shawn, but didn’t you see the numbers that Paper users only use it for x seconds per day/week/month?” Yes but I don’t care about that metric because it doesn’t tell me anything. It doesn’t tell me if the person is happy, frustrated, busy, excited, or whatever other infinite senarios I could write. Metrics are good, but they tell you very little. As a designer, I would rather have a happy user that spends 10 seconds than a frustrated user that spends 10 minutes.

I don’t know what the future of Paper will be. Maybe Facebook will kill it if it doesn’t reach a certain number of users, or maybe they will continue making these small focused apps for a narrow audience. In the meantime, I’m enjoying Paper. It’s making me a happier Facebook user, even if it’s only for a few minutes a week.

Currently, when I get a text or push notification on my iPhone, it interrupts whatever I’m doing and shows me a dialog box that I must interact with. It’s insanely annoying.

After thinking about how it could be implemented on the iPhone, I think I have come up with something that solves this problem.​​

Here are some additional thoughts about my decisions:

This got a nice writeup on a href="http://techcrunch.com/2011/03/07/iphone-notification-system/">