I live in mild terror of a single question. It usually crops up when I meet someone for the first time. It’s not because the question is a difficult one for most people. In fact, it’s one many people enjoy answering.
What do you do?
Well, shit. I guess it’s time for me to attempt a meaningful answer to this. Here we go.
What the heck I do
I am a designer for Automattic. I design interfaces used to build a large portion of the web. Specifically, I work on WordPress.com.
Occasionally, at the mention of WordPress.com, I see ears perk up and a spark of recognition in someone’s eye. Unfortunately, they don’t usually hear or know about the .com part of my statement. If I then find out they are conflating WordPress.com with WordPress, an internal conflict starts brewing.
Do I elaborate and explain the difference between WordPress.com and WordPress, or do I let it slide just this once and move on with my life?
I almost always explain the difference unless I’m particularly eager to end the conversation.
For those of you unaware of the difference, WordPress is an open source project available for anyone to use for free. WordPress.com is a service that is in fact powered by WordPress, but is not WordPress the project. It has extensive customizations and now a completely separate admin we designed and built in React.
What I get paid to do by Automattic is work on various parts WordPress.com to improve the experience.
Cool. Once I explain that, I’m usually in the clear, but not always. Occasionally, someone will ask what the heck I actually do.
Crap. They’re on to me. Here’s my attempt to explain what I do as a designer at Automattic while working on WordPress.com.
There’s no short explanation that isn’t a drastic oversimplification of the work I do.
Attempted explanation of what I do via drastic oversimplification
Above all else, I design. This means I follow a series of pretty common design processes that, at a high level, are practiced across various professions and industries. It usually goes something like this:
- Discovery: research and understand a problem
- Ideate: come up with ideas to solve a problem
- Prototype: quickly build a prototype to test an idea
- Test: test the prototype
- Iterate: iterate on the prototype to improve it further and repeat steps 3 and 4 until you get results you’re willing to release into the wild
This is a pretty drastic oversimplification of a process that can take months. I apologize to anyone who’s written a design book over the last century or two. The list also doesn’t really help explain what my job is and what I do, but does help give an idea that some of the things I work on can take a good amount of time to complete and require a broad skillset.
A single day on my job is kinda wacky. Much of it is difficult to empathize with. I’m usually working on multiple projects simultaneously during the course of a week. This means I’m working on solving various problems on each project each day. These problems can be either design problems or a technical problem. Both are equally difficult. I’m corresponding on these using multiple communication tools per project including chat, video chat, blogging, and discussion on issue trackers (Github or Trac). I’m keeping my tools secure and up to date. These include command line tools that help our build process, various apps, WordPress installs, sandboxes, and anything else needed for that day.
A design problem can be as simple as creating a flow allowing someone to accept an invitation to a WordPress.com site (something Rick Bannister is working on with me currently). This sounds simple, but can be complex. The flow will vary depending on a few factors:
- Are they using a WordPress app?
- Which platform?
- Are they accepting via email?
- Are they accepting via WordPress.com notifications on the web app?
- Are they logged in?
- If so, are they able to switch accounts to accept on another account?
- Do they have 2-factor authentication enabled?
- And several more…
Each of these questions can span a new interaction that needs to be thought out, designed, built, and tested. We will also be gathering usage data which will help inform what works and what doesn’t. (This means I also have to do a bit of basic data analysis.)
We’ll usually mock things up pretty efficiently with wireframes or more high fidelity comps depending on the project. In this example, we went from rough wireframes to high fidelity mockups.
Quick sidebar: A wireframe is a super rough skeleton of a website or app to visualize interactions. There are usually no colors or styling.
When it’s time to build the thing, our designers are either coding out a prototype themselves or working closely with a developer or two to build the design out. Our designers are largely responsible for a good portion of the front-end CSS and a bit of Javascript. We also are responsible for making sure every design is responsive (works on devices of various sizes), works on various browsers, is accessible, and works on various devices. This means we know a large amount of CSS and HTML trivia in order to make sure we’re not breaking the internet for somebody when we make a change. We also test the heck out of it.
Sidebar: It’s really freaking easy to break the internet, by the way. I think Kevin Conboy said it best. He said something like “Our job is to break the internet and fix it again until it does what we need it to.”
Anyway, back to implementation. I spend a bunch of hours battling tools and writing code to encourage the browser to do what I ask of it. I often end up in bizarre edge-case corners of the internet reading various specs and understanding how to resolve some browser quirk. It’s way more fun than it sounds, even if sometimes a bit futile.
We have a pretty specific process for adding code that involves PRs (Pull Requests), design reviews, extensive Github discussion, and code reviews. Needless to say, we are all pretty comfortable with Github and Subversion flows. If that all sounds like gibberish to you, well, it is.
Once we get it built, we test the heck out if it. This means that I open a bunch of virtual machines, emulators, my phone, my tablet, and a few extra devices I have lying around and take my design for a spin. This can be super tedious with something like an invitation flow.
Next, we’ll have other employees test it. If it works and is an improvement, we’ll launch the thing without any fanfare. This usually involves a few hours of heart palpitations while we closely monitor our various methods of receiving customer feedback to make sure we didn’t break the internet again.
If we’re lucky, we didn’t break the internet.
I kind of glossed over the development aspect a bit, but you should all totally read this article to help understand what programming is like. Or just read it because it’s brilliantly written.
Okay, so I think I’ve really vaguely walked you all through what I do.
But that’s just for my day job. I also contribute to WordPress the project and a couple other open source projects. Everything I just described above, I do when working on the WordPress project, though much scaled back due to the fact that I am a human and need to eat, sleep, and yeah… that’s pretty much it.
I tend to leave out my work on the WordPress project because it tends to just add to the confusion for one of two reasons. It can accidentally result in more conflation of the WordPress.com and WordPress. It is also sometimes hard for someone to understand why the heck I want to donate time to that thing that sounds kinda like the thing I do on my day job. Maybe I’ll do a post on “Why I contribute to some big ol’ open source thing” instead of spending my time doing what normal people do (watching Archer in a snuggie and eating hot pockets?).
I’m sorry this got a bit ramble-y, but whatever… thanks for bearing with me.
Anyway. Long explanation short: I design, but in a really complicated insane way and I absolutely friggin love it. Send help.
P.S. I also speak at conferences, run local webby meetups, and have recently made attempts to play the banjo.
Ok! Now I get it. So what do you do???