Link tags: organisation

Why “AI” projects fail

“AI” is heralded (by those who claim it to replace workers as well as those that argue for it as a mere tool) as a thing to drop into your workflows to create whatever gains promised. It’s magic in the literal sense. You learn a few spells/prompts and your problems go poof. But that was already bullshit when we talked about introducing other digital tools into our workflows.

And we’ve been doing this for decades now, with every new technology we spend a lot of money to get a lot of bloody noses for way too little outcome. Because we keep not looking at actual, real problems in front of us – that the people affected by them probably can tell you at least a significant part of the solution to. No we want a magic tool to make the problem disappear. Which is a significantly different thing than solving it.

Efficiency trades off against resiliency - Made of Bugs

Past some point, making a system more efficient will mean making it less resilient, and, conversely, building in robustness tends to make a system less efficient (at least in the short run).

This is true of software, networks, and organisations.

When we set metrics or goals for a system or a team or an organization that ask for efficiency, let us be aware that, absent countervailing pressures, we are probably also asking for the system to become more brittle and fragile, too.

Your design system contribution practice is doomed to fail by Amy Hupe, content designer.

This is a great analysis by Amy of the conflicting priorities tugging at design systems.

No matter how hard we work to foster these socialist ideals, like community, collaboration, and contribution, it feels as though we’re always being dragged to a default culture of individualism.

Full Stack Service Design – Sarah Drummond

Katie shared this (very good) piece about service design on Slack at work today, and when I got to the bit about different levels, my brain immediately went “pace layers!”

1. The Service
2. The Infrastructure
3. The Organisation
4. The Intent
5. The Culture

How to build a bad design system | CSS-Tricks

Working in a big organization is shocking to newcomers because of this, as suddenly everyone has to be consulted to make the smallest decision. And the more people you have to consult to get something done, the more bureaucracy exists within that company. In short: design systems cannot be effective in bureaucratic organizations. Trust me, I’ve tried.

Who hurt you, Robin?

Guide to Internal Communication, the Basecamp Way

Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts. If it’s important, critical, or fundamental, write it up, don’t chat it down.

This one feels like it should be Somebody’s Law:

If your words can be perceived in different ways, they’ll be understood in the way which does the most harm.

The Ugly Truth about Design Systems

The video of a talk in which Mark discusses pace layers, dogs, and design systems. He concludes:

1. Current design systems thinking limits free, playful expression.
2. Design systems uncover organisational disfunction.
3. Continual design improvement and delivery is a lie.
4. Component-focussed design is siloed thinking.

It’s true many design systems are the blueprints for manufacturing and large scale application. But in almost every instance I can think of, once you move from design to manufacturing the horse has bolted. It’s very difficult to move back into design because the results of the system are in the wild. The more strict the system, the less able you are to change it. That’s why broad principles, just enough governance, and directional examples are far superior to locked-down cookie cutters.

Workplace topology | Clearleft

The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.

This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:

Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.

Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.

That last part dovetails nicely with Jerlyn’s equally great piece.

Creating the “Perfect” CSS System – Gusto Design – Medium

This is great advice from Lindsay Grizzard—getting agreement is so much more important than personal preference when it comes to collaborating on a design system.

When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, don’t use BEM.

It’s all about the people, people!

Full-Stack Developers | Brad Frost

In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.

Web Matters

An organisation has formed here in the UK as a response to the increasing threats to the web:

We are called to come together in response to growing political and social uncertainty, direct threats to the profession, and a lack of vocal and proactive representation to organise as a representative, independent, and politically responsible industry body.

The inaugural AGM is happening in Edinburgh tomorrow. Get along to that if you can. Otherwise, there’s always Slack.

I like their manifesto; let’s put it to the test-o.

Maintaining and organising a pattern library - FutureLearn

Alla looks at a few different ways of organising the contents of a pattern library, based on her experience with the FutureLearn team.

Science Hack Day is coming to your city! by Ariel Waldman

Want a Science Hack Day where you live? Make it so!

We’ll tell you what you really want: Mobile context, top tasks, and organization-centric thinking | Sara Wachter-Boettcher, Content Strategist

An excellent follow-up to the recent posts on the myth of mobile context.

You often hear about cutting content to cut clutter. I support this—if you’re cutting the clutter from everywhere, not just a mobile experience.

Maybe the answer isn’t cutting. Maybe it’s learning better skills for designing and structuring complex information to be usable and enjoyable in small spaces.

Open Conference Expectations — Gist

This is a really good initiative—a list of minimum expectations from conference organisers (although there’s clearly some differences between cheaper grassroots events and larger industry affairs).

Structuring a Responsive Stylesheet | Sparkbox

Some thoughts on structuring your CSS for responsive designs.