For the past 4+ years, I worked as a Happiness Engineer supporting WordPress.com and the WordPress apps. I spent roughly the first two years working in the WordPress.com Support Forums, and I found that I loved providing public support and troubleshooting the incredible range of issues that arose there. I spent the past two years supporting the WordPress apps, and over time I got more and more involved in testing them as well.
As I spent time developing on my own manual testing approach, working with beta testing communities, exploring the support/development feedback loop, and encouraging my coworkers’ troubleshooting skills, I also kept an eye on a team being formed at Automattic around automated testing and bug prioritization. I worked with and learned from them as more discussions arose around testing and quality within our fast-paced, distributed environment. And although I enjoyed helping people use WordPress, I discovered that my favorite work was helping development teams understand our customers’ needs and identify what issues most needed their attention.
That work and study paid off, and today I started my first day as an Excellence Wrangler. I’ll be automating tests, doing manual testing, triaging bugs reports, and generally helping our support and development teams communicate and prioritize to create the best experience possible for our customers.
And if that excitement wasn’t enough, I also had a delivery that I’ve been waiting on since I hit my four-year anniversary at Automattic — a new laptop with the WordPress logo:
When I was in school, I always thought math word problems were a little funny. I understood that the point was for me to apply math to solve real-world problems, but the problems never felt real. However, these days I truly appreciate all of the ways that math taught me how to think about, break down, and work through problems.
These are the same skills you can use to solve a problem in support, as well:
Gather data about the problem
Look for patterns
Make a conjecture
Test your conjecture
As noted in the video, it’s also incredibly important to tackle small, discrete parts of the problem and work from there to the larger solution. If you stare at a big problem, it can look impossible to solve. But if you can prove theories about small parts of the problem, the larger solution can become clear.
Thank you to all of my teachers and others who encouraged me to learn and practice these skills — although I don’t do much pure math these days, I use these skills every day!
If you’re interested in inclusive design, I’d recommend listening to “On Average” from the podcast 99% Invisible. From the episode:
So in 1926, when the army was designing its first-ever fighter plane cockpit, engineers measured the physical dimensions of hundreds of male pilots and used this data to standardize cockpit dimensions. Of course, the possibility of female pilots was never considered. Of course.
The size and shape of the seat, the distance to the pedals and the stick, the height of the windshield, even the shape of the flight helmets were all made to conform to the average 1920’s male pilot. Which changed the way the pilots were selected.
You basically then select people that fit into that and then exclude people that don’t.
Designing for the average and excluding anyone who doesn’t fit that average isn’t, well, inclusive. The episode goes on to discuss how design (including in the military) has become more inclusive — but it’s still something we struggle with.
From what I’ve seen in software design and development, one of the challenges is deciding which user personas and scenarios will be considered in your design, and which issues are only edge cases. Where and how do you draw that line? It’s also a matter of just remembering to think outside your own perspective, to consider cases that you haven’t thought of already. (As designer and fellow Automattician Mel Choyce pointed out, it’s about challenging your own biases by seeking out and really listening to users with different perspectives.)
As a linguaphile, I tend to notice when software design struggles or forgets to include non-English languages. For example, designs that aren’t responsive to languages that take up more space (ahemGermanahem) or that don’t consider right-to-left languages end up excluding entire populations of potential users in other parts of the world. It can be hard for monolingual designers and developers to know how their products work in other languages, and it’s always satisfying when I have a chance to test a product and suggest language-based enhancements, so people can use our products in any language. It’s one small way I can help democratize publishing for users around the world.
An exciting part of working at Automattic is the open source philosophy. It’s thrilling to help open source projects like Calypso (the new WordPress.com), even in a small way. I spent a chunk of time last year reviewing open bug reports, enhancement requests, and the like before the project was open sourced — it’s fun to see (and help with) new issues that come up as more people work with, get inspired by, and contribute to Calypso.
Open source isn’t just about developers, either — I do a lot of my day-to-day work in the open. I used to mainly provide support out in the open, helping users in the WordPress.com forums. These days I spend most of my time in the WordPress app repos, reporting and testing issues in the open there. (If you’d like to get involved, I also started posting calls for testing the WordPress apps over at Make WordPress Mobile.)
Openness can really be part of everyone’s work — from open source, to open testing, and open support. Being open helps us learn from each other, inspire each other, and keep us aware of and oriented toward the wider community in which we work.