Automate (tiresomely) Repeated Decisions

Work can be (loosely) reduced to 2 main tasks that all of us do

• Deciding
• Doing

While reading the Design systems 101: What is a design system? article, I stumbled again with the concept of decision-making on granular choices of an occupation, once and not burdening ourselves with that decision again, at least for some time.

Discussing automation and (simple or large) optimizations is common practice among fellow Engineers. But that wasn't exactly the norm for other professions and I personally suspect that this is the reason behind the fear, and excitement of the actual Artificial Intelligence hype. That stated, the audience of this article is

• Engineers interested in what kind of work is worth automating and why you should do it
• Product Designers struggling to understand that Automating Decisions isn't a creativity limiter (in fact, it's the opposite!)

Why Do We Automate?

Declutter decision-making is common for an Engineer. Scripts that automate repetitive tasks or use small macros inside our Editors are almost like breathing. It can save massive amounts of time. But after some reflection, it is not just about the time we save.

It is about the attention span that is avoided at those simpler tasks.

The fatigue and slog faced after a day of hard work in those tiny, small, and mind-consuming tasks can be huge. Even though sometimes those Snacking tasks can be fulfilling and learning opportunities, those are the tasks we spend time "Doing" repetitive work that can be automated, consuming most of our time.

Why Start Automating?

Once Engineers start to get comfortable with their environment and editors, they begin automating tasks such as mass edits in multiple files at once instead of manually changing each file and validating the change.

That's also one of the main reasons to write Automated Tests: Creating small chunks of code, Services that encapsulate business logic and isolate complex data mutations, all tested, gives the confidence to move forward to other tasks.

Decide once, write the code, test it, validate it, and close that box.

The Pragmatic Programmer book mentions 2 Tips that highly correlate to those concepts:

• Tip 11 - DRY (Don't Repeat Yourself)
• Tip 48 - Design to Test

But that logical leap is not that simple to sell to Product Designers. Where creativity plays a crucial factor in your craft, and the distance between the logical world of Programming Languages is farthest, limiting "smaller decisions" such as

• size of the round border of a button
• padding of an Icon or
• the subtle impact between using merlot, wine, and sangria (For fellow Engineers: those are all different shades of red)

Can easily sound like a huge punch for creative minds.

Compound Benefits of Decisions Made

Once engineers join a project, there's always code to be reused and standards to be followed. Writing consistent code over the codebase is beneficial for more reasons than there are stars in the universe.

Constants, util functions, and libraries to be built on top of it are actually the norm. If you don't have a really good reason (and a detailed approved plan of migration), changing those constraints isn't going to happen that easily. And even for upgrading dependencies it is possible to write automated migrations, that can also be tested. It is a fractal of automations.

But for some Product Designers, if the one specific shade of green they are using at their page isn't available as a Design Token, the new green sometimes will be used anyways without much reasoning behind it. For those professionals, having constraints feels like tying their hands behind their back and forcing them to paint a Monalisa replica with their feet.

Choose When to Decide

Automating repetitive chores is not about curbing one's creativity. It's all about relieving the mind for the work that matters. Work that only you can do: Make important decisions. Design a Product to real-world problem. Architect solutions from your unique perspective. Let your mark to a product.

That's one big reason to think about start using a Design System and enabling the nurture of your backlog with High-impact Decision-Making chores instead of Low-impact repetitive tasks.