Aim for the dollar, hit the penny

In designers' portfolios, I often see a whole range of technologies and methods used: custom development, JTBD, CJM, Double Diamond, and so on. But did this ultimately help the project, and if so, how?

How many times have I seen a JTBD applied to a project simply for show, but ultimately achieving nothing? And that's a bad sign, because it turns the work into administration. Moving cards, writing lists, compiling reports, drawing diagrams.

I don't deny the benefits. A sound methodology abstracts and formalizes work, transforming a complex and confusing process into a short and understandable formula. A formula is easier to use, convey to others, and collaborate with. Educational and any training process in general is structured in the same way—we do simple, isolated exercises to learn. And in large teams, it's also necessary to standardize processes to prevent everything from falling apart. Naturally, there's a temptation to refine these training sessions and methods and improve upon them.

After all, design in itself has no meaning; it operates within the framework of a larger task, solving a problem for the user, the business, or the culture. The purpose of methodologies is to facilitate, explain, and teach—they're not about achieving results. Therefore, the overall goal is often lost in the rush to refine and adhere to methodologies.

Passing exams with flying colors doesn't indicate knowledge of the subject. Mastering karate kata doesn't necessarily translate into success in a fight. A fancy camera won't take a great photo. Flawless application of Scrum and a design system doesn't guarantee solving user and business problems.

Any project methodology will clash with reality. Sometimes you have to do things a little differently, not quite "correctly," than you were taught. After all, it's important to achieve results, not to use a method or tool "correctly." Where you need to change something for yourself, change it. I'll tell you something scary: even components can be broken down into smaller pieces.

Therefore, it's more important to keep the big picture in mind and question yourself: "How will implementing this methodology help me? Can I do without it?" And if possible, it's better to do without it. Don't put in the effort if it's not going to work. It's no good wasting resources and time building a complex, flexible, detailed, and "correct" work model, only to end up with complete nonsense. It's better to disrupt, play fast and loose, and break the rules to achieve the desired result. Think strategically, not instrumentally.

p.s. All of this exists in the context of short- and long-term goals, between which the search for the optimal solution takes place.