My personal history with design tools
Design tools have had a funny past. For many years Adobe had the monopoly with their early versions of Photoshop, Illustrator, and InDesign before later going on to acquire Dreamweaver, Flash, and Fireworks (R.I.P) from Macromedia back in 2005. To me, these were the design tools of my formative years building up my design career.
When I first began using (mostly) Photoshop, it was used to add ridiculous amounts of superfluous layer styles to my compositions as well as doctor the few decent photographs that I took back then.
As I began my foray into the world of design, predominantly in the direction of self-taught graphic and web design, I was blissfully unaware of the complexities of modern-day applications. Complex applications of course existed back then (circa 2004) but my focus was on pixel-perfect brochure websites. We all have to start somewhere…
When working specifically in UX roles I began playing around with Axure as the wire-framing/interaction tool of choice. This was later proceeded with the practice of coding interfaces and then more latterly exploring the possibilities of Sketch with its mountain of plugins.
An ocean of offerings
Today we find ourselves in this fantastic position of having a sea of design tools at our disposal — each seaming to offer some ointment to the itch of solving real-life design problems. This was best summarised when I read an article on Medium poking fun at the myriad of tools that we have on offer today, and how our designs transition from one tool depending on the stage of design we are at. Though the article was of a comic nature, to me it highlighted the gaps that we have to work with when taking a design through its various stages.
We have our wire-framing tools, our interaction tools, our visual design tools, our animation tools, our feedback tools…and so it continues…
This is not necessarily a bad thing, as to seek out one tool that does everything would be equally as painful as you would require to navigate a plethora of menus and views depending on what stage of the process you were working on. Adobe has taken a stab at crossing the design to prototype chasm but from my early explorations of Adobe Experience Design they have ended up with a fairly limited offering for both sides.
On the visual side, the details are lacking in terms of control over the typography, stroke, fills, and shadows of your design. Then on the flip side when you move across to the prototyping stage you are fairly limited to mobile-centric gesture transitions. Yes, the world is going mobile, but we still have laptops and “desktop web” which will be here for some time yet. This use case has completely escaped Adobe’s offering. (Disclaimer: I did not spend all that much time in the tool, so the above is not an exhaustive review and I do appreciate their efforts in tackling this issue).
Without being too exhaustive (I could discuss design tools for longer than anyone would care to read) on the other side you have Sketch, which has matured over the years to become a fairly reliable choice for interface design but is also lacking in the next stage of design — the transitions and states.
Whilst there are a number of plugins available for Sketch, it doesn’t take too long to find one which becomes incompatible with the latest update, so for me depending on boutique plugins for such a core part of my working life is a little risky. That being said, Craft (from InVision) is actively pursuing a resolute approach to solving some of the missing pieces of Sketch and I do have hopes for what they are doing, but let’s see.
Can one tool handle all this complexity?
Given the landscape of the products that we design and build today, there is no concrete tool or set of features that would make our lives easier, but some things are certainly clear. As we continue to design the products of today and tomorrow, the complexity will only continue to grow. People are more connected, more dispersed, more distracted, and more overwhelmed with information than they have ever been in the past.
Complexity in this regard doesn’t necessarily mean a messy interface (you’re thinking Microsoft Office right now aren’t you)? The complexity I refer to is much more engrained in under-the-surface areas. It’s the subliminal connection of your product with the data and customizations that are tailored to each of your users. Interfaces are becoming more and more adaptive in this respect and as such, we as designers must give up the perception of control that we have. This is why so many circles in design are now discussing design systems and component libraries as we are moving away from creating “final” designs but are instead composing all of the pieces that enable designs to be final when the system and the data interact.
What this means for us…
So, we acknowledge that those who we are designing for are going through seismic shifts in the way they use digital products. We as designers are not immune to these drastic cultural and technological shifts. A “typical” design needs to consider some of the following factors, which is not even an exhaustive list:
Data — there are tonnes of it, and our designs have to be connected with the real-world data which surrounds us and our users.
Context — users are switching contexts (and devices) many times throughout the course of a day and we as designers have to consider and design for these handovers to ensure we connect their experiences across each of the contexts. Our devices today can also influence our designs by making available contextual data such as time of day, geolocation, battery levels, etc
Device size — not a new problem, but a persistent one. Gone are the days of fairly uniform screen sizes and resolutions. We need to constantly design across many sizes when considering each design decision.
State — again, not an issue that has just arisen, but is certainly one gaining greater awareness is the fact that your interface will not always exist as intended. What happens when things are loading, when they fail to load, when the connection drops, or when the data is much more or less than what you’re ideal state would accommodate?
Language — before the world wide web, companies operated globally but were more restricted over infrastructure and costs than what they are today. Our digital products and companies of today can literally serve the needs of a global population overnight. This has a huge cultural impact on our design decisions.
Interaction — As devices continue to become more and more powerful, so too are the ways in which we can interact with them. At a design level, we no longer need to consider just simple pointer interactions, but also factor in gestural interactions, touch (+ force touch), and natural language to name a few.
In addition to the above-mentioned points, in order for our designs to withstand any longevity in the marketplace we need to test our hypotheses and get real feedback from real users in real time which brings yet another layer of complexity to the designer’s tool belt. I enjoy using tools like Lookback and services like UserTesting to understand how users interact with our designs but these are also somewhat disconnected in that we need a further step to review and gather feedback which then feeds back into some other tool to ensure we don’t miss all of the points raised.
Even then, once we have tested and confirmed our concepts we still have the tedious task of communicating all of the above to our engineers and colleagues who need to realize these designs. Again, there are tools like Zeplin and Avocode which are trying to plug these gaps, but there is still so much missing when it comes to this handover.
So what next?
As you can see, our current situation is a complex one and is one which we are constantly evolving and learning from. As a profession, designing digital products is vastly overshadowed by the disciplines of engineering or architecture in terms of our vocational experience and best practices.
I do not expect, or indeed hope, that we end up with one tool or process which will address our every need — as, despite sounding overly ambitious, to have a single tool for all of this complexity would only serve to introduce further complexities in our processes and would likely lead us to a particular way of working as such a vast product would not be able to change tack as nimbly as all the smaller upstarts have done in the past few years.
Much like the software industry has always strived to have separation of concerns and modularity, I feel we could benefit from a similar ecosystem with our design tools. The main point of friction that we are living with though is the communication between tools, which I look to cover in part two of this post.
Let’s not lose hope
As frustrating as it can be at times to decide which tool to use for which purpose, I feel that it can also help us to focus on that particular problem area at that particular moment. We also have the added benefit that this large ecosystem of offerings helps to push their counterparts further and faster and to respond much more quickly to change.
Gone are the days of design tool monopolies. We are now in a phase where tools like Figma are truly challenging our current processes against the wealth of other tools out there. I am interested to see how the next few years will play out, but I am pretty confident that whatever changes we see, there will be some game-changers on the horizon.
Until then, the greatest tool that we can use as designers is and always will be communication. Regardless of this tool, or that tool, if we are not able to eloquently share and communicate our ideas without the need for a tool, then we are facing much bigger problems. There is a lot to be said about the power of a pen, some paper, and a lot of conversations — which was a big theme in one of my previous articles: Before the interface.