I’ll be moderating this online panel next week with Emma Boulton, Holly Habstritt Gaal, Jean Laleuf, and Lola Oyelayo-Pearson.
I’m looking forward to it! Come along if you’re interested in the future of design teams.
What will the near-future look like for design teams? Join us as we explore how processes, team structures and culture might change as our industry matures and grows.
I wrote something recently about telling the story of performance. Sue Loh emphasis the importance of understanding what makes people tick:
Performance engineers need to be an interesting mix of data-lovers and people-whisperers.
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?
I really, really like the way that this straightforward accessibility guide is subdivided by discipline. As Maya wrote in the blog post announcing its launch:
Each person on a team, whether you’re a manager, designer, or developer, has a role to play. Your responsibilities are different depending on your role. So that’s how we structured the guide, with a separate section for each of five roles:
- Product management
- Content design
- UX design
- Visual design
- Front-end development
The transcript of a talk that is fantastic in every sense.
Fans are organised, motivated, creative, technical, and frankly flat-out awe-inspiring.
Susan writes about the challenges when trying to get widespread adoption of a design system. Spoiler: the challenges aren’t technical.
Change is hard. Communication and collaboration are absolutely necessary to make a system work. And the more people you can get involved from various disciplines the better chance you have of maintaining your system.
For any single scenario you can name it’ll be easier to create a process for it than build a culture that handles it automatically. But each process is a tiny cut away from the freedom that you want your team to enjoy.
A great in-depth report from Alice on creating, running, and most importantly, selling an in-house design system. This makes a great companion piece to her Patterns Day talk.
Where internal teams seem to go wrong is not appreciating that the thing they’re building is still a product and so it needs to compete with other products on the market.
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.
The most ambitious project from Archive Team yet: backing up the Internet Archive.
We can do this, people! Moore’s Law and all that.
What a fantastic collection of creators!
Such a classic game, well worth playing again.
See that helmet? That’s my helmet. Jim borrowed it for this video.
And now I think that the Future Friendly posse has a theme song.
Jason’s rip-roaring presentation from Defcon last year.
James Bridle is my favourite Blogpunk author.
A viciously accurate assessment of Yahoo’s scorched earth policy towards our online collective culture:
All I can say, looking back, is that when history takes a look at the lives of Jerry Yang and David Filo, this is what it will probably say: Two graduate students, intrigued by a growing wealth of material on the Internet, built a huge fucking lobster trap, absorbed as much of human history and creativity as they could, and destroyed all of it.
Instruction manual to operate and maintain Charles Babbage's 2nd Difference Engine built by Barrie Holloway and Reg Crick, June 1991 for the Science Museum, London SW7 2DD.