The Prototyping Toolbox is a Mess!
Today’s prototyping software fails to facilitate the workflows we really need.
Prototyping digital products is a long and hard process. Navigating your ideas through various iterations of wire framing, visual design, interaction and animation, distribution, testing and feedback and finally the hand off to the developers… The problem is, nobody has time for long and hard.
Prototyping needs to be friction-less to facilitate fast and regular validation of ideas.
Added to our current dilemma, the prototyping tools to our disposal have some serious UX issues. Ironically they suffer from the very flaws we’re so dedicated to spare our users from:
- lack of essential features
- incompatibilities
- steep learning curve
- bad performance
- inefficiencies, redundancies and all sorts of overhead imaginable
Dissatisfied with my own experiences, I did some research within the UX community and asked colleagues what their workflows are and if the can recommend any tools.
Since everybody agrees that prototyping is essential to the creation process, there were a lot of people interested to join the conversation.
Although the majority of them admitted having problems with their workflow, not everybody was as critical about the status quo as myself. Why is that? I’m inclined to think that some of our colleagues started rationalising the pain they have to put up with to make it more bearable. There is that notion that due to the complexity of prototyping the stakeholders in our projects have to make the extra effort to put together and implement complex software workflows. While that is a perfectly healthy mindset for software users, I feel that it is our duty as designers to challenge the way things are in order to unearth potential for improvement.
6 most common explanations
To get a bit closer to potential areas for improvement, I would like to examine the 6 most common explanations people give, when describing their prototyping tool set. To me, all of those are valid approaches to deal with the tools we have today, but they are also very telling in terms of where existant tools fail to facilitate the workflows we really need. Let’s have a look:
1. There’s plenty of Fish
“Aren’t we lucky? All those tools to our disposal.”
The Wikipedia page comparing prototyping tools lists more than 50 tools in this category and at first glance quite a few come to my mind that aren’t even on that list. Every week there are two new medium articles proclaiming the arrival of that new prototyping tool everybody in their sane mind needs to check instantaneously.
Well keeping a sane mind is exactly the problem in this context.
Keaton Herzer wrote a great article highlighting how an excess of choice is nerve wrecking and counterproductive, when quality and functional range of the options available are not satisfactory. The overhead of evaluating and trying out all these tools is something we cannot afford to maintain.
‘Prototyping fatigue’ anyone? We don’t need more choice, we need quality.
2. Mission to Mars
“We’re flying to Mars, our work is rocket science, an existing solution to our problem is unthinkable.”
Just ‘wow’, totally impressed here! No in fact, I would be willing to accept that kind of reasoning if your team was actually building voice controlled VR applications. But in most UX projects we’re designing screen based applications for either mobile devices or the web.
Am I really asking for too much in requesting a solid industry standard for these common use cases?
3. Chain Gang
“We’re building a tool chain from multiple products.”
It’s hard to deny: due to the lack of integrative solutions available today, sadly, this is pretty much the only way to go. Nevertheless those so-called tool chains are rather loosely linked forcing us to deal with export tasks, dissenting interface concepts, unstable plug-ins and an ever-growing mess of file formats and versions.
Extensibility is great, but you shouldn’t have to rely on too many different tools only to achieve the most basic tasks. For example, to date, most teams have to handle screen design and interactivity in separate applications.
This is nonsense! In order to achieve holistic user experiences these things should be designed in the same context.
4. Throw-away products
“Prototypes are throw-away products and are only meant to illustrate one feature on a single occasion. Pick whatever tool matches your problem.”
The fact that we work in sprints nowadays doesn’t mean we don’t have to work sustainably. How about teams that are extending and tweaking their product over several years? They are surely not willing to build every other prototype from scratch. Depending on the feature you’re working on you spend a couple of hours simply mocking up the context of your application, before you even begin building the actual feature.
I would certainly prefer building and testing multiple features in the same prototype with a prototyping tool that supports the creation of design conform modules with a smart pattern library.
5. The Enterprise Solution
“Everything’s possible… we just need to figure out, how!”
The opposite of the quick-and-dirty approach are those software juggernauts that promise to do it all. The trouble with these, however, is that they provide functionality at the expense of the user experience. A couple of days with the product and you still have no idea how to accomplish your specific task, or whether that feature is available at all. It feels like Microsoft Office 20 years ago — Clip Arts and VB Macro in one menu with no discernible structure to it.
To really wrap your head around that tool, you’re bound to put so much research and engineering into your prototype that you’re basically building your application twice.
Put your ingenuity into your product, not into the tool you are using!
6. Well… Unicorns
“Who needs design software? We’re designing with code!”
Designing in HTML, CSS and JavaScript — Sure, there are a couple of experts that do have the skills to pull that off. And, theoretically, this is super effective, your code might even end up in the production repository.
There is no arguing that a profound understanding of the underlying technology is highly relevant to inform your design. But after the hundredth blog post “Designers have to learn to code!” we still have to accept that developing designers are still the exception to the rule. Especially if you keep in mind that the web is only one of several platforms that we need to design for today. What about designers that also write Objective-C, Java, C#, PhoneGap, Xamarin, …
Anyway, even if you’re pretty great at coding, the chance that you’re iterating as fast with — say — CSS as you would be using a good design tool is rather small.
But this is exactly the point:
We design best, when iterating ideas comes at the smallest effort possible.
That’s why I am so passionately calling for better design software. As stated before there is no shortage of contenders in this market and some of them even show great potential. But none of their offerings feel like a finished product. As a result our workflows remain fragmented. To get around the headache we need software that provides both a broad functional range and great usability.
Ok, this has been a lot of complaining on my behalf. How do you feel about the situation? How are you keeping up in today’s prototyping software jungle? Please, let me know in the comments!
If you suffer the same as I do, give some sympathy via that heart shaped icon below, or follow me for further updates on the topic.
Joachim Tillessen is partner at emjot, a Hamburg based company specialising in custom tailored web applications and corporate design solutions. On top of working hard on the best design and UX solutions for his clients, he’s currently doing research on the future of prototyping in digital product development.
