The thing I dislike about most prototyping tools -- and Origami is no exception -- is how so much emphasis is placed on polishing micro-interactions before the app flow is even in place. It's like trying to produce a movie by doing color correction before you even have a screenplay.
The mobile previews from Origami-like tools will show a refined "golden path" through the app with beautiful stock photos in every screen, but more boring use cases tend to be ignored. This tends to lead to usability problems down the road, when users discover those "dead ends" that the design unconsciously avoided.
It's also frustrating for programmers when you are handed a high-gloss prototype that has no relation to the actual platform UI classes and guidelines. Implementing all those fancy little triggered animations takes so much time that no one has time to peek at the iOS guidelines and notice how the design actually breaks 80% of Apple's rules.
Companies like Facebook have enough resources and actual UX competence to get these things right (eventually), but I've seen this happen too many times at smaller agencies and startups.
This is a strong argument for prototyping the workflow with index cards and pen; deliberately rough to deter people discussing whether it should be cornflower blue.
(I think there was a tool that offered this, XKCD style, but I've no idea what it was called)
Early on at my first appdev job, I was showing off all the changes I had made in functionality of the website. The response I got: "make the box bluer"
I think the way to go is to create a mood board / app style guide / (whatever you like to call it) that shows the design of elements. So you will have the design of buttons (all states), fonts, font sizes margins, and maybe even only one fake page design.
When you present this next to the interaction design customers can understand what is going on and most can imagine what the end product is going to look like.
And imho it's also a managers job to guide the customer away from (for that moment) distracting remarks like 'make the box bluer'.
You can simple fix this by saying something like "Ok, we will note your remark about the color".
A lot of larger companies have responses just like this. I was in a meeting yesterday where we talked about a progress bar for 30 minutes.
Years ago I decided to demo everything in HTML/CSS. I find that I can write web code faster than I can whip something up in a prototyping tool. The demo can also be viewed in a browser. It's not 1:1, but it gives me a lot more control to make things bluer.
I have been using Balsamiq mockups (Desktop) for years and the lack of interaction design is still a huge drawback that sadly won't be fixed. Which means that when you are showcasing/previewing your mockups, users can't really interact with them as you would with usual UI widgets.
But for certain fast prototyping it is unbeatable, probably faster than pen and paper once you get used to it.
The last iOS UI I did prototyping work on was done using PowerPoint using a set of sketch-styled components (from this[1] guy, although I can't find the particular set that I used on his site right now).
Mostly worked out pretty nicely and avoided the inevitable digressions into "what shade of puce should the title bar be", but there is no way to adequately express on Hacker News the facepalm I made when someone complained that the sketch/wireframe style wasn't going to work too well for the finished app.
What many people don't realize is that you can put the paper in front of potential users and have them interact with it. You can draw/move the results of their actions to get an idea of how they will use your software before you have to write a single line of code. Getting inside the mind of your users and seeing their assumptions and desires in action is incredibly valuable.
Where I work, our solution to at least part of this has been to keep a tight feedback loop between design prototypes and developers: We make it a habit to get engineering eyes on things early on, so we can ask, "can we do this easily? Does Android support this natively? Will this trigger a big refactor somewhere else?"
To your movie analogy, I'd compare tools like Invision to scriptwriting and storyboards, and tools like Origami to animatics and previsualization.
Exactly this. There are countless tools for flows and storyboards. Origami and others are competing to be the photoshop of software interface design. Exploring animations, visualizations, events and movement with speed isn't a solved problem yet. Which is probably why these things are emphasized in the marketing for the tool.
> It's also frustrating for programmers when you are handed a high-gloss prototype that has no relation to the actual platform UI classes and guidelines. Implementing all those fancy little triggered animations takes so much time that no one has time to peek at the iOS guidelines and notice how the design actually breaks 80% of Apple's rules.
Yup, that's why I feel it's super important that these type of tools feed into a production workflow. It means you can hit those constraints upfront(removing needless back and forth between eng<->design) and you as a developer don't have to worry about pixel minutia.
It's a win-win on both sides, but a really hard sell since the impact is a second-order effect reflected in the work produced instead of the tool its self.
I agree completely: the defaults should be the platform conventions. This wasn't much a part of the original Origami, but we've tried to improve that in the new version by providing some premade iOS and Android components for the most common things.
You can show an iOS styled Action Sheet, Android checkbox, etc., without building it from scratch (look in the layer + menu). While this doesn't include everything you need to know about iOS or Android conventions as a designer, it does encourage people to start with the standard controls and then look to custom solutions only when they don't fit. As much as possible, I tried to make the Ports on the layers match the API that the engineer sees in ObjC or Java so it feels like you're speaking the same language.
You can also break these components open and customize them, somewhat like you would as an engineer by subclassing or composing sub-parts. Internally at FB, we also made some custom layer patches that match the UI conventions for the FB app, Instagram, etc so you can have consistency by default. These bundles of layers & patches are called Systems (still working on docs for this), which you can build and distribute among your team. There is some more about this in our F8 presentation earlier this year.
The idea is that as a designer you can fill in the text for your Alert View or whatever instead of messing around with resizing rounded rectangles & text boxes like in Sketch.
I've generally seen tools like Balsamiq and Invision used for the app flow and tools like Framer and Origami used for micro-interactions. I would, however, like to see something that blends the two well, but maybe that just doesn't fit with enough people's use cases.
Invision is (supposedly) developing a prototyping tool that plugs directly into Sketch. If it ever gets released, I think it's going to be really awesome.
It's more like a warning against getting carried away with the latest tool. It happens easily to developers too, after all (hello useless rewrite in latest JS framework).
Origami is excellent and parametrized animations can be actually useful, it's just not so widely applicable or foundational as some designers and project managers think.
The mobile previews from Origami-like tools will show a refined "golden path" through the app with beautiful stock photos in every screen, but more boring use cases tend to be ignored. This tends to lead to usability problems down the road, when users discover those "dead ends" that the design unconsciously avoided.
It's also frustrating for programmers when you are handed a high-gloss prototype that has no relation to the actual platform UI classes and guidelines. Implementing all those fancy little triggered animations takes so much time that no one has time to peek at the iOS guidelines and notice how the design actually breaks 80% of Apple's rules.
Companies like Facebook have enough resources and actual UX competence to get these things right (eventually), but I've seen this happen too many times at smaller agencies and startups.