In many of the teams that I have joined in the past, I have found a situation similar to the following — they seem to work and deliver things quickly, but without following a reflected approach to their interface design process; there are almost no shared libraries nor practices; and finally, the design documentation seems to serve a very short-lived purpose, being as useful as necessary enough to keep shipping things out of the door.

For a newly hired designer, such a situation does not look very promising. The implications of this exponentially grow as more and more people become part of the team, even if its size remains quite small. (From my experience, in a team of only three designers you’ll already start feeling the urge of setting up some common practices on how to work together.)

As a consequence, a lot of the initial onboarding time that should be spent on learning how to navigate through the company is spent instead on finding files and previous design versions, all of this in an attempt to figure out how the product works. Having these at hand also helps recognize past decisions, as if they were a log to keep track of the design’s evolution, leading to a better understanding of what the current version works the way it actually does.

While doing this, we do not only lose precious time, but also our team members’ time — people need patiently to clear our doubts, collect links and screenshots from past user stories, and so on, and this happens all while trying to keep also our own individual and internal organization in a good shape in order to not lose track of things.

In the teams where I’ve found this is happening, I have also noticed that the evolutions of design and code move somewhat independently from each other, even when there’s collaboration and frequent communication set up between the designers and engineers.

Note: What’s the difference between a developer and an engineer? The short answer is, both mean roughly the same thing as in the software industry “software developer” and “software engineer” are often used interchangeably. In my current team, we use “engineers” — so here and in the rest of the article I’ll be using this term.

And since people don’t share common practices and approaches, everyone is dealing with problems and solutions in their own ways. So what to do when we find ourselves in such a scenario? There are two possible approaches I can think of.

1. We always have the old and classic “it is what is.” You will eventually get used to how things are, you will learn how things work, and move on. You will manage to find some logic (even if it’s your own) inside the chaos — a sort of entropy, if you like; enough to keep shipping designs. Soon all of this will stop bothering you much and will become someone else’s problem.

2. There is the possibility of finding a solution — or at least there will be such a possibility when you have a team that is on the same page as you and it will want to support your efforts. And these efforts might be big, since you will have to think about how to fix things in a way that works for everyone, solves the current problem, and is also future-proof. Challenging, isn’t it?

There’s also the initial time investment that you will need to do on your side — you will need time to articulate the problem, and then present the possible response and its advantages, all of this in a way that managers can understand clearly. Speaking their language and presenting this as a way to potentially save time and money might be the best way to frame your proposal!

With all of these things needed in order to just get started, it’s understandable why we usually go (and look) the other way. But if you are still with me, I will attempt to show you why, and what you need to do to make a change for the better.

Why Do We Do This?

Before we continue, I think it’s important to understand why working in an apparently disorganized way seems to be the norm — and why maybe this even seems to be somewhat really working in so many teams.

One of those reasons could be due to pressure from managers to deliver more, and to deliver quickly. We think that we’ll go faster if we leave layers, groups, and components unnamed. We don’t stop to organize them in a way so that they will be easy to update in the future. Spending time refining our design workflow to something that could be useful beyond this specific point in time seems unnecessary (and it even seems to slow us down) when there are other, more urgent things to do instead.

It could also be the case that our designs are intended for a short-lived product. Then, investing effort in keeping a proper arrangement inside the files, and in how the proposal is communicated seems to be unappealing — and maybe, even unnecessary in that scenario. In the end, why should we focus on doing something properly specified (let alone documented), if in six months from now we won’t care about this product anymore? Or at least, that’s what we think of in that given moment — you never know when you will need to revisit old design decisions.

Finally, it could be due to not seeing the value of working this way. Perhaps it’s not something that we feel would be useful or necessary, or maybe we just find it boring to document cases and scenarios. We don’t want to do that because it’s more fun to spend time tweaking visual variations, making them more appealing. Perhaps, something that we can one day upload to our portfolios — as in the end, nobody will know what’s going on inside the depths of our design files, right?

These are not all the possible reasons, of course. And all of them could even make sense or be understandable depending on your specific needs, timing, budget and whatever works for you (yet be different from someone else).

In some teams, designers really want to change (and improve) their design practices. They just don’t know how to start, and they may also be lacking the skills of someone more experienced leading the way. But even the longest journeys start with a single step, and in this case, it may be quite obvious why to walk down this road — the road less traveled.

The Benefits Of The Change

“Keep shipping things” is sometimes a trap that gives you the illusion that no change is necessary. It happens often, though, that you will realize there are better ways of working once you start making your process more efficient, scalable and sustainable. You may experiment trying to optimize and reduce the more cumbersome steps of your workflow, those that take more time or distract you from the things you really want to do. Just then, you will start wondering why you didn’t do it before. This aha! moment may be self-realization at first, but once you understand it you will be able to pitch its benefits to other people in your team. Until then, you might need to work by yourself in the shadows, silently preparing your case.

Just to clarify, while doing this I’m not necessarily talking about building a fully-fleshed design system all by yourself — but instead about design practices that will improve collaboration between the teams. Practices that, in the best of the cases, will start shifting everybody’s mindset once they start “seeing the light” themselves. People will reckon the need of going forwards when the advantages of the process are self-evident since the whole team benefits from them.

But I am not speaking about design systems here. Let’s start simple: think of the simplest things first. For example, just naming a component the same way in the design and code; or doing a bit of preparatory work specifying the maximum width for a container and how it will respond to varying amounts of content, things that sooner or later will need to be addressed anyway. If done right, starting with the design phase and with involvement from the engineers will smoothen the implementation later. Define interactions, animations and transitions together — you can make a basic prototype that will bring further alignment and boost confidence in every team member, even before a single line of code was written.

And there’s something else. As designers, we should be supportive to our fellow team members, current and future, who will have to work on our design files and understand how we got to those results. Design work should be fairly self-explanatory.

But we will also do this for ourselves, so we can make more thoughtful design decisions. Pausing for a moment during this reorganization process will force us to rethink how we have been doing things so far, and why. We tend to forget that the process of organizing our design is also design — being organized, efficient, optimizing resources in order to get more possible solutions. Isn’t the process we follow something that also shapes us as designers, beyond the end result?

Just keep in mind, it’s also true that the systematic approach is not for everybody. Some teams may need uncertainty and even some amount of disorder in order to thrive. It could happen that it does not make a lot of sense to impose certain order and conditions when it’s exactly the lack of these that allows richer proposals to sprout and grow during the exploration phase.

Maybe this chaotic approach works for you only for certain parts of the design process and it’s you who will have to decide how much of it to allow. There’s a threshold where one can maneuver, keeping a balance while you explore and follow certain good workflows at the same time. If lately, you are losing most of your time understanding how a design works or searching for pieces from the past, it’s likely that you have crossed that line already.

The Steps Of The Process

There are some steps that you can put into practice to set this change into motion. There’s a lot of hype around design systems (and hey, even I created an online course about them!) yet there’s no even need to have one such a system and to adopt a workflow that you can replicate to whatever you, and your team, do from now onwards.

However, there’s a strategic way of starting to work on this so it doesn’t represent too much of a hassle. You could, for example, wait until there’s a need to design a new component and only then do it. Start putting this new approach into practice more regularly and set the grounds for the rest of the design work, future and past.

The good thing about working this way is that you can start building small, and once the benefits of it are more evident, hopefully other people in your team will see this as the benchmark to aim for. So don’t go crazy applying this to everything in your product until you see some signs of people being on board with the idea. Documentation will play a key part in this process (as we will see later) since this will be a piece of communication that will serve as a success story for people who are non-designers as well.

Once the first steps have been done, it’s likely there won’t be any arguments for not replicating this process for other things that you will do from now on, and even with previous designs that were shipped without following this technique.

So, how can you kick-start this with your next new interface component? Let’s start with the concept of modularization.

Modularize parts of the design

Right from the beginning of a new design project (after some exploratory design and research have been done), you can start thinking of systematizing your designs. One way of doing this is thinking in pseudo-design properties that later on might correlate with the ones you will have in the code. For example, for a new component, what are the aspects of it that you think should be customizable per instance later on? This could be parts of the content or the visual properties.

Useful tip: Beware that software such as Figma gives designers a lot of freedom to change things in the components’ instances. These changes, later on, will be difficult to replicate by an engineer using the component’s coded counterpart. That’s why your design definition should already include tables (or anything similar that will do the trick) in the design file itself, indicating which are the properties that will be flexible to be changed later on. This will be useful for the designers, but also for the engineers — as they will have a rough idea of how to structure the data when the actual implementation phase begins.

The way you present and communicate your design proposal should also reflect these decisions in a way that is very clear, from a visual point of view. Do arrange your design in such a way so it’s evident how it’s divided and structured in variants, just by taking a quick glance at it.

Validate with the engineers

A big part of this entire process is making sure that the design proposal and the arrangements of these modules make sense for the engineers, too. This will result in a certain parity and alignment between the designed component and its coded counterpart.

During the validation stage, engineers will likely take a look at what you have, ask questions (hopefully a lot, that’s a good sign!), so that you could better refine the scenarios that may be missing from your variations. These could include loading or intermediate states, or designs with varying amounts of information (too little or too much). These questions will help determine how well-prepared is the design of the component for real-world conditions.

Another important point is that, at this stage, designers should find ways of aligning themselves with the engineers in regards to how these properties we mentioned are being named. Ideally, the way you split a component in your design software should follow a similar logic to what happens in the code and the same with how those properties are named.

It’s important to bring designers closer to a systematic way of thinking; this alignment is what will make this whole work sustainable over time.

Documentation

The good thing about all this work that we (or you, even better) have done so far, is that it will serve a purpose beyond the validation phase and will set the grounds for more permanent documentation. Remember what I was speaking about at the beginning, making things easy for newcomers? They won’t need to understand the back and forth that took place in order to validate a component. The documentation will be the testimony and the outcome of that friction for them instead.

If we are talking solely about components, there are a few things that you could include in the documentation:

• Properties.
  Even if the documentation is design-oriented and there’s separate technical documentation, it will be useful to include a simplified list of the properties that the coded component will allow and will be possible to be customized with. This is mostly for the designers who need to understand that in their design software (where things are easier to change, compared to the things that can be modified in the code) they cannot just change anything they want — but need to follow a predefined set of rules instead.

• Variants.
  All the visual (and behavioral) variations that a component could have. These could include different sizes, examples with icons and without, and all of its different states (hover, focus, pressed, disabled, and so on).

• Use cases.
  It’s always a good idea to document how the component will be used in context and not only in isolation. By showing examples of the component in a realistic scenario that currently (or potentially) exists in the product, it will be easier for people to understand what’s the intended use of the component.

• Good practices.
  This one is pretty straightforward and basically means to include recommendations on how people should (and shouldn’t) use a component. It's always better if you accompany a component with visual examples to show what you mean exactly. Some things that you could include are related to the placement, content, customization of the properties, etc., in order to show both the incorrect uses and the recommended ones.

• Content design.
  Starting with the design phase you can begin thinking about how the text content of the component should be used. Think of the good practices and approaches for labels, placeholders, how to write error messages and text in the buttons. There is no need to go into full details — just think of the most common situations to keep in mind, then list them one by one.

• Behavior and interaction notes.
  There are some things that don’t necessarily affect the design proposal but could be useful in order to understand how the component works under different circumstances. Similar to what we mentioned before during the validation with engineers phase, you could include examples of how a component adapts depending on the amount of content it has; or a representation of the interaction area (the zone that will be clickable); and so on.

There are a few more things that you could include, besides all of these. If you have the chance of also embedding prototypes or real, coded examples, this will help paint the whole picture and the designers taking a look at the documentation will have a more than a solid idea of the component, how it works in the product, how to use it, and what can be done with it.

If this sounds too daunting, you could start by designing a minimum viable version of each component, or a documentation template, and include only the content that you think most of the components should have in order to be clear and easy to understand. All of that is more than anyone would want when starting to work on a product.

Replicating the process with older designs

If and when you have succeeded in making a case for this process, people will most likely want to follow a similar approach from now onwards. Designs that have already been shipped and may need some maintenance or improvements will be just another chance to start applying this new workflow in your day-to-day practice.

In that case, besides following the steps mentioned earlier, you will need to do some extra work to bring further alignment. A good idea would be to start making an auditory of all the different instances of a particular component, in the design files and in the versions implemented in the product. You may start noticing discrepancies between the design and implementation — or maybe a design wasn’t even ever been implemented — or perhaps you will discover that there are a lot of different versions of it.

Making an auditory can be done component by component, independently, by putting everything together in one single canvas with the sole purpose of collecting, observing and comparing. You can start with something as simple as a button, an input field, or a footer, and map all the versions of these elements that you’ve found spread around. Once you have everything in one place you can start the clean-up process: removing and simplifying everything that is slightly different with the purpose of consolidation and unification. Instead of having 34 buttons that look slightly different, keep just a few of them that look more distinctive.

From here on, you can connect this part of the work with what we mentioned before. This means starting with structuring components on a similar set of variants and properties to the ones you have followed for the new components. In the end, all of them will look like part of a family, or… yes, a design system.

From System To Mindset

Speaking of systems, what nobody tells you about design systems is that the part of growing, maintaining and spreading the voice is more difficult than the part of designing and coding the components. And you will need to do these things every day!

The things that we have reviewed so far do not even require you to have a design system per se. You could adopt most of these techniques even if it’s for the design part of the product alone. If you do it, you will start changing your mindset so when you have the chance to work or start a design system, you will be more than ready by then.

Changing the way you work and adopting practices that go in line with modularity, reusability, scalability and some other *-ity words will help make your design work sustainable over time.

Along the way, you will need to educate others, too — but once you adopt a methodology that works for your particular team, context and needs, and if its benefits are clear, others will follow suit and this mindset will start spreading and propagating internally until it becomes an established practice.

With designers, there will be some extra work, since, as opposed to engineers, we are not so used to thinking in terms of properties and modularity, and may feel constrained by the lack of customization that a particular component may have. Probably this won’t change overnight, but you can start adopting some practices that little by little will help designers learn how to work in a way that is more systematic and more efficient.

These are just some of the practices, to name a few:

• Follow internal conventions.
  There isn’t a single way of doing things, and usually every designer will have their own workflows. That’s why it’s important to agree on the basics — from naming the layers, to splitting the variants of the components in your design software — in a way that can be quickly understood by everyone. The ultimate goal would be to open a file from any other designer on the team, the file should make sense at first sight, and by understanding its logic you should be able to easily work with it and modify it. This goes beyond the design files themselves. You could also follow standardized workflows on how to design components, communicate a product release, or handle bugs in the design. It’s important to make sure that everybody’s on board with this and to have public documentation to reinforce these guidelines. (It won’t work if only a few people in the team follow them, and the rest don’t care.)

• Think of the modularity from the very beginning.
  As mentioned earlier, you don’t have to wait until you have an implemented component in order to determine its variants and properties. You can start planning these things during the design exploration phase. Just by keeping in mind what could potentially be a customizable property in the final component, you will adapt yourself to work in a more pragmatic way that will save you time and some back and forth with the engineers in your team.

  During this stage, you can involve other people to validate your ideas and get feedback so they know about your design proposal even before it is in its final shape, and at the same time, your design won’t be a complete surprise when the moment comes to get a more official validation.

• Don’t get caught by your design tool.
  Every design tool has constraints that make us involuntarily increase the gap between the design and the code. In some cases, our design tools will even force us to do things in a certain way that won’t have parity in the code. That’s why it’s important to ask ourselves from time to time: “Is the software we are using a limitation or is it useful? Is it helping us to get better results or is it getting in our way instead?”

  Whenever it’s possible, our product design work needs to keep one layer of abstraction from the software itself so it still makes sense, no matter if we use Figma, Sketch, Illustrator, Affinity Designer, or Microsoft Paint to design it.

• Do the boring documentation part.
  The design work is not finished with the interface design being completed. Documentation is another step in the process and it should not be overlooked. It will be a summary and a testimony of how something works, but also a living document that will change and evolve over time, just as any element of the design. But documenting for the documentation's sake is not very useful, it has to serve a purpose with clear benefits for the design and development teams. I think that’s why, besides being useful, you should make the documentation clear, visually well-explained, and as friendly as possible.

• Find ways of designing less.
  If you have good documentation in place, then it means you have already explained some of the use cases and different scenarios. So instead of having to constantly create/design them every time, you could just refer to the documentation. This is definitely a way of saving time and avoiding to re-define behaviors every time from scratch. For example, if you have a pattern for a search process in your design documentation, it means that in the UI screen where you have a search input field, you can just put the search field and forget about specifying it again. Effective laziness one could say.

  Another way of designing less is taking advantage of the components’ properties. This will allow you to skip repetitive designs where the only thing that changes are the properties values but not the visual design itself. Think of a modal dialog box that allows customizing the title, text, and buttons, while everything else remains the same. Whenever you need to use them, instead of designing a full screen to just show the properties values, you could document them separately as simple text. In the long run, such a system will be easier to maintain and will be closer to what an engineer needs in order to implement it.

• Have a maintenance and contribution process in place.
  Everything we have mentioned so far will be as useful as its capacity to evolve over time. You may need to define certain roles to make it clear who is in charge of maintaining what. Ownership will keep processes, documentation and components lean, efficient, and organized. There could be different ways of handling this but I prefer an approach where there’s someone accountable for every part — it could be anyone inside the team. This way, they will feel this is their responsibility and will act as guardians and educators to keep the work serving its original purpose and remain in good shape.

  As the product grows over time, these roles (people in the team) will be also responsible for incorporating the new contributions and suggestions from other, less-involved designers. In this regard, it’s important to be transparent on what’s your criteria to accept and add any new piece, from minor edits made to the documentation to whole new components. Contributors (could be anyone in the team) will need to understand that this is a process that aims to keep the quality bar up, but at the same time won’t feel discouraging or “bureaucratic” to the contributors. Keep it simple and lean, like everything else. Test it and refine it over time, just don’t settle with what you think is “just working.”

Conclusion

Independently of having a design system in place, it is worth investing time in properly structuring the design workflows and nurturing good practices that can be sustained over time. These will make your design process faster, newcomers will need to spend less time understanding how everything works, and they will increase the alignment and collaboration between designers and engineers.

And more importantly, fostering good design practices may also help designers change their mindset — in a way, this sounds more strict and rigid, but it will in fact challenge their creativity and will help generate efficient outcomes based on reusable properties, closer to the constraints of the coded components.

Changing the internal culture and getting internal buy-in won’t happen overnight. It may involve a lot of work, convincing people, and even working in the shadows before you have a proposal that can be shared, agreed upon, and put in place to see if it sticks.

And as with everything, it may need iterations over time and little tweaks to see if it works for your particular needs (and your particular team). Although it sounds daunting, give it a try! I’m sure you will be a better designer at the other side of tunnel — and hopefully, the rest of your team as well.