Developing for the design vs developing for agility

This is a note. Notes are work-in-progress thoughts and ponderings that I choose to share “out loud”, subject to change and revision.

(I would be remiss if I didn’t take this opportunity to first and foremost emphasize that when a [custom] design is created and approved without real content, it sets everyone involved up for failure – the designer, the developer, the content creator, the end-user – everyone. Something I will definitely expand more on one day, because it just cannot be said enough.)

There are two fairly common scenarios when you’re building out a website design:

• Developing for the design: You’re building for a client/team that wants to stick very tightly to the design, never deviate, and has a full blown process when they want to make any changes that starts from content, goes through a designer, and then eventually ends up with a developer who creates/adjusts the code and maybe even the newly approved copy
• Developing for agility: You’re building for a client/team that is very agile and prefers to be able to make changes across function, design, and copy themselves to some extent and expects the CMS to cater to that level of flexibility.

We’re also starting to see an emerging middle scenario, where we are still developing for the design with some agility expectations around content and a few approved design choices.

Where the new (new being a relative term, since it’s now more than 5 years since its merge into Core) WordPress Block Editor shines most is in the sphere of agility. Out of the box it provides a level of flexibility never before seen in WordPress Core, something people leaned on page builders or non-WordPress solutions for.

As soon as you don’t want to provide total 100% flexibility, the Block Editor – as it stands right now – starts to feel lacking. There are locking features but either they go too far or not far enough, with not enough fine control over what’s lockable or not and for whom. And this is where you start to see policies, protocols, systems having to come into play that are outside of the editor. OR you see developers making rigid templates within the WordPress Block Editor, negating nearly all of the empowerment the block editor can provide.

This is possibly the biggest point of friction that still exists when you’re building for clients with the Block Editor – which I’m willing to bet is still the most common way WordPress finds its way onto the internet: in the hands of agencies building bespoke stuff on top of WordPress for clients in literally any industry you can think of, and why even now agency adoption of the Block Editor is slow, stuttering, or downright non-existent in some spheres.

The problem is we’re in a weird spot where clients see the level of agility other systems can give them – and they want that in WordPress too – but they also want their website to look good. They want the ability to be flexible and create new things quickly and easily without developer/designers getting involved but have it follow the design system they probably paid a lot of money for.

We all used to build complex custom page-builder type things with ACF Flexible Content which was actually really good at treading this weird middle. You could create sections/components/blocks (whatever you want to call them) that had some level of flexibility but were still very strictly controlled. The problem now is that we all want to tread that middle ground but do it in the Block Editor because it’s fantastically visual and reduces the cognitive dissonance for the folks using the editor on a regular basis.

But despite the advent of patterns, content locking, templates – we are still in a place where it’s not clear how you can accomplish this well. And for the situations where it is clear, the barrier to entry becomes time. For many people, creating native blocks with the level of complexity they need is still too hard, too long, too unprofitable. Some of us are able to do it, some of our clients can afford it, many in-house teams are able to find the resources to do it, but that’s definitely not the majority.

We’re getting there, it’s a process. But I know first hand, how frustrating this middle place can be where we all are living in one way or another. It’s amazing and exciting and frustrating and difficult. It’s all true all at once.