UX for Product Managers

UX is short for User Experience Design, and it can be defined as the branch of design that creates easy-to-use and delightful products that focus on the user’s needs.  UX is very important to all Product Managers because it is a key component of the 4 pillars of Product Leadership.

You can think of UX as another tool in your Product Management belt to help you create the best possible product: one that truly solves the user’s needs and reduces the user frustration that is so common in the software world today. In this post, I’ll focus on Software UX, meaning the interactions that users have with your software, such as installation, on-boarding, daily usage, self-help, etc. Keep in mind that UX is a comprehensive discipline. It can also help you design user experiences related to non-software areas of your product, such as packaging, buying experience, store experience (think Apple store), support experience, etc.

UX for Product Managers

One question I often get from fellow professionals is: “why should I care about UX?” People tell me that they’ve been producing professional software for decades, and they never had to worry about it. They think it’s a fad (like Agile, right?) and that it will go away soon. The truth is that design has been around for a long time, but only recently, engineering companies have started to pay attention to this discipline. Throughout the years, UX has had many names. Some call it usability, ease-of-use, etc. Regardless of how they call it, the important thing is that most companies today are investing in it to give their products an edge. A good user experience can truly make or break your product. Good user experience is important to both the final users and buyers, so it should become essential to you as a Product Manager.

One of the big catalysts for the UX explosion was the introduction of the iPhone in 2007. The user experience of this new device was revolutionary! So easy to use, so innovative, so obvious that it made us wonder: why didn’t I think about it first? It’s true that Apple has a history of greatly designed software, but the difference is that the iPhone was so successful that it became mainstream.  And with that massive adoption, more and more people started to expect the same level of experience from all their software products. The thought was: why can’t all software be as easy to use? Why do I have to live with clunky business software as opposed to beautifully designed applications?

Since then, companies have taken notice and started to invest in ways to make their software more user-friendly. A few years back, while working as Director of PM for a design agency, almost every conversation with Product VPs, CEOs and CMOs revolved around making their product more usable and enjoyable. They’d say: “I want my product to be like the iPhone. Well, not like the iPhone, but like the iPhone…”.

Before UX, most user interfaces were designed by Engineers based on their own view of the world. The UIs were functional, but they were usually very confusing and overloaded with information that didn’t need to be there. The good news is that those days are gone. UX brings to the table teams of trained professionals whose main goal is to design software that is focused on the user instead of business requirements or the will of the Engineering team. Below I introduce some of the basic terms and disciplines you’ll encounter as you start adopting UX within your Product Management practice.

Design disciplines behind UX

It’s important to mention that UX is an umbrella term. It refers to a grouping of design disciplines that together have the potential to elevate the quality of your software. Keep in mind that it is possible to find fluent designers in more than one of these disciplines. These disciplines include:

Information Architecture (IA)

Information Architecture is responsible for modeling and organizing all the data in your application. Everything else within the application will be built on top of this data model. Some common deliverables you can expect include site maps, information architecture diagrams, and object models.

Interaction Design (IX)

Interaction Design is responsible for organizing how the models provided by the IA will be displayed on the screen. Interaction designers design the overall UI framework for the application. They also design the navigation, and they provide ways for the user always to know where they are, where they came from and how to go back. They are also experts at selecting which UI controls to use depending on the desired interaction with the user. Some common IX deliverables include sketches and wireframes (like the one on the left). The development team will use these deliverables as a roadmap on how the application should flow.

As a Product Manager, chances are you are also creating some basic sketches or wireframes in tools like Visio or Balsamiq. That’s great because sketches are the perfect tool for communicating ideas to your team. But, when it’s time to design the actual application, it’s a good idea to get help from the pros and have an interaction designer leverage your sketch to work their magic.

Visual Design (VD)

Visual Design is the discipline that makes your designs shine! It adds color, fonts, texture, and overall look & feel to the wireframes, bringing them to life and aligning them with your brand. There’s a common misconception that UX is all about making things “pretty.” That’s not the case. UX is about making the user experience easier and more enjoyable. Part of it, yes, is improving the look and feel, but that’s not all. Visual Design is also about making sure the software conveys the right messages and even the right emotion (using color). Common VD deliverables include Photoshop and HTML files and other visual assets such as icons, buttons, title bars, backgrounds, etc.

Sometimes, the visual comps include annotations describing how the design needs to be implemented by the development team  (i.e., font type and size, spacing in pixels, hex colors, etc.). It’s also common for visual and interaction designers to create a style guide to capture all the appearance rules for the application. A style guide becomes the roadmap for front-end developers to implement the UIs exactly how it was designed.

Design Research

As Product Managers, we are measured by the success of our product in the market. A big part of that success depends on users adopting our product.  But early on, how do you find out the real pains of the user? Many Product Managers don’t like to ask their users for feedback or their biggest pains. They believe that it might make them look ignorant or feel they won’t innovate since the user is “giving them the answer.” Nothing could be farther from the truth, but there are good and bad ways to engage your users. And that’s exactly what design research can help you with.

Design researchers can perform stakeholder interviews, heuristic evaluations of existing software, contextual inquiries to see the users “acting in the wild,” Kano studies, affinity diagrams, and many other techniques to get to the bottom of the user’s pain. Design researchers can model your users by creating “personas” and can create complex flows that describe the user’s state of mind when performing specific operations with your software—fascinating stuff.

In general, users feel appreciated if you ask for their input. But be careful. Users will usually try to give you a “solution” to their problem instead of articulating the problem itself. This is where design research really shines. Researchers don’t “ask” the user what they need. They observe the users identify where they are struggling and therefore identify the real pain. Once the need has been defined, it’s your job to be innovative and collaborate with your team to develop the best possible solution. Believe me; this approach is much more effective than coming up with both the problem and the solution by yourself. That is a recipe for disaster, and there are many names in the startup graveyard to attest to that. Design research and usability testing are at the core of some of the latest business trends like Lean Startup.

Usability Testing

As you know, finding a bug on released software is many times more expensive than finding the bug during the early development stages. Likewise, the longer it takes you to find a usability issue or a design flaw, the more expensive it will be to fix, and even worse, you risk frustrating your users and hurting that adoption that you so much desire.

From an engineering perspective, it’s easy to think that if you built what you planned, then you solved the problem. Basically, if it passes QA, then the user will be happy, right? Not really. There are many examples of software that does exactly what it was designed to do, but it still doesn’t solve the user’s need. I’m not talking about the cases where we misunderstand the requirements and therefore solve the wrong problem. I’m talking about those cases where we created a solution for the right problem, but we implemented the solution in a way that still doesn’t solve the user’s need. Maybe it is cumbersome to use, or the approach is only intuitive to the developer and not the user. Regardless, the feature will fail, and you’ll have frustrated users. The role of usability testing is to determine if the solution you plan to develop (or already developed) will actually meet the user’s needs.  It’s critical, and you can’t afford to skip this key component of the development cycle.

User testing can be conducted with simple sketches, prototypes, or fully functional software. The choice depends on where you are in the development lifecycle and the type of information you are looking to get. User testing techniques include A/B Testing, eye-tracking tests, cognitive walkthroughs, etc. My main recommendation is that regardless of the technique, usability testing is constant throughout your product life cycle. Just like with QA, usability testing can’t be something you do only once. It must be done constantly with real users, and ideally, it should be part of every sprint.

The Bottom Line

UX is an invaluable tool in your search for the elusive ideal product. In my next post, I share lessons learned on how to integrate UX into your Agile team.  Be sure to read it before your next stand-up meeting. You’ll be glad you did.