Aligning design tools with design practices – Part 2

Will Rockel

Will Rockel

I'm a UX designer, so my mom has no idea what I do.

Are the tools your teams use in your organisation’s design function aligned with your practices? In Part 1 of this article, we explored why this matters, and what decisions to use tools can tell us about an organisation and its design culture.

In this second Part, let’s look at a systematic process you can use to objectively understand how well your tools align with the maturity of your design practice, and roadmap your way to a better design culture overall. I’ll also give some recommendations for next steps, based on what that analysis reveals for you.

Understanding how your tools support design culture

The top three UI tools — Figma, Sketch, and Xd — have basic feature parity, so how do you choose the right tool? I would encourage you to think beyond the features and consider how the tools can encourage a kind of collaboration that works for your organisation. That doesn’t mean making it easier to leave comments ordering changes. I mean real collaboration between product, design and dev to solve meaningful problems for your organisation.

Be flexible, and stay focused on the people involved in the process.

At Cogent, we take a critical-thinking approach to the way we work, and then select the right tools from our toolkit to move us towards that goal. We start by thinking about people and collaboration. Based on this ideology, design culture practices could be placed on a spectrum. I’ve included a few examples of extreme ends of that spectrum here.

This table is by no means exhaustive, so feel free to add your own examples. The point is to start establishing a roadmap for a design culture in your organisation that is based on principles manifested through specific actions. 

For example, I value collaboration between designers and developers, so on the immature side of the spectrum might be “no collaboration between devs and designers” and the other end of the spectrum would be “has regular design pairing sessions”. The value of this exercise comes from mapping practices specific to your team. When completing this process Include people who aren’t designers. You might be surprised at their interpretation of the status quo and expectations about design.

Since tools, practices, and culture are all connected, the next logical step is to repeat the same process for your tools.

Mapping culture and processes to reveal strengths and weaknesses

Finally you can map your culture and practices relative to your tools, either at a macro or micro level. For example you could conduct a quick survey among your entire team or department asking how they would score the organisation’s design maturity and tool efficiency. Alternatively, you could run a workshop to see where individual practices fall on the matrix shown below. If you want to track individual practices like this, write each of your practices on its own post-it, then place each post-it on the appropriate place on the matrix. Either method gives you a valuable heat map of sentiment as a benchmark for tracking change and deciding next steps.

Roadmapping a better design culture

Obviously, since I don’t know the specifics of your organization, I can’t give you clear advice on what your particular next steps might be once you complete this analysis. However, I do want to include some general thoughts about what your score might mean, and potential next steps.

Your culture is good, and your tools enable that culture

  • Congrats! It’s a great time to push your boundaries.
  • Keep focusing on a product-led growth strategy.
  • Keep collaborating with product managers and developers.
  • Try using fewer mockups. Empower the rest of the team to make simple design decisions.
  • Focus on higher-level problems: Why is the product the way it is? What do users really need?

Your design culture is bad, and you have bad tools

  • Establish some design principles, and use them while making design decisions. If design decisions are being made by other departments, then gently ask how those decisions are aligning with team goals.
  • Designers often find themselves working across different departments like tech, sales, marketing, and product. Although designers often have insight into several parts of the business, design as a discipline is rarely granted the same level of autonomy or authority as the departments it enhances. If your culture and your tools are both poor, then perhaps design is being guided by other departments or priorities which are in conflict with your team’s objectives.
  • Find a problem space, or objective for design to own within your organization and raise your flag high to celebrate your contributions to related outcomes.
  • If the core issue is a problem of influence, then demonstrate the value of design with objective data. If speaking in a language your audience understands. Use articles from business publications to make business cases

Your design culture is bad, but the tools are great

  • Some tools, like Figma, include templates for running retros, card sorting etc. Use the tools to introduce better practices and reaccess how you conduct common rituals.
  • Evangelize about the ROI on design.
  • Actively engage your team in design decisions. 
  • If you are a designer, involve your team early in the design process with sketch workshops and design pairing. Ask your team, “Is this enough detail?”, and actively listen to the responses. Spend an equal amount of time communicating how you arrived at a solution as you do explaining the solution.
  • If you aren’t a designer, get into the habit of asking your designer, “Why did you choose that solution?”

Your design culture is good, but your tools and practices are bad

This is unlikely to be the case, but let’s hypothesise.

  • Leverage your good cultural practices to explore other options for tooling.
  • Is design a singular practice in your organisation, or does it also include things like marketing? Removing some tools is an easy pitch (because it saves money), but make sure you understand why that tool was selected before it’s discarded.
  • Perhaps the design team should re-organized so that product design, marketing, and internal design functions have dedicated toolsets and practices instead of a general one. This gets to the heart of the question in part 1 about how your organisation opens a bottle of wine. This kind of change is unlikely to be quick and shouldn’t be a unilateral decision, but a clear problem statement is the start to crafting a solution.  

Organisational change is a slow and difficult process, but small incremental improvements to daily practices can yield surprising insights and results for your entire team. Selecting the right tools is a manifestation of that change, but remember: sometimes those tools aren’t software. Switching to Figma for UI design won’t improve your outcomes if you don’t also change practices across the entire design process. Building a design system won’t result in faster delivery cycles if teams aren’t empowered to make decisions. Design isn’t a deliverable, it’s a process, and it involves the entire organization.

Good luck. And if you ever want some assistance, Cogent is happy to help.

Liked this post? Share it on…

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Related posts

Design
Ben Rowe

Getting on board with onboarding – Part 2

Welcome to part two of my post on User Onboarding. In part one, we talked about what good onboarding is, and isn’t. And after showing some great onboarding examples, we talked about how understanding your user – and understanding the value that you’re providing them – is crucial to a successful onboarding experience.

Read More
Design
Ben Rowe

Getting on board with onboarding

One of the key contributors to a successful product-led business is a great user onboarding experience.
By helping people understand how your product works and how it can help them, you’ll be able to activate more users and turn them happy, into paying customers.

Read More