Wowowowoww, where do I start?! So many cool things have happened over the past month and yes, it’s only been one month and four days since the last Desgingineering Chronicles post. I am aware that you, reader, are not quite as invested in this content as I am…but still, wow!
Recap
Before I get too ahead of myself, let’s get to the obligatory recap of the last Chronicle. It was broken into two parts, less technical Part 1 and more technical Part 2.
In less technical Part 1, I wrote about some challenges we faced as a team over the course of project Cantaloupe, and a personal note that, even though things might sound awesome and perfect according to others’ blog posts and tweets, there are always ups and downs.
Our challenges were namely the difficulty in splitting up front- and back-end tasks when the PMC workflow has traditionally been oriented around features that involve both ends. There were some dark times where the specialized knowledge required to use the design system’s CSS architecture and templating seemed to be keeping the project from moving forward, but after three sprints or so after we found our groove, and things really picked up (which I’ll talk about in this Chronicle).
CSS utilities classes have been a giant success, and along with a modified ITCSS plus CSS algorithms paradigm, we now have a nice system for naming and categorizing declarations that can accommodates pretty much anything. At the time, almost all of the CSS algorithms had been written by me, so I was concerned that might mean it only made sense to me which would be dangerous, but since then, Yahil, the other front-end developer on the project, has started using the term and we’ve pair programmed some algorithms together. I wrote about one of those sessions in this post.
The technical Part 2 reviews our pattern architecture, the use of SCSS utility class generators, and provides some examples of the CSS algorithms we are using as well as a break down of the patterns we’ve collected.
I am writing this post a bit sooner than anticipated (gasp!), so the items in the “what’s coming up” section of Part 2 (road map, sharing pattern configuration) are in the beginning phases, but before I get into those details…
Cantaloupe is Deadline.com!!!
And it’s alive! A living, breathing, and pretty fast website!! I am so, so proud of what we’ve built, and the launch even went relatively smoothly as far as launches go.
If you’ve been following this series and/or are interested in seeing our naming conventions, CSS architecture, and algorithms in action, open up the inspector on Deadline.com and inspect to your heart’s content!
Also…coolest thing ever that probably would only happen in LA: I am writing this at a coffee shop, obviously, and went to purchase an avocado toast. When I walked back to my work station, I saw someone at a different table looking at the new Deadline!!!! Of course, I interrupted him to point out that is my team’s handiwork. He said he likes the redesign a lot and that I can quote him in this blog post. Fun!
Showing That It’s Useful
Three months ago, back in the Chronicle from month 5.5-6.5 (regretting these decimal numbers…would chapter names be better?) when I started writing about project Cantaloupe a.k.a. Deadline, I referred back to Brad Frost’s principles for starting a design system at a big company. These principles have been guiding my work pretty much since day 1, and in that post three months ago, I kind of assumed I’d checked them all off:
Wow! Lots has come together over the past month. In a big way. Design systems are now a thing at PMC! And all because I followed Brad Frost’s three simple steps for starting a design system at a big company:
1. Make a thing (for PMC, the IndieWire pattern library)
From Chronicle: Months 5.5-6.5, published 3 months before this one
2. Show that it’s useful (I guess people liked it!)
3. Make it official (read on!)
There has been much less friction than I anticipated in getting to step 3. I’ve been meeting with the design team for a while now, and they have been on board, but working in a systems-oriented way is a big shift in mentality for how to handle engineering and the project management workflow. I expected to have to do more convincing and pitching, but nope! PMC gets it.
I see this differently now. While the “thing” was certainly the IndieWire pattern library (read about that all the way back in this Chronicle from The Second Month), I think I was a little ahead of myself calling Deadline number 3. And maybe the “thing” was more like the pattern library / modular front-end, in general.
With hindsight on my side, I now see Deadline as number 2, not number 3. “I guess people liked it!” does not qualify as showing that something is useful. PMC operates with a lot more intention and careful vetting of investment than that! Deadline was the opportunity to “show that it’s useful”. The company took a sizeable risk in letting me loose on this high-profile project. But, by golly, it was a risk that paid off, big time!
Now, we have legitimate evidence in the form of a successful project outcome that the systems-oriented approach works for PMC and, perhaps most important, there are more voices than mine and the designers’ supporting the growth of a system. Everyone is excited about it! I reflected on this in a small post earlier this month called Embryonic Design System.
Building a design system is playing the long game – it takes time. Especially now that I am 11110 years old, I am starting to understand this and am in less of a hurry to check off the items in Brad Frost’s list. I would also say that, until there are actual, published interface elements shared across brands, I cannot check off number 3 for “make it official”. And despite my “what’s coming up” prediction last month about sharing the video element, I don’t see that happening for several months at least.
Also, the design system will need a name…
How do we know the “thing” is useful?
I feel like, perhaps the best indication that something worked or was useful, is how people feel about it after it launches. I’m sure I’m not alone when I say there are projects I’ve launched that I never want to look at again, or that I cringe to think about. Deadline is not that, at all!
Happy Team
In the last post, I shared this image that described my fears for Deadline, and what has surely happened on past projects:
With Deadline and the design system though, rather than turning into the haggard Daniel Radcliffe on the right, the team operated more like this at the end of project:
Sure, there was a lot to do and there were few bugs and things went wrong, but all of us were ready to tackle whatever came along! And throughout the launch and last minute changes, we accumulated very little technical debt to sort through later. I’m still really proud of the project.
Happy Stakeholders
Like many large companies, a lot of the work at PMC comes down to making sure those who pay our salaries are happy. The stakeholders. And who is the ultimate stakeholder at Penske Media Corporation? Jay Penske, the CEO, of course!
Like many large companies, a lot of the work at PMC comes down to making sure those who pay our salaries are happy. The stakeholders. And who is the ultimate stakeholder at Penske Media Corporation? Jay Penske, the CEO, of course!
In the words of this ultimate stakeholder, Deadline is “one of the best projects I’ve seen where we’ve translated design to the web” and, according to our head of department, he is, I quote, “THRILLED with the outcome of the project” and “extremely exited about the design system pattern library”. Wowza! Design system pattern library! A happy CEO is a sure-fire sign that something worked.
High Quality Product and Faster Development
Deadline has shown that a design system is useful by demonstrating a smooth launch, easy to fix design bugs, less regressions, and a performant and accessible front-end. Our CSS is significantly lighter than the last site build that was done by an external agency, and I would say about 70% of the code we’ve written is just about ready to be shared with another theme (after we figure out how to do the sharing).
Development has been going really fast the past few sprints, too. After we worked out the kinks in our process, estimations for both small “tweaks” and larger feature development are lower. An entire template build out (assuming it uses existing patterns) might be estimated at a 2 or 3 where previously it would be a 5 or 8 (we use the Fibonacci sequence for story points). At this point, we are assembling elements rather than building them. I don’t have specific data about this, but it’s on my to-do list to compare Deadline’s JIRA history with other projects and hopefully the data will reflect this conclusion.
Further, the quality in the design implementation is as good as the best part of the site…because it all uses the same patterns! The design team had minimal feedback, and they were generally flexible when it came to changes that didn’t fit into the system.
Road Mapping and Blueberry
A week ago or so, I met with one of our very experienced project managers to ask her advice about creating a road map for the design system. She had an excellent explanation, and I must say, I find it way more meaningful to get this kind of information from a human vs. articles found in a “how to make a roadmap” search…
Here are my notes in bullet form:
- Articulate the ultimate goal in a sentence or two
- Work backwards from the goal to the present, and figure out some deliverables and key groupings of work
- Do a brain dump of the biggest chunks – get it down on paper and organize it later.
- What will be the biggest phases of product delivery?
- What is dependent on what? How can you minimize those dependencies?
- After you have some items down, think about the actual resourcing – what can be done with “big bang” projects (e.g. Deadline), what can be done on my own, etc?
- The sustainable product plan comes after the “big bang” projects – it’s good to think about that, but we also allow that to develop organically.
I have a meeting with the engineering directors next week to share my plans and get their input on the road map and some technical challenges. I’ll be fine-tuning this over the next few days and breaking out some tasks in spreadsheet form, but here’s what I have so far:
The “where we want to be” of the design system: A full-time team of 3-4 people that work on the design system as their primary assignment – me as the lead, 1-2 additional engineers (PMC or contractors), and a designer.
In a bit more detail:
- All new front-end across the company is built using the shared system patterns, conventions, and tooling.
- We have strong linting and testing for patterns, and there is a fast, flat environment where developers can assemble UI outside of the WordPress environment.
- Old code-bases are gradually being refactored to the published system patterns.
- Settings, Primitive Patterns, Algorithms, and Utilities are documented at their own URL, and can be consumed and configurable by themes.
- Modules (which are assemblages of Primitive Patterns, Algos, and Utilities) can be shared across brands via portable configuration objects.
There’s probably another phase to this I don’t even know about yet…Web Components, perhaps? How about Gutenberg and JSX versions of patterns?
The next step for me this week will be to break these down into steps and figure out what is dependent on what. Then, in my meeting with the engineering directors, we can both review that and discuss what would be the most valuable to tackle in my post-project consulting time with Sparkbox, and what should be accomplished pre-Blueberry.
Introducing…Blueberry!
The second “big bang” project will be…Blueberry! Yes, another code name. Blueberry will be different than Cantaloupe, first and foremost in that I am getting in to the project much, much earlier this time. The designs are still in the wire-framing phase! This is a big step forward: now engineering and design can be completely in sync before the stakeholders are part of the conversation.
The designer is doing a fantastic job considering every aspect of the UI in relation to what exists on Deadline. At the moment, I’m thinking the goal with Blueberry will be to figure out sharing and publishing. Blueberry’s development will involve contribution to the Deadline code-base, at least in part, updating our architecture so that patterns are shared on both sites. This will be a huge, huge win because if they are shared on two sites, they can be shared on all sites.
So, how will we use the same o-nav pattern on both Blueberry and Deadline? Where will that code live, how will it be maintained, and where will it be documented? Big questions, and ones I do not want to rush.
Another Cool Success
This is a non-Deadline win: An experiment I wrote about in the very first Chronicle from July of 2018 is working! The experiment was building out a chunk of HTML/CSS in a CodePen that can be included for developer reference in JIRA tickets. This is the one I built for a small newsletter signup (I know it has BEM selector concatenation…gasp!):
See the Pen Newsletter Signup by PMC Devs (@pmcdev) on CodePen.
That was about six months ago, and the product manager I had initially worked with told me the other day that it has been extremely useful. Both she and other product manager have included it in tickets at least 3 times since we created it! There have been many fewer questions/back and forth with the engineers and the quality is much higher. So cool.
What’s Coming Up
There are a few things I still want to write about, and they may or may not make it into a Part 2, or separate blog posts:
- How we are splitting assets and handling critical CSS in WordPress
- Pair programming and more algorithms!!
- Using the one-offs for algorithms, and ideas for project-specific patterns
- The pains of pixel perfect (and that there might be more to the story)
- JavaScript isn’t necessarily a solved problem, like I said last month
Also, I would really, really like to put our assets/src directory up on Github for browsing purposes, so stay tuned for that.
Otherwise, what’s coming up between now and the next Chronicle will be my meeting with the engineering directors and preparing for more work with Sparkbox. I’ll hopefully have some time to do experiments around sharing configuration among the pattern library and the production theme, and I would love to try out some strategies for testing patterns.
And…visual regression testing on Deadline. I need to learn more about continuous integration, how our pipeline works, and further develop my mental model for Docker and containerization.
Okay, back to the weekend!