You may notice a [WiH] following the title of this post – that means, “Written in Haste”. In the interest of not letting my ideas go stale, or waiting until there is too much to write about, I’m going to write and publish this post in haste. You’ve been warned!
Okay, so, to start: what are Designgineering Chronicles? Well, this is the first of maybe, hopefully several blog posts where I write about what I’m doing at work. What does a “Design Engineer” at a big company actually do? Well, it’s super interesting and super fun and there’s a ton of work to do that I’d like to share!
Some background about PMC
Let me start with a few key points about PMC and how it operates:
- PMC is a large media company that owns and operates around 20 brands such as Rolling Stone, Variety, Robb Report, IndieWire, and however many others.
- As far as I can tell, the brands pretty much operate as independent entities, except when it comes to digital. PMC has a product team (that I’m on) that manages and develops brands’ digital products.
- If a brand wants to add a new feature to their site or tweak a design, they do that through PMC. Some of the brands have their own designers, but development and anything product-related is handled via smaller teams of engineers and product managers at PMC called “pods”.
- Project management at PMC is fantastic. I am so impressed by how highly valued project management is across the company.
- PMC follows a pretty strict agile/two-week sprint workflow and uses JIRA for project management software.
Some engineering notes:
- All of the brands are on WordPress VIP. Most the sites were developed by outside agencies and are now maintained in-house.
- Most of the engineering team is remote. There are several developers in India, some are full time and some are through a WordPress VIP consulting firm.
- There is a great culture of code reviewing and unit testing PHP. I wrote my first test last week – it was tough at first, but testing is awesome!
- There is an ongoing initiative for the development of PMC Core Tech that, at the moment, consists of a suite of WordPress plugins that apply functionality to multiple brands. Apart from those plugins, the code-bases – particularly concerning front-end – are unique snowflakes.
Some front-end and design notes:
- Newer site builds have relatively healthy front-ends and CSS architecture, and the newest even contain style guides!
- Before me, there were no full-time front-end developers – front-end code written in-house is handled by largely back-end focused developers.
- Older sites are, well, older sites. I’ve been in one or two nasty specificity battles thus far, and have luckily made it out alive.
- The design to development workflow is oriented around delivering page mockups from design and implementing the mockups using Invision Inspect for communicating specifications.
- There is no dedicated QA role – everyone involved in a task collectively QAs the work.
What I’ve been working on
PMC needs a design system. I don’t know what that’s going to look like quite yet, and I don’t want to rush into it.
Research
Over the past couple of weeks, I’ve been doing some informal research with the goal of getting a good idea of the pain points in the current design implementation and front-end workflow. The research consisted of:
- Conversations with the design team, project and product managers about pain points in the design implementation workflow
- Conversations with developers to get an idea of front-end competency and workflow
- Analysis of JIRA tickets that had a particular amount of back and forth
- Keeping good notes about conclusions and ideas for solutions to test
Process Experiments
I’ve been participating in my pod’s “business as usual” – i.e. fulfilling requests for features and fixes from the brands – and I am getting a good handle on the development process while suggesting various process improvements and experiments here and there.
A few of them so far:
- Including CodePens outlining the HTML/CSS for a feature. Based on the existing code-bases, there is a lot of misunderstanding about how to handle CSS layout, and my thought was that including a Pen outlining the architecture would serve as a helpful reference point. I don’t have enough data yet as to whether or not this is helpful.
- Pair programming JIRA tickets with project managers. This has worked out really well so far! More often than not, when we sit down to write a ticket together, it either becomes more than one ticket or we realize there is more information needed about the request. I like to think that’s saved some time in the long run! The project manager in my pod has a great handle on CSS and using the Inspector to communicate tasks, and I think that knowledge is very valuable.
- Separating front-end and back-end into different tickets. One of the current “business as usual” is a bit unusual – rather than an individual task, it is an ongoing project to refresh the homepage design on IndieWire. The tickets have been separated according to UI sections on the homepage e.g. one ticket would be the “Awards section” and another the “Reviews filtering section”. Rather than including all of the PHP, JS, CSS and HTML in a single task, we are experimenting with breaking the ticket up into:
- Static HTML – the raw markup, all by itself.
- Back-end/PHP – building out a widget, for example.
- CSS or “Design Implemetation” – applying styles to the static HTML in #1. This way, #2 and #3 can happen concurrently.
- Interactivity/Functionality – applying any JS and ensuring the CSS applies as expected in the theme.
- Style guide with KSS. With the homepage project mentioned above, I’ve started refactoring some SCSS and set up a KSS-node style guide in the project. My plan is to dump the static HTML from step 1 above into Nunjucks files and write the CSS separately from the WordPress site. We’ll see how that goes!
Documentation
Finally, well ‘finally-ish’, I’ve been working on documentation. PMC uses Confluence for company-wide documentation, and I’ve started working on a section called “Front-end Guides” that outlines some best practices for HTML and CSS as well as common patterns and tools used throughout the code-bases.
Documentation is also a big part of what the KSS style guide above will provide. My thought is that by religiously writing documentation, a language will start to emerge and we can consider the form of a design-system-thing from there.
I’ve also made a habit of updating the existing docs with things that I’ve encountered while setting up my development environment. Little things such as adding a troubleshooting section or a note that “running this command might fix it” will, I hope, help someone with the same problem in the future!
What’s coming up
Whew, that’s a lot! I’ve started a lot of small, ongoing projects and am settling in nicely to the development workflow (and learning some object-oriented PHP!).
Standardizing A Build Step
Before any kind of design-system-thing or front-end improvements can happen across the brands, we need to be able to easily write front-end code. That is not the case, at the moment. Developers have reported that it takes 20+ minutes to compile CSS changes using some of the current webpack configurations, and I have already spent several hours if not days debugging mysterious issues resulting from build configurations no one understands.
Over the next couple of weeks, I’ll be evaluating various options for uniting the build step: is webpack the right solution? Gulp? npm scripts? A combination? I’m leaning towards the latter, with an emphasis on separating the CSS and JS workflows. I have created an npm scripts workflow for IndieWire’s CSS and style guide and I like that a lot so far. JavaScript, however, is another beast, and although my gut feeling is that webpack’s complexities cause more pain than benefit for PMC’s uses, I need to give it some serious thought and research.
Carefully watch Scenario-Driven Design Systems by Yesenia Perez-Cruz
I discovered this talk called Scenario-Driven Design Systems by Yesenia Perez-Cruz that is all about how, at Vox Media, she and others created a flexible design system that served several brands – a similar situation to the one at PMC. I haven’t watched the talk in its entirety yet, and I want to give it some close attention in the coming weeks.
Slow down, brain!
My brain gets very far ahead of reality at times. I need to consciously slow down the idea generation and focus on doing the work, and not falling victim to jumping from idea to idea. The road map for the aforementioned design-system-thing will emerge, in due time! Patience, Lara.