As many of us are still working remotely, it’s a great time to evaluate whether your design tools and design practices are aligned. Tools reflect culture and practices, so an evaluation of tools needs to consider the role of design in your organization.
In this two-part series, I’ll take a look firstly at the reasons why we choose and use the tools we do, and what those tools say about our organisations. In Part 2, I’ll step through a practical process for assessing the nature and value of the tools you’re currently using, and your organisation’s design maturity, before suggesting some next steps to help you create a roadmap for a better design culture.
Design can be siloed even at the best of times, and working remotely adds unique challenges to your team. When you’re co-located, incidental conversations and spontaneous ideas empower the team to make sound choices. Working remotely doesn’t mean a designer can’t chat with a developer to work out a solution on the fly, but it does mean that the project manager can’t glean insights from the conversation without being explicitly invited. Understanding gets fragmented, context is lost and confusion spreads. These complications can exacerbate an already fragile design process.
The typical design process is collaborative, with input from many disciplines working toward a well-defined mutual goal. It looks something like this:
- Find a problem.
- Research the causes.
- Invent some solutions.
- Build a way to test the solutions.
- Incorporate test results.
- Finish the design enough to hand it off to the developers (or other stake-holders) so it can be built.
A designer’s core competencies can be summarised as: researching problems, facilitating solutions, collaborating on implementation, and communicating outcomes. You may notice that I didn’t include drawing rectangles, choosing colours or making the interface look cool. Those actions are a subset of the core design processes.
Designers create mock-ups not because there is value in a mock-up alone, but because a mock-up is a tool to communicate details to the rest of the team. As a designer I don’t want interfaces to look beautiful because that’s “cool” or on-trend; I want them to look beautiful because beauty and utility are functionally the same.
Looks cool, but not very helpful.
Depending on your team’s capabilities and existing infrastructure, designers may not actually create high-fidelity mock-ups — whiteboard drawings may suffice. They might also prototype directly in code. In any case, a fully detailed visual that cannot be understood or handed off to other team members is not valuable. So why are many organisations still only using their design tools to draw rectangles, fiddle with colours, or choreograph non-browser based animations?
Tools reflect the structure, priorities, and processes of your organisation. Design tools are meant to enable collaboration between designers, team members, and external stakeholders. So the tools, and the ways you use them, should focus on increasing communication and collaboration, because both of those things will improve the ability of your entire team to produce meaningful outcomes.
The right tool for the job
The idea of a single, purpose-built UI design tool is relatively new, so it’s not surprising that organisations are still developing best practices and harbouring old habits. For years, Photoshop was the tool for creating UI designs. Photoshop pre-dates the popular consumer internet so it obviously wasn’t built for the purpose of designing UI. Sharing designs required exporting static images and emailing the files to team members. Comments were stored in email threads, or in a separate file which may or may not have been a living document. Developers spent untold hours slicing images and manually measuring pixels. It was a terrible and tedious process.
An abundance of tools have been developed in the last few years.
Then tools like Invision and Zeplin disrupted the feedback and hand-off processes, but the overall experience was still clunky and complicated. In 2010 Sketch launched a single tool built explicitly for UI design and hand-off. In 2016 Figma launched an in-browser UI design tool that allowed for the creation of cloud-based, collaborative design files. Adobe and Invision have both created similar tools, and Sketch has added similar functionality.
It’s 10 years since Sketch was launched, and now we have a proliferation of tools for designing UI, dev hand-off, advanced prototyping, commenting, user research, and capturing the analytics of user behaviour. It’s great that we have quality tools, but do we really need to incorporate so many of them into our design flow?
How to open a bottle
The tools you use reveal a lot about your priorities
In Consider the Fork, author Bee Wilson discusses how it’s possible to speculate on the material history and culinary rituals of a culture by examining the tools created by that culture. Metal was scarce in Japan, but bamboo was abundant, so chopsticks and a cuisine involving food pre-chopped into mouth-sized bites developed. England had an abundance of trees, livestock, and metal, so a cuisine with specialised metal utensils, and fire-intensive roasts which are carved by individual diners developed.
Re-examining your own design tools and practices in a similar way can not only improve your team’s productivity: it can actually reveal insights into your organisation’s priorities and values.
So how would your organisation uncork a bottle of wine? It could hack together a solution with what you have available, and use a shoe. You don’t need to wait for a new tool, but the experience may be subpar, and in this case, you risk shattering the bottle of wine, ruining the shoe, and potentially injuring yourself. It’s lean, and it can work in a pinch (trust me), but it’s not for everyone.
You could purchase a corkscrew. It’s a proven solution, and in fact the experience can be quite elegant, and elevate the enjoyment of the wine. But honestly, you probably won’t use the corkscrew very often. It takes up space in the drawer, and do you really want a tool for every single process?
Alternatively you can purchase a Swiss Army knife with a basic corkscrew included. It won’t be as ergonomic as using a proper corkscrew and you probably don’t need all the other attachments, but at least you’ll know you’re covered when the need arises.
Each of these is a valid option in its own way, but it’s worth considering why your organisation would choose to use a shoe, a corkscrew, or a Swiss Army knife. I know I would rather spend a design budget on user research and professional development of soft skills than on tools that aren’t being utilised or conflict with my team’s objectives. Being able to add single users might be handy, but using too many tools can have hidden costs:
- training and continual knowledge development
- context switching between various tools
- redundant processes
- confusion over when to use which tool
- legacy files and multiple sources of truth
- managing plugins and extensions
- lower team morale due to unwieldy tools.
We’ve discussed a brief history of UI design tools, and explored the reasoning behind reassessing your tool choices. Effectively, we’ve seen what looking at your toolset can reveal about your organisation. That should give you a little food for thought, I hope. In Part 2, we’ll step together through a process you can use in your organisation to make this assessment systematically, and roadmap a better design culture.