Taking care of the grass
I had a client who was a fourth-generation Texan. He ran a healthcare IT company, but he grew up on a cattle ranch. And one day in a meeting, he told us this story:
The ranch he grew up on had this long entrance, and he had to mow the whole thing every week. He complained to his dad about wasting time cutting the grass when he could be helping out with the real work. His dad looked at him and, as only an old Texan can, he said:
“You take care of the grass, and nobody asks if you take care of the cows.”
They always just stare at you for a few seconds after saying something like that.
Okay, so that works a lot better in a talk, but I had to try. You can see where I’m going.
Even if they don’t realize it, people can tell when you take care of your product. The first time sets the expectation. Over time, it builds trust.
Inside our companies, it affects us too. When you constantly deal with bugs, breaks and inconsistencies in your own products, you stop paying attention. You get desensitized. It’s called the “broken windows theory.” The more things are disjointed, run-down or janky, the more willing you are to let them stay that way.
One crooked picture on the wall? Fix it. A room piled up with boxes and furniture? Fuck it.
In our work, it’s called “tech debt.” Or in our case, it’s design or experience debt. Tiny problems and inconsistencies that build up over time.
We make concessions to get our product shipped. “Don’t worry we’ll fix that as soon as we launch” we say, then we move on to the next thing and move that thing to the wishlist.
But there’s a reason they call it *debt*. It comes with interest. And the longer you avoid those problems, the more they cost everybody.
When I started writing this, I thought it was about doing “the little things.” But that’s not it.
It’s about the tedious, unsexy work. The stuff that’s hard to get excited about and easy to avoid. But it’s important. Probably even more important than that next sexy new thing you really want to work on. Because if you don’t mind the details today, you’ll pay for them later.
So let’s talk about a few ways you can pay down that debt.
1. Fix your shit.
One of the famous mantras at Facebook is “Move Fast and Break Things.” It was perfect for engineering-led startup culture. But as products grow into systems, you don’t have the luxury to let the little broken windows go unfixed for long. So around the time I joined, there was a new poster, often alongside the original. “Slow Down and Fix Your Shit.”
Photo courtesy of Stephen Gates
Look, bugs happen. We move fast and miss things. But we can’t ignore them. Fixing bugs is not a nice-to-have. If your product doesn’t do what it’s supposed to do, your product isn’t done.
In “Designing for Services Beyond the Screen” Andy Polaine uses the example of an airline:
“All the small glitches — delivering letters to the wrong address, billing errors, customers having to repeat details multiple times — damage people’s trust in a company. They make people wonder whether similar chaos is going on behind the scenes. If the airline’s web systems don’t work, how well does it maintain its aircraft?”
If you take care of the experience, nobody asks if you’re taking care of the planes.
So how do you ensure you catch these issues before they start breaking your windows?
Find and report bugs
I’m not talking about bugs that your users and visitors report. Obviously, you have an easy way for your users to report bugs! Right?
I’m talking about reporting bugs yourself.
As design and content people, it’s our responsibility to go back to the things we’ve launched and make sure they actually do what they’re supposed to do.
Does it look like it did in the mocks? Is the content right? Does it actually have all the features that you planned? If not, that’s a bug.
File a task and make sure your team fixes it. Don’t move on until the job is done.
Use your feedback channels
Sometimes the thing that frustrates people about your product isn’t a bug.
Maybe it’s an overly complex workflow, missing functionality or maybe it just doesn’t do what people expect it to. Without clear, open channels for feedback, you may be missing out on important product issues and ideas.
Which channel is the best? Depends on where your customers are. Are they posting on Facebook? Tweeting about your product? Can you ask for feedback through email? Ask directly in your product?
It doesn’t matter. Go where your customers are, and then encourage the rest of your customers to go there too.
But here’s the catch. You actually have to read the feedback and then respond to it. If your customers are actually giving you feedback, that’s a huge deal. Don’t let it go unacknowledged.
2. Set standards. Follow them.
Fixing bugs and listening to feedback are obvious ways to show you care, but they’re not enough to provide a high-quality experience.
In their book on Service Design, Andy Polaine, Ben Reason and Lavrans Lovlie explain how inconsistent experiences between the different parts of your product can degrade the overall perception of quality across them all:
“What is most important to look for is variation in quality between the touch-points and the gap between expectations and experiences. When people get what they expect, they feel that the quality is right.”
Consistency is key to a quality experience across your product. And to be consistent, you need to set some standards.
Set content standards
Everyone knows about brand guidelines and style guides, but that’s not what I’m talking about. Yes, you absolutely need those things. But after that, you should also start working to standardize how language is used across your products, websites and communications.
At Facebook, the content strategy team has in-depth standards around capitalization, spelling, punctuation, how to present numbers — all the traditional things you expect to find in a style guide.
But that’s just the start. There are also in-depth standards for special types of content that happen in user interfaces.
Let’s use button text as an example: Ideally, text in buttons should be one or two words and free of pronouns or articles. It should use the active voice and match the action or event that will happen when the person clicks on it. If you have more than one button, the options should be parallel and mutually exclusive.
Why so much attention to one or two words in a button? Because you never want someone to be surprised by what will happen when they click on it. Vague calls to action, unclear choices and inconsistent behaviors can all undercut trust and make people question the quality of the results they’re getting from your product.
Find design patterns
As we focus on individual pieces of content or elements, it’s easy to lose sight of the broader workflows we’re creating. But take a step back, and you quickly start to find patterns.
You’ll find common workflows or interactions. You’ll find groups of buttons, text fields and labels that work well together. As you find these patterns, build standards around them.
Are there interactions that can work for multiple use cases? If someone makes a choice near the top of the flow, do elements change below? Each of these is an opportunity to test and refine a single pattern that works best for your product.
Beyond improving the experience for the people who use your products, these guides can also improve efficiency for the people who build them. Content models, design files and even code elements can all be shared across teams to help everyone build better experiences faster.
3. Mind the system.
If you find yourself responding to customer feedback or proposed guidelines with things like “this was originally designed for a different use-case” or “it can’t work that way here because of how it works over there,” then you’re not really talking about bugs or guidelines anymore. You’re talking about systems.
Standards, guidelines and reusable components are important foundations for a functional system. But even those aren’t always enough.
Define object models
One of the best ways to make sense of a product system is to step back as far as possible and start develop a clear object model.
Don’t confuse your object model with your org chart. We’re immersed in our teams all day, every day, so it’s easy to build a mental model of our products based on the structures we see.
Here’s a simple test: Does your sitemap match your office map? Do your users navigate your product in the same way you navigate to your desk every day? It sounds funny, but it happens more often than any of us would like to admit.
Now try to forget what you know about how your product is built, and think about the way the pieces fit together. That’s an object model. In most cases, this is an abstraction, designed to help you and your users understand how the system fits together.
Build language systems
Similarly, language standards aren’t just rote rules about what to call things and what words to avoid. They provide guidance on how to name features, how terms work alongside each other and where this language may show up in the future.
When you’re naming features or aspects of a product, try to think through all the ways this product could grow in the future. Will you need to name similar features? Will the terminology you use now still apply if key pieces change? Are there terms for existing features or competitive products you need to consider?
When we started work on Facebook’s conversion lift measurement, I spent much of my time developing systems for the language in the product.
The first version of the product was only built to measure conversions and sales from our ads, but we knew if we succeeded here, there would be a number of other types coming soon. As I mapped out the content and named key metrics, I didn’t just do it for the product we were launching. I actually wrote that content for the next 3 or 4 versions that we hoped to launch — app installs, mobile devices and subscribers, brand metrics — to make sure it would work for them too.
Build design systems
As your product evolves, it becomes harder to standardize design patterns and guidelines. But with a clear understanding of how the big pieces fit together, you can start to turn those guides and frameworks into systems of moveable parts.
In his talk on the GE Design System at Enterprise UX, Dave Cronin described their approach as building Lego pieces rather than style guides.
My favorite slide from Dave Cronin’s talk (and from the whole conference, actually).
Cronin is the “Director of Design for the Industrial Internet” at GE. That sounds very internet-of-things-y, but what it really means is that his team works on interfaces for the things that people don’t realize have interfaces: aircraft maintenance equipment, MRI machines, oil pipelines, nuclear power plants.
They design components for actual rocket scientists… but also for Homer Simpson.
GE has 40,000 software and data engineers. When he gave that talk, Cronin’s team consisted of 20 software designers. Rather than trying to dictate exactly what people build and how, they approach the design system as a collection of interface stencils and components that can work together like building blocks. These pieces fit together in natural ways and support consistent workflows, while also giving teams the flexibility they need to adapt.
Are you taking care of the grass?
There’s a part of that teenage wannabe rancher inside of us all. We want to ride out in the open, see the land, take charge. We don’t want to waste our time doing yard work.
But here’s the thing: That work *is* the work. And we can only avoid it for so long before we get stuck in the weeds.
Way too often, we start looking at the next big thing and ignore the work that still needs to be done. Funny enough, the tendency to ignore those things is usually one of the main reasons you find it so hard to move forward.
Make the effort to take care of your products and people today, and you can go even bigger and better next time.
Cross-posted from claydelk.com.
