Design Engineering - Snook.ca
Here’s a seven-year old post by Snook—this design engineer thing is not new.
Link tags: teams
11
Exploring the future of… Design teams | Clearleft
I’ll be moderating this online panel next week with Emma Boulton, Holly Habstritt Gaal, Jean Laleuf, and Lola Oyelayo-Pearson.
There are still some spots available—it’s free to register. The discussion won’t be made public; the Chatham House Rule applies.
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.
Performance, security, and ethics: influencing effectively
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.
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?
Accessibility for Teams
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
Superfan! — Sacha Judd
The transcript of a talk that is fantastic in every sense.
Fans are organised, motivated, creative, technical, and frankly flat-out awe-inspiring.
Building and maintaining a design system | susan jean robertson
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.
Tips for in-house teams in a free market software culture
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.
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.
Science Hack Day San Francisco 2014 Teams - an album on Flickr
What a fantastic collection of creators!
Play Steamshovel Harry, a free online game on Kongregate
Such a classic game, well worth playing again.