Tinned Fruit Missives May 2017


Systems, systems, systems. Design systems everywhere. As more and more organisations publish their own design systems, it appears that web design has entered a more stable, consolidatory phase. Since responsive design and the mobile revolution, there haven’t been any great innovations that fundamentally change the way we design. Companies are evolving their design practices instead. Even smaller companies with a single product and a single team look to design systems as a way to speed up and focus design and product development.

I find the trend interesting, not just because it’s a sign of industry maturity, but because it is weirdly satisfying to work on something at this more abstract level. Instead of thinking about the specific customer problem we’re trying to help with, we’re pulling out common information and interaction patterns and making them into concrete re-usable assets. It scratches the same part of my brain as refactoring.

If you’re interested to discover more about design systems, I can recommend Stu Robson’s Design Systems newsletter and the Design Systems Slack channel.

All the best,

– Jim


Lessons Learned Scaling Design Teams - Aaron Walter

https://www.invisionapp.com/blog/scaling-design-teams/

Everything that Aaron describes here about product and design in growing product companies applies equally to product engineering. Products and companies go through a series of stages where a different approach is needed. A company just starting out will need adaptable generalists who can pitch in on different types of customer need. But as the company grows, there is a shift towards product consolidation, and more specialists are needed. I believe the hardest part of this is staying aware of what’s going to be needed in 6 months or a year from now.

Designing a Systems Team - Nathan Curtis

https://medium.com/eightshapes-llc/designing-a-systems-team-d22f27a2d81d

On the same theme of organisational growth, Nathan Curtis describes possible structures for design systems teams in different circumstances. The description of how cross-team design platform activity emerges in a growing company is spot on. This could be a dry subject, but there are pretty diagrams to help :-). This post is a great place to start if your company has tried and failed to build a UI library or style guide, only to see poor adoption.

CSS is Not Broken - Keith J. Grant

http://keithjgrant.com/posts/2017/03/css-is-not-broken/

There’s been a bucket of hype around styled components recently. As usual, it’s easy to get swept up by the possibility that we have found a new, better solution to the challenges of CSS-at-scale. Here, Keith makes the point that CSS, like other languages, demands skill and expertise to wield effectively. Blaming the language for a poorly structured code base wouldn’t fly for other languages, so why is it OK for CSS?

TypeScript at Slack - Felix Rieseberg

https://slack.engineering/typescript-at-slack-a81307fa288d

TypeScript is a statically-typed superset of JavaScript. I found this post interesting because of the practical lessons learned when adding types to a large existing JavaScript codebase. They found lots of small type bugs not exposed by unit tests, and despite the process taking six months and the moderate learning curve for developers, the author clearly feels it was worth it. An interesting example of code investment (as opposed to code debt).



Tinned Fruit Missives is a monthly newsletter published by Jim Newbery, a front-end engineering consultant from Edinburgh in Scotland.

I help growing web product companies with their front-end development strategy. Let’s talk!

Join my daily mailing list

Sign up now and get my Front-End Engineering Responsibilities Laundry List PDF for free.

You'll get regular emails about front-end development. Unsubscribe at any time.