It’s performance review season, and a lot of you are thinking about ways to show recognition for the people you work with (and maybe get a little for yourself along the way).

At one of my past jobs, we had a regular survey that went around to get feedback on employee sentiment, challenges, growth opportunities, etc. Every time, people responded that one of the biggest areas of improvement was around a lack of “recognition” for their work.

A flurry of posts would go out from the managers and leads in the ensuing weeks announcing the great work by this and that and that person. And they’d all pat themselves on the back for helping to “recognize” their people. Yet the scores never really went up.

But the reason I consistently marked that as an area for improvement (yes, it was me!), and the reason so many people I talked to felt “unrecognized” wasn’t a lack of thanks or celebrations or tshirts (there’s certainly no lack of those).

Real recognition isn’t about my name on the screen at an all-hands. It’s about making sure I’m involved when you start working on something related to my work.

Too often, the same ones who scrambled to publicly “recognize” their people went right back to planning and discussing, privately, things that directly related to the work those people did.

I know everyone can’t be involved in every conversation. Sometimes a small group has to make decisions. But there’s a lot of room in between.

If you recognize someone for what they did, then you recognize what they do. And that means you have an opportunity to make sure they’re able to do it again, in the times and places where it’s the most valuable.

So yes, write up all the wonderful work your colleagues did last year, and let them know where they could do more. But don’t let it end there. Remember the things you said they accomplished (or better yet, look at the things they said they did), and invite them in when you start working on something similar this year. I guarantee they’ll recognize you for it later.

Emailing the org chart

Ever heard the term “shipping your org chart”? That’s when you design your product or organize your website based on internal power structures, not real customer experiences.

Sometimes these are huge disconnects in web design or product strategy. More often they’re just small details. Little things that don’t break the experience entirely, but they show a breakdown in the your ability to put the customer first.

In the last week, I’ve noticed two such cases where I could see the seams in a big company’s org chart.

Note to self

There’s a great little feature in the new Outlook iOS app when you send yourself an email (yes, I do this pretty regularly). The sender’s name shows up as “Note to Self”:

outlook appIt’s a nice little nugget that shows the Outlook app team did their research, saw a common action and then designed a feature to make it a nice experience. Now the reason I say “the Outlook app team” did this, is because here’s that exact same email in Outlook on my desktop:

outlook desktop 2

I’ve sent myself emails to track notes or to-do’s for years, and it’s never bothered me that it came from me. It makes perfect sense. The only reason I even cared is because I noticed the new experience and thought, “Wow, that’s nice. It *is* a note-to-self. Neat.” Then a little while later, I opened Outlook on my laptop and *whomp whomp*.

Does this ruin my experience of the app? No. Does it ruin my experience on the desktop? No. Does it remind me, blatantly, that there are different teams with different goals working on what is the same product for me outside of that company? You betcha.

Woohoo! Or not…

In case you think I’m just picking on Microsoft because everyone loves to pick on Microsoft, here’s an example from Google.

I’m a neurotic about unread emails. I hate seeing the counter and I hate being reminded that there are things that I haven’t dealt with yet. I wouldn’t say that I’m an Inbox Zero kind of person, because I’m perfectly happy to look at something and willingly avoid doing it. But I want to make that choice.

So when I finished opening, deleting or actively ignoring everything in Gmail this week, I got this message on desktop:

gmail desktop 2This time, I noticed because I thought, “Woohoo? That doesn’t really sound like Google. Must be left over from a long time ago.” There’s nothing wrong with it in particular, it’s just not the style that Google seems to take these days. And honestly, that’s only something a content strategist would notice or care about.

A little while later, I checked the Gmail app on my phone and:

gmail appWoohoo no more. Maybe a little dry, but that’s way more like the Google voice I’ve interacted with over the last few years. And since the Gmail app came a lot later than the web version, I’d bet that’s closer to what their internal guidelines call for.

Whether you prefer the woohoo or the straightforward tone, they’re definitely not consistent.

Again, does this difference break the experience? No. But does it tell me that there’s a disconnect in how these two (or likely more) teams are dealing with content and design inside their experiences? Absolutely.

So what?

These are pretty minor issues–even for something as mundane as email. But I’m pointing them out because they’re signs of something we all struggle with. More than the slightly disjointed customer experience, these differences are signals of inefficiencies and duplicate efforts for the teams that built them.

Don’t worry. I’m not just going to flame these teams and go back to my own org chart. Here are a few ways I’d recommend not making the same mistakes they did.

1. Talk to each other

This is the easiest thing you can do but also the easiest to stop doing when things get busy. To keep that from happening, schedule regular 1-on-1’s with partners to talk about what you’re working on and how they might relate or compete.

If you have separate teams for web and mobile or different teams for different parts of your product, use recurring team check-ins to make sure everyone is connected with their counterparts on the other side.

2. Review each other’s work

When we get heads-down on a project, we stop looking at what others around us are doing. Develop a regular process to make sure you can see each other’s work and give feedback. Invite people from other teams to your design critiques or demos to look for inconsistencies in the experiences or opportunities to connect with their work.

Sometimes it’s hard to make significant changes when you’re in the middle of a sprint or development cycle, so make sure you circle back with your partner teams during the planning and review stages. Don’t just create roadmaps for your own team, share them with other teams and look for potential conflicts or opportunities to join forces. After you ship, review the results as a group along with your individual managers or area leads.

3. Don’t sit in your org chart

You’re more likely to ship the org when you physically sit in it every day. Mix up where you sit so that you’re not surrounded only by the people who work on the exact same part of the product or are part of the same discipline as you. If you can’t move for good, at least go to other areas and work for a day or even a few hours. You’ll be surprised how quickly you start to think about the experience holistically when you’re not spending all day in your little part of it.

In Understanding Context, Andrew Hinton uses the example of a field with a stone wall to explain how physical boundaries affect our perception:

Such structures have a physical effect of stopping or slowing terrestrial motion, but they also carry a cultural meaning, such as “this land belongs to someone” or “keep your sheep on the other side, away from my sheep.” The wall changes the context of the field, transforming an open, undifferentiated vista into a specific human place with additional layers of significance.

The way we organize ourselves physically inherently affects how we think about our work and our products. Find ways to break down those walls, or at least step around them occasionally.

4. Wear the customer’s shoes

This is another step that’s easy to ignore. Take the time to test out your products or websites as your customers. I don’t mean playing with your prototypes, though. I mean actually going home, going to your website and trying to complete a common task from start to finish.

When I was at Facebook, every employee received a $250 credit to spend on ads, not as another perk, but so we could actually use the ads products as our customers do. We were encouraged to find a real business–friends, family members or local non-profits–and actually run real ads for them, then provide feedback on the interfaces and the results.

So go to your site. Sign up for a trial. Download the software. Check your email on your phone and your laptop. Take the tour. Read the app release notes. Whatever it is, make sure you’re stepping outside of your company and trying to see your work from the outside. You’ll be surprised how different things can look.

5. Think in experiences, not pieces

Does the customer’s experience start and stop within your area of responsibility? I’m guessing not. So don’t just think about the piece that you own–think about what the customer will be doing before they get to your part and what they want to do after. Do the experiences in each of these areas flow together, or can you see the seams? Look for ways to share designs, interaction patterns and content to support a more consistent experience across the parts, and you may even increase your team’s efficiency along the way.

During BuzzFeed’s recent reorg into separate news and entertainment divisions, CEO Jonah Peretti explained in a memo to employees:

Having a single “video department” in 2016 makes about as much sense as having a “mobile department”… Instead of organizing around a format or technology, we will organize our work to take full advantage of many formats and technologies.

Remember, you’re all in this together

When we’re heads down on a project, it’s hard to step back and take a look around. But it’s a necessary part of creating seamless experiences for our customers.

Customers don’t care how many product managers or scrum teams worked on an app. To them it’s all one company, and it should feel like one product.

Your customers may not explicitly notice when teams aren’t working together, but they feel the friction. And if it’s showing on the outside, you can bet people feel it inside the company.

Look for ways to connect the experience for your teams and your customers, or eventually the seams start to come apart for everyone.

Developing language from the World Bank

This week the World Bank announced there would stop using the “developing” vs “developed” labels for countries. What initially seemed like a surface level change of language may actually have a bigger effect on how economists and policy-makers view the world.
The data scientist who originally recommended dropping these qualifiers explained his reasoning:

“This is about updating people’s mental models as well… If the regular person’s mental model of the developing country is a big family [and] bad health outcomes, that might be a shorthand. [But] in a lot of countries, you have far improved infant mortality numbers. The old way of thinking of the developing world as this place where there’s been no progress is not that helpful.”

But most interesting to me is this point from the brief announcement on the World Bank’s blog:

“Two implications of this change are that a new aggregate for North America has been included in tables, and aggregates for Europe and Central Asia include countries of the European Union.”

When you change the groupings, you change the information and you change the types of things you can learn from it. I don’t know much about global economic analysis, but I’d be willing to bet these new tables tell a very different story than the old ones. Whether either of them is “right” is beside the point.

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.

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 Cronin's talk (and from the whole conference, actually).

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.