Do we need better prototyping or simpler coding?
No points for guessing. It’s the second one.
As designers, we don’t have a lot of consensus. We can’t really agree on best practices — design @1x, @2x, @3x? (hint: it is @1x)
We can’t really agree on what to call ourselves — am I a UI-UX-Product-Service-Full-stack-Unicorn?
We certainly can’t agree on what tools are best to do our job — Sketch, Photoshop (I got jokes), Adobe XD, InVision, Proto.io, Framer, Pixate?
One thing we can agree on is that we need better tools. Tools that bridge the chasm between design and development, instead of shout across it.
But before we get into how, lets look at why:
The current prototyping tools landscape:
Essentially there are 3 types of tools:
- Vector tools
- Multi-page tools
- Single-page/Layer tools
Let’s take a look a each one:
Vector Tools
If you have been anywhere near a designer, you have seen or used one of these tools. Inevitably 90% of designs are done inside vector based programs.
Pros:
-Super easy to use.
-This ease of use means designers can really express their vision for the design accurately.
Cons:
-Limited to no interactivity. We end up producing flat art-boards and then stringing them together in another multi-page interactivity tool, like InVision, to mimic interactivity.
-Designing at multiple screen sizes and resolutions can be a pain (Sketch is making this much easier though).
-Require complicated spec sheets and handover files to ensure the developer can interpret the designs.
Multi-page Tools
As mentioned above, these tools tend to take flat designs made in a vector program and string together the whole flow of the app. In fact, most of the good ones interact directly with Sketch to improve the workflow.
Pros:
- Pretty easy to use.
- Allow designers to fake a real app relatively well.
- They are great for demonstrating flows, animations and simpler interactions which is useful when proving the concept.
Cons:
-All the interactivity is, essentially, fake. By this I mean there is no actual internal logic inside the app. Things like text fields and data are tough to mimic.
-It’s also very difficult to show lower level animations and user-interactions.
-You have to create the design in a vector program, and then string together the pages.(InVision has a pretty good workflow with Sketch though)
-Still difficult for a developer to interpret the designs.
Single-page/Layer Tools
These tools are primarily for prototyping out smaller, more detailed interactions. Useful for demonstrating single user flows and moments.
Pros:
-Relatively high degree of interactivity. Some tools, like Framer, allow you to make working text fields, use live data sources and responsive interactions.
Cons:
-High learning curve. The more interactivity, the higher the learning curve. Pixate requires a passing understanding of Javascript to really exploit it’s features. Origami requires keeping track of a vast set of nodes. And in Framer, the design is done in code (CoffeeScript, which is like a more readable version of Javascript).
-The developer needs to spend time duplicating work you have already done.
Okay, so what’s wrong with these?
What’s the problem with a high learning curve? If you can demonstrate interactivity to a developer in code then surely it is worthwhile?
Well, no, not really.
None of these tools solve the main issue in UI design: bridging the gap between design and development.
When you pass your design on to the developer, all that work learning CoffeeScript and stringing together nodes, that’s all thrown away. These things may help the developer interpret your design better, but he/she still has to sit down and build it from scratch, in code.
This takes time. Yours and theirs.
So, what is the answer?
It’s not to make these prototyping tools more complicated. It’s to make coding UI, more intuitive. In a perfect world, a designer could build the UI, in code, whilst the developer focuses on complicated developer bits™. The problem is, right now, doing that is really hard.
Introducing Fuse:
Fuse is not a prototyping tool. In fact, it exists so that prototyping (as most people currently use it) should no longer be needed. It is a mobile app development framework (fancy way of saying: a set of coding languages that you use to make apps) that’s more accessible, but still outputs 100% native code for both iOS and Android.
What truly makes makes Fuse different, is that it is designed to bridge that gap between designers and developers by empowering designers to get involved in the process earlier and more often. Building UI in code is simpler, more intuitive and scaleable. When developers no longer fear designers intervening late in the process, you know you have a good workflow.
UX Markup — An introduction:
You can think of UX markup as a coding language built specifically for making mobile UI’s quickly and easily. It’s an XML based language so you might recognise the way it works already.
Want to make a Rectangle? Simple:
Want to add some text into that Rectangle? Cool. Just add a <Text> tag inside the <Rectangle> tag:
Drop-shadow? No problem:
Looks like a button, should we make it clickable? Sweet:
This is obviously just scratching the surface of what Fuse can do. It is an immensely powerful UI tool with a large list of triggers and animators. Designed to build entire, production ready apps, for both iOS and Android simultaneously.
Why is this cool? Because that code you wrote right there does not get thrown away. It gets compiled down into native code on both iOS and Android. That’s right. You are building the UI. In real time. In code.
That means you don’t have to spend time prototyping. You can make changes to the UI, test them, and iterate. Simple.
But what about those ‘complicated developer bits’™?
Don’t stress, they are there too. Fuse is designed so that the UI is built in UX Markup. The more complicated interactivity and data-binding is done in vanilla Javascript. Yes, vanilla Javascript — not some superset that you need to learn, but plain, easy to read Javascript.
“Ah, but what if I want to use The Super Advanced Feature™ in Not Yet Shipped OS Version?” I hear you say. No sweat. In Fuse, you can include native code (like Java and Objective-C) in your Fuse projects. There’s literally nothing you can do with the native platform tools that you cannot do with Fuse. Like adding speech recognition to your iOS app, for example.
Which parts of that process you take part in, is really determined by how much you are willing to learn.
Tl/dr:
Don’t waste time prototyping things you have to throw away. Build production ready apps in Fuse as easy as you prototype today.
Fuse is powerful and accessible, for both designers and developers.
Try it out here
