iOS and Android prototyping tools are at a dead end

With Pixate recently deceased, it’s a good time to reflect on where we’re at with prototyping tools for native.

Having spent half my career designing websites, and more recently designing them in-browser, I’ve struggled the past few years when designing native apps in iOS or Android.

The web is great because with a bootstrap, or the right set of skills, you can mock things up very realistically to the final product. You can ditch pictures of a site strung together in InVision, for an interface that can be stretched, folded, and interacted with on a deeper level. This is great for testing, demoing, and iterating. What’s more, it the actual medium the final product lives in.

My point is this: mocking up websites with a browser, is realistic. So why do we accept tools that fall short of realism when it comes to prototyping on native?

Why aren’t native prototyping tools realistic?

A major shortcoming of native prototyping on Pixate, Framer, InVision, Flinto, etc is NONE of them can simulate a keyboard. When I need to test users entering keystrokes into an input like a form, there is no way for these tools to test that interaction and get feedback.

Simple logic is another blindspot these tools have; we don’t have a good way to surface multiple modes or states depending on a specific type of user input. The beating heart of interactivity, missing, in favor of a linear sequence of static screens. Even if I could accomplish some of this in Pixate or Framer, my project scope limited me from designing even a modestly sized app. This has required me to break my design down into pieces to gain more space and keep the complexity down.

Meanwhile, I can mock up brilliant animations on Framer that are truly unique and beautiful. Animations that I cannot export, and cannot be used in the native authoring environment of my app. We’ll just have to look at it, and eyeball it while we build it again.

Duplication of work: We are literally building our apps twice

How is this possible (moreover acceptable) to designers? Would our clients be ok with this if we broke it down like this? Some of the astute ones might say “that’s the cost of admission, these are the tools we have”.

This reminds me of S.R. Hadden quote from the movie Contact:

For designers to accept and live in this scenario is understandable, yet deserving of criticism. On one hand, for years we’ve come to accept Adobe seeping features we don’t need into apps that are bloated beyond usefulness. On the other hand, we should do better to drive the conversation as users of these apps and demand tools that are better suited, and more realistic to the platforms we design in.

Maybe those demands have been heard in terms of volume, but not content. What we have now is a paralyzing array of tools that accomplish the same set of things: Animation, clickable daisy chains of static images, custom scripting languages. None of these tools can export usable code, simulate logic, or deep interaction such as keyboards.

No grievances without solutions

I’m not one to lodge a complaint without having a few solutions, so here’s where I’m currently at:

  • Use a web bootstrap to simulate native. It’s easy to update, moderately realistic, and works on devices. Here’s one that’s good at iOS [Rachet], here’s one that’s good at Android. [Material UI]

  • Double down on process and ship design to devs really, really quickly; institute lean UX like you mean it. If we put more into Kanban, pairing with devs, and leveraging the actual medium as the prototype, then maybe we cut out the need for a prototyping half measure.

  • Learn Storyboard in Xcode. Yea, I don’t want to do this because it’s just not designer friendly and does require coding knowledge. Storyboard is definitely not plug and play.

  • Axure. This tool brings with it some cost and learning curve challenges, but this may be one of the best solutions around for simulating, testing, prototyping key input and logic. This one get’s overlooked a bunch, but has less of a learning curve than Xcode or Android Studio.

I hope this spurs thinking about where we’re headed with prototyping. We’ve hit a saturation point and it doesn’t look like we’re getting closer to a solution, because we’re not addressing the right problem. Maybe we need to ask for a tool that realistically simulates the platform we design on, and the native code it uses.

Previous
Previous

Ultra-lean user testing with Amazon Turk and Google Forms