Prototyping for Real

When I first began building my side-project site SwiftUI Prototyping the aim was to help designers building passable prototype apps that would live on device. This remains the dream and as SwiftUI improves with each new iteration, we're getting closer to having all the features designers need.

My pitch is simple—many of the apps and products we're designing these days are complex and we should be prototyping even more. You need to prototype the real thing. Even if it's for yourself, it's extremely valuable to see and interact with your designs on the real device. That goes for a website—you're likely looking at the design on a screen, maybe even in the browser, and for the responsive site you're likely using inspector but you really should get the whole design onto your phone, how else we you know whether the hovers work (they won't). If you're designing an app, get the design on your phone—send over a PNG and view it. Get your prototype on your phone—use the companion app for your prototyping tool. And if you can go further, make a rough mockup app in SwiftUI.

Key piece of advice: make friends with your devs! They can help you with questions and advice if you're stuck.

Designers should code, maybe

I won't dwell on the debate for too long but should designers learn to code? Yes. Probably. Well it depends. I tend to be both a generalist and a design technologist (an earlier adopter). I like to experiment and learn, and sometimes these are skills that help me in my career. Some designers can draw and illustrate—this is not my strongest skill and my best drawing was back in college. Should designers know how to draw? Yes. Probably. Well it depends. Just like all designers don't need to draw, all designers don't need to code. All designers didn't need to know how to use Flash or Director—does that analogy work? One more. Should designers prototype? Yes, absolutely.

I joined the developers at Canadian Tire as we took the Big Nerd Ranch Swift course because I wanted to understand Swift even if I wasn't ever going to write production code. But it did help me learn enough of another language to "speak dev" and also see the possibilities. (Equally attending Google I/O the year Material 2 was launched including the new lower tab bar element, and speaking with the designers and engineers helped me successfully pitch this very iOS-like element in the Canadian Tire app)

In the months after the course, I was able to build a working prototype for a somewhat complex barcode scanning feature using the phone's camera. We talk about a prototype saving a thousand meetings and that's very true. I attempted to use the prototyping apps of the day to mockup how the barcode feature would work, but this wasn't "native" and it was little more than a video. To be clear the app I built was hacked together based on a lot of Googling and diving into Apple's AV documentation, but it worked—a barcode could be scanned, the camera could recognize a real barcode and trigger both the interaction and visual feedback but also run the search for that product (although that was an image of a design—it wasn't really about the results, it was about the interaction). And I did that with Swift but this was before SwiftUI. However even today the limitations of SwiftUI currently prevent most of the experience but I can now mockup most of the app and much of the interactions. Just like before I can stick that app on a phone and demo it in person, or run usability tests. It's basically just enough code to illustrate the intent without suspending belief.

Use the real tools

Over the years I've tried numerous prototyping tools—Flinto, Protopie, XD, Keynote even—but one of the most successful user tests I did involved an HTML prototype for a webpage with just enough JS (well JQuery) to make the page interactive. It was for a website after all. I've tried mocking up a mobile app using Keynote and a simple HTML touch-based framework (which needed to be hosted somewhere), and I was able to get by with a little smoke and mirrors (real data but generic, linear user journeys and a lot of images). This worked for demoing the flow and the design in situ (like printing off a page layout or logo) but many things had to be faked—asking for location data, showing real content based on the real location (at least that worked when in the office). We don't design using Word/Pages or Powerpoint/Keynote, we design using the best tools for the job—tools that vary by the designer and team. Prototyping is wide open and there's often a learning curve for whatever app is in vogue. Why can't it be HTML or Swift?

Well it can. That's a rhetorical question.

Obviously I'm not suggesting every designer take two months or more to learn SwiftUI in the middle of a project. (I'm imagining several product managers getting very nervous here). If you have the time, try learning SwiftUI on a side-project—maybe there's an app idea you've always had but needed both the excuse and reason to validate the idea. It's possible you can build it using HTML (there are wrappers to make it look like an app but there's extra work to make the interactions and transitions feel natural), but if the thought of cracking open Xcode doesn't concern you, give it a try.

At the same time I'm not suggesting the entire app should be built, any more than I'm suggesting designers write production code (I'm imagining several developers getting very nervous here). Focus on one feature at a time, that is after all likely the design task you're working on. Even when we redesigned the entire Canadian Tire mobile commerce app, we ran our sprints one feature at a time. But over time we could have built a fairly robust end-to-end experience by connecting each prototype (although I recall trying and the number of art boards and spaghetti lines connecting the prototype screens began too much for the app to bear). The same iterative approach would work with SwiftUI and the end result might be a full user journey, or a complete mess.