Thoughts on Design Software

There’s a great scene in “Under Great White Northern Lights” where Jack White discusses the finer points of his choice in electric guitars. His explanation reveals a nearly masochistic approach to performing live; not taping picks to the mic stand, playing cheap plastic-body guitars, setting up the stage with instruments far from each other.

All this self-imposed difficulty is aimed at fostering a better creative process. While this approach may not be right for everyone, it can certainly be observed that creatives (in any arena) have strong preferences when it comes to our toolkits. In the interest of sparking discussion around choices of design tools, I’ve put together some of my observations from the last few months

Choosing the Right Tool

I’m beginning to think that the decision to use Photoshop over Sketch makes me an oddball. True, Photoshop wasn’t originally intended for things like UI design, an arena in which Sketch shines. Nonetheless, hardware restrictions aren’t a thing of the past.

I do the vast majority (about 99%) of my design work on a mid-2010 MacBook Pro. It’s a frankenstein machine with maxed-out off-brand memory, and an internal SSD where the Optical Drive once was. I’ve been comfortable enough with those upgrades, but I’m not too sure about upgrading the graphics card, which causes Sketch to crash every 15 minutes until I restart my machine.

It isn’t efficient for me to use the newest software, nor is it cost-effective to upgrade my hardware setup. This is where choosing the right tool becomes crucial.

By choosing the right tool, I don’t mean the fastest or the best, but rather the most appropriate. There are more factors at play here than objective ease-of-use and efficiency. When I started designing, Photoshop was the de facto UI design tool. Six years in, I’m much more familiar with PS, and again my hardware setup makes use of a product like Sketch impractical.

In the context of working with a team, the appropriateness of tools becomes more nuanced. What if I can’t use Tool A, but my teammates only know how to use Tool B? In such a case, perhaps the best course of action is to ignore the specifics, and focus on the core design & production specs. A button spec such as “42px height with 10px left and right padding, a #12aeeb background color, and type set in 16px Source Sans Pro Semibold” can be communicated in common language shared across softwares, eliminating the need for a homogeneous toolkit and allowing teammates to select the tools they most prefer.

Inconvenience can be a Good Thing

Ever since I installed a second hard drive this past April, I’ve received an annoying error message every time I open any Adobe software.

Sure, I could fix it and stop dealing with the minor annoyance. What I’ve realized, however, is that the anticipation of this mildly obnoxious warning (which turns out to be a non-issue when using the tools themselves) deters me from making a typical designer mistake: jumping straight into software without putting forethought into design decisions.

I’m inclined to think ahead of time about whether I really need to open the software, or if I might better spend my time sketching out a blueprint before digging into details. Of course, the inconvenience isn’t enough to keep me from getting the work done. Rather, it’s what I’d call a Goldilocks inconvenience — just enough to spur a bit of forethought.

I suppose this situation doesn’t apply to most design tools. Nonetheless, I find it interesting how we can creatively leveraging minor annoyances to our advantage.

Learning how to Learn

Within the larger context of design softwares, I find the ever-growing subset of prototyping solutions both plentiful and exciting. The downside, paraphrased as described several years ago in Barry Schwartz’s “The Paradox of Choice”, is that more choices can become a burden.

With the all-you-can-eat buffet of prototyping options, what’s a designer to do? There simply aren’t enough hours in the day to dig into every single solution with an equal level of due diligence.

In the past six months, I’ve learned (or at least begun learning) more softwares and coding languages than I can count. What sticks with me is the importance of learning how to learn, as opposed to learning how to master something.

By and large, the softwares we use as designers are analogous to one another. Concepts like layers, screen comps, art boards, anti-aliasing, timelines, and embedded files are shared to varying degrees across a multitude of softwares. Understanding these core concepts makes picking up new tools significantly faster and easier.

Proximity to the Means of Production

Easy tools make for shorter path from idea to visual representation. This does not, however, make them good tools.

Typically, the more difficult a tool is to use, the closer it is to the means of production. Forcing oneself to design a website in the browser using a text editor is more difficult than doing so in a raster-based software. The benefit of doing so is that what is created is very close to a final product. In addition, the array of options is less opinionated, as more difficult tools tend to be less proscriptive.

I’ve been using Tumult’s wonderful Hype Pro software to create prototypes and animations for about 6 weeks. What I’ve found is that the software is much quicker than writing code and, because it produces HTML documents, keeps the designer grounded in what can and can’t be achieved within current HTML & CSS standards.

By way of comparison, Adobe After Effects offers a much greater range of animation options, for example animating individual anchor points of an SVG element. Although these options allow for the creation of more complex animations, such animations would likely be heavily altered if not thrown out entirely in production.

The idea that designers should be close to the means of production is nothing new. Today, this means seeing eye-to-eye with engineers, where in the past the same idea applied (and, to be fair, still applies) to working closely with pre-press and printing specialists.

Focused & Modular Software

Feature-creep can be a nasty thing. Plenty of design & tech professionals know it, but fewer seem able to avoid the siren call of just-one-more-feature. It’s refreshing when a tool comes along that does a few things really well.

I’ve got a smile on my face as I type this and the characters show up on one of my favorite new tools that exemplifies the focused approach: iA Writer. What iA Writer promises is distraction-free writing, and after using this tool for several months, I can say with confidence that it absolutely delivers on its promise.

With that, I’d like to make a prediction for the next ten years: that we’ll see a lot more of the focused and modular approach to design software. These types of apps have a particular appeal in that their focus and simplicity makes them more likable than their bloated counterparts.

Conclusion

Tools don’t make the designer. But they can influence the experience of designing and making things. With that in mind, critical consideration of the tools and softwares we use can eliminate day-to-day frustrations and friction between designers and developers.

At the end of the day, the best design tool is the one you have close at hand. And that might not even be a software.

I am currently a student in BDW’s 50 week program. See my work at tinyeahno.com

Follow RE: Write for more articles from BDW Students

Learn more about the BDW program.