The Design Tools We Really Need

Micah Sivitz
Jul 6, 2016 · 6 min read

Designers have never been more empowered to design beautiful interfaces. Thanks to tools like Sketch, we can now mock up interfaces faster than we can edit photos. Other tools like Framer, Pixate, Invision, Flinto, etc, have come around that allow us to take these mock ups into clickable prototypes and animated transitions. Prototypes can be taken so far as to even trick people into thinking they’re seeing a fully functional product. The state of design tools has never been more exciting.

The Designer’s Toolbox is Full (of similar tools)

Although we have a ton of tools to choose from when designing, each tool has functional overlap with our other tools. It’s like having a philips-head screwdriver and a flat-head screwdriver — they both have similar functionality but they’re meant for different screws.

The inherent problem with most of the tools designers use today is that they are focused on working in isolation. Designers often learn to do things in one specific way and develop habits that make them more efficient at their process. The problems kick in when many designers are working together but their processes differ.

What designers really need is a set of tools that provide the following:

1. A Unified Syntax

Every designer has their own way of ideating, pitching their work, rounding their corners on buttons, implementing their gradients and shadows, saving their folders / files / pages / artboards / layers, defining a user flow, etc. These subtle differences cause problems when working on a team because it takes time for teammates to parse through the work and understand it.

What we need:

  • A process to follow that creates a common design language for every designer within a given team.

2. Cross Platform Typography

Text handling differs from platform to platform. The way Sketch handles text is different from the way the web handles text which is different from the way iOS handles text which is also different from… etc, etc

Some platforms position text according to a baseline grid, some use the top of the text frame, and some… I don’t know how they work. Handing over designs to an engineer is a different conversation depending on the platform. Everyone ends up confused and there’s a lot of back and forth in order to get things the way the designer intended.

What we need:

  • Unified type formatting across all platforms.

3. Adaptive UI (Dynamic Text)

All text is static in the current suite of design tools. When changing text blocks to different sizes and lengths, the rest of the interface in a mockup doesn’t know how to react. When designers need to show a version of the same screen with different data, languages, or font sizes (eg. accessibility mode) they have to create a different mockup for each scenario. Making prototypes with accurate data means taking the time to fill in every text field with real world examples and adjusting the rest of the UI to adapt.

What we need:

  • A design tool that can insert real world data and allow the UI to adapt accordingly.

4. Collaboration Tools

Iterating on old work is painful. Because design systems are constantly changing it is often difficult to pick up an old project and integrate it into the current one. It takes lots of time to sift through the work, take the learnings, and integrate them into the ideation for the current project.

Engineers have already figured this out. They use systems like Git to control each iteration of their work and contribute to services like Github to collaborate with their teammates. When they’re ready to merge their work with the team they present a “pull request” that asks the rest of the team to approve the changes. This process allows for many people to work on the same project at the same time without any conflict. It also allows for collaborative work that can be easily spun off and changed into something completely new (open source).

At Shyp, our design team uses Github for our styleguides, but Github is not a tool built for designers.

What we need:

  • Better tools for collaboration.
  • Ability to easily share a library of resources between a team of designers without any worry of conflict.
  • Ability to pick up one another’s work and hit the ground running.
  • Ability to source old work and integrate it into our current project.

5. Seamless Transition from Design » Code

Going from a pixel perfect design to development is like starting over. Designers spend a lot of their time red-lining their document, laying out user flows, and spec’ing out ideas. Prototyping tools have come a long way but they still only give the engineer a concept of the idea. An engineer still has to spend a bulk of their time interpreting the work the designer did and translating it into code. Then, once it’s built, there’s inevitably a back-and-forth between the developer and the designer to make sure what is going to production is exactly what the designer had mocked up.

What we need:

  • An easy way to take what we’ve designed and translate it to production ready code. Engineers should be able to focus on the complex logic of the application without wasting time perfecting the pixels in the interface.

The Good News

These problems are not unknown and there are many companies trying to solve them today. The industry has recognized that the quality of our products will go up if we make design tools better.

Shoutout to the brave teams tackling these problems

  • The team at Principle (which may or may not be one person) is a super cool prototyping tool that is going in a really strong direction.
  • Zeplin is a really cool app that’s made for that handoff moment between a designer and an engineer. It’s got a lot of promise.
  • The team at Figma is working on a “collaborative interface design tool.” This is a different take on the problem but definitely an interesting one.
  • Google’s Material Design has some of the best UI guidelines I’ve ever seen. Tools like this help designers think systematically.
  • The design team at Airbnb has written publicly about the system they’re building for their internal team. I love the direction they’re taking with the living components library. Not something every team could do, but it’s awesome they’re sharing their ideas publicly with the community.
  • Apple just announced their new Swift Playgrounds which is an exciting attempt to make coding easier. Although this is on the other side of the spectrum, I still think it’s exciting and worth the mention.
  • I heard a rumor that Apple has had an internal design tool for the past couple years that they call “Micah.” I can’t validate this is true but of course I’m very curious, especially given that it’s (cough) named after me (cough).
  • Also, shoutout to Sketch, because ❤️

Anything I missed? Let’s chat on Twitter or follow the Shyp Design publication for more thoughts from our design team.

PS — we’re looking for A+ designers to join our team. If you’re interested or know anyone, send them our way!

Shyp Design

Thoughts from the Design Team at Shyp

Micah Sivitz

Written by

Designer at Dropbox. Years of non-writing experience.

Shyp Design

Thoughts from the Design Team at Shyp

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade