Over the last 20 years, Lori Landesman has worked as a Product and UX Manager at Netscape, User Interface Engineering, The MathWorks, IBM and Attivio. Most recently, she was the Vice President of User Experience at TradeStone Software, which provides enterprise software for the retail industry.
Lori is passionate about making life easier for people who use software, web and mobile applications. She leads cross-functional teams through a user centered design process that results in products tailored to target users and the tasks they need to perform. She’s educated user experience designers, product managers and executives by writing articles and delivering presentations to groups at Harvard Business School, ACM SIGCHI, UXPA, and the IBM Pulse conference.
For more than a decade, Lori has worked almost exclusively on enterprise software. Christine Perfetti recently talked with Lori to discuss her lessons learned while driving user experience forward at these organizations.
Just the Highlights: The Big Interview Takeaways
We conduct these interviews for product teams: product managers, UX professionals, and developers who are responsible for shipping great products. We understand it’s difficult to take time away from your job to digest content. That’s why we’ve highlighted the key insights for you below. We highly recommend you read the entire interview for more advice and recommendations from Lori.
The degree to which design will be prioritized within an organization is based on how the highest levels of management perceive design. If the C-level executives think of design simply as the aesthetics or color sets, it’s a major red flag.
It’s important to understand what kind of organization you’re getting yourself into. Is it sales-driven? engineering-driven? You’ll need to understand what pockets of the organization drive the business and product decisions, and who is perceived as being the money maker.
UX needs to be its own functional area, reporting directly to the CEO with its own C-level executive. If a company isn’t positioning UX correctly, it’s not going to be a priority.
The problem with product roadmaps. I believe a roadmap is a misguided approach because it assumes that more features are better, which just isn’t the case. Roadmaps rarely address how the priorities will make the customer more productive. It’s the wrong conversation to be having.
Alternative to roadmaps in the Enterprise. At IBM, when an influential customer wanted a feature, instead of putting it in the roadmap, the project would go to the professional services team to build the feature, test, and iterate.
Full Interview with Lori Landesman
You have been working in the user experience field for close to two decades. How has the field evolved?
When I first started out, user experience was thought of as mainly usability testing, typically conducted at the end of projects just before release. Over the years, UX professionals have started thinking more broadly about what it means to focus on the user experience. It’s become a much more integral part of the business.
When I was working at User Interface Engineering in the late 1990s, I had a dramatic shift in my perspective when we conducted a large-scale e-commerce research project to evaluate how effectively shopping sites enabled users to achieve their goals. While the focus of the research was on the shopping experience on the sites, we recognized that for users to accomplish their goals, the experience didn’t end when someone completed their purchase on the site.
The experience continued beyond the purchase. In addition to evaluating the site experience, we assessed how quickly users received the product, what their impressions were once it arrived, and the extent to which their expectations were met. We looked at the holistic experience users had with these companies.
I felt this shift in focus most strongly when I was at the MathWorks starting around 2002. It became clear that usability testing wasn’t the only thing we could bring to the teams. We started thinking much more broadly about the end-to-end experience prospects and customers had with our company and how we could use user research and the design process to understand and influence that.
In Enterprise software, how did you tackle injecting design into the culture?
It’s a huge challenge to foster good design. One of my conclusions is that for design to be truly integrated within an organization, it goes far beyond what the members of the product and UX teams are doing.
It’s about the culture. The degree to which design will be prioritized within an organization is based on how the highest levels of management perceive design. If the C-level executives think of design simply as the aesthetics or color sets, it’s a major red flag. Design can thrive only when the upper management is interested in learning more about how people use their products and the overall relationship users have with the company at all touch points.
This mindset from leadership makes a huge difference because it’s hard to assemble a team who can create something great if product quality and design are not rewarded. I have been on great teams that have accomplished amazing things sometimes in spite of management, but it’s such a better experience when the work is happening in the right culture.
If leadership is onboard, what are your priorities when entering an organization?
It’s important to understand what kind of organization you’re getting yourself into. Is it sales-driven? engineering-driven? You’ll need to understand what pockets of the organization drive the business and product decisions, and who is perceived as being the money maker.
When I joined Attivio, I was a UX team of one. Rather than jumping right into design work, I spent time understanding the organization, culture, and landscape. In my first several months, I invested time in understanding who the key drivers were within the organization, which paid off in the long run.
Through my conversations with the internal teams, it became clear to me that Attivio was a sales-driven company. The CEO came from a sales background and the sales engineering team played a large role in the sales process and providing feedback to the product team.
Because they were important to the organization, customer-facing, and regular product users themselves, the sales engineers were natural partners for me. I helped them design proofs-of-concept for prospects during the sales process. When they needed help demonstrating how our product could solve unique and specific problems, I created mockups using Balsamiq or ran workshops that enabled the team to sell more product engagements.
I demonstrated to the sales team how an adjunct member with design skills could help them. When talking with people about my time at Attivio, they are sometimes surprised to hear that I viewed myself just as much a part of the sales organization as I did the product team.
How did you measure the success of your designs?
At the time, being a team of one, I measured my success by how frequently and consistently colleagues in sales, professional services and development came back to me for help. I knew I could sell the importance of design if I could help the other pockets of the organization succeed.
When people talk about UX strategy, it seems like what they really talking about is demonstrating the influence of user experience on the business. Is this your impression?
Completely. UX strategy is not about improving the product. It’s about having the UX team make an impact on the organization. Attivio proved to me that this could happen. An important aspect of UX strategy is knowing how to use your skills to make an impact on the organization.
For a user experience team to have an organization-wide influence, it can’t reside under another functional group such as marketing or engineering. It needs to be its own functional area, reporting directly to the CEO with its own C-level executive. If a company isn’t positioning UX correctly, it’s not going to be a priority.
Under what conditions have you delivered the most successful product experiences?
When I worked with a small, cross-functional team with a clear goal and definition of success, we accomplished a lot. The most successful projects had small teams where team members brought different skills to the project. We also worked in short, focused timeframes.
What makes these smaller teams so successful?
Engagement with the customer is huge. It’s important to talk to the users on a regular basis, and run product concepts by them.
Also at Attivio, I worked with a team in professional services that delivered a product the customer valued because the team worked well together, and communicated with each other and with users frequently. We all had our specialties, but we shared ideas and helped each other out. I’ve found that teams work best when they exhibit genuine curiosity about the customers and each other’s opinions.
Things start to break down when team members only focus on their main competencies or responsibilities. For example, it’s a problem when the UX team members are the only people involved in the research or design. This is why I believe a waterfall process is problematic. It sets people up against each other because it says once your phase is done, you’re done. That shuts down the best part of the team which is communication and the ability to cross-pollinate with each other.
How important is research to your approach?
In enterprise software, I can’t depend on my own domain and tool knowledge to figure out what the product should do. At the MathWorks, the customers I worked with were statisticians. At IBM, I worked with maintenance managers at large universities. At TradeStone, the audience was retail professionals who do the design and sourcing of clothes.
When I joined these companies, I had no knowledge or personal experience in any of these areas. If I didn’t conduct user research, I would be flying blind. It’s not the same as designing a consumer product, such as iTunes. The only way I can assume the user mindset is by talking to real users and observing how they do their work.
How effective are product roadmaps for prioritizing work within an enterprise?
Almost everywhere I have worked, we’ve had some sort of roadmap that outlines the features we expect to deliver in the next 1-3 years. In enterprise software, customers demand it because they want to know what they are paying maintenance for.
I believe this is a misguided approach because it assumes that more features are better, which just isn’t the case. Roadmaps rarely address how the priorities will make the customer more productive. It’s the wrong conversation to be having. However, in enterprises, it’s a really hard cycle to break because the customers are demanding it and they want to know that upgrading will be possible and worth their resources.
If roadmaps aren’t the solution, how can organizations prioritize?
At IBM, the product team could experiment with new ideas if we could find a customer who was willing to pay for it. Also, in many cases, when an influential customer wanted a feature, instead of putting it in the roadmap, the project would go to the professional services team to build the feature, test, and iterate. If we learned that a feature was fulfilling a need for a broader set of customers, only then would it go into the roadmap.
At IBM, we were quite successful with this approach, but teams will always run into the unavoidable problem of high-powered, high paying customers who want their requests as part of the base product. It’s really hard to avoid. Ideally, an organization wants to get to the point where they have an R&D team that can experiment and innovate on opportunities for the future, but it’s hard to do that when you’re delivering on the demands from customers. It’s especially frustrating because those demands don’t necessarily make life any better for real users. In fact, because they promote feature bloat, they often make things worse.
Have you made any major mistakes along the way? If so, what would you tell product teams to avoid?
I haven’t always been persistent enough in assessing how the leadership defined product quality and good design and how they measured the success of my role. if upper management emphasizes “the pretty” or prioritizes the re-skinning of existing screens, those are red flags. If you want to do something interesting and that you can be proud of, it has to be in an organization that has a better appreciation for user experience than that.
What advice would you give to teams for delivering great products?
Teams need to consistently validate with the right users. The more teams are looking to themselves for ideas, the more likely they will get off track.
I can’t emphasize enough how important it is for teams to talk to each other and be open to each other’s ideas with the understanding that your team includes your company colleagues as well as your customers. You all have to be talking to each other regularly.