UX professionals often find it difficult to demonstrate the value of User Experience to enterprise product teams, especially when companies or organizations lack UX maturity. Perhaps you’ve found yourself outnumbered on teams of solution-focused developers and their like-minded peers, feeling as though no one understands your perspective. You might have been the recipient of a dismissive arm wave. Maybe someone has told you that a product or a feature does not require UX oversight—even though it does. Perhaps stakeholders have told you that they already know what users want or there isn’t enough time to address a product workflow that could satisfy a core user need.
When you meet resistance from teammates and stakeholders, do you turn tail and slink away, then allow a product to go to market without its receiving the appropriate level of UX attention? Hopefully not! Some battles are worth fighting—as uncomfortable as they might be. As I described in “Demonstrating the Value of User Experience to Enterprise Product Teams, Part 2,” responding tactfully to caustic feedback from teammates is a challenging skill to master. It requires empathy, a trait that UX professionals must often draw upon in relating to the people who use our products. It is just as important to demonstrate empathy for our teammates, who are under their own pressures and must often meet challenging deadlines. Read More
What do you think of when you hear the term enterprise UX? Designing corporate Human Resources (HR) systems or intranets? Many articles and books for UX professionals focus on designing Web sites and mobile applications for consumers. But what about the silent majority of users in the workplace who are trying to get their job done? Many of them think of enterprise software as the generally sub-par tools that companies force them to use.
However, over the past few years, enterprise UX has started to get more attention from user-experience thought leaders. (There’s even a conference dedicated to it.) But what does enterprise UX actually mean? From what we’ve observed, it seems that there is not yet an agreed-upon definition of this term. This fuels confusion about enterprise UX, why it matters, and what scope it encompasses. Therefore, in our first column on this topic, we’ll
provide a working definition of enterprise UX
describe a few of the many environments in which enterprise UX makes a difference
identify obstacles to designing and developing great enterprise software Read More
Users want to work in familiar languages and environments, so companies that build and sell enterprise products to customers from different cultures and in different locales must support these expectations. Doing so requires localization—adapting documents or products to ensure they’re culturally appropriate. However, product teams often overlook this requirement or put off localization until late in the development cycle.
Even when localization is a formal requirement, a product team that is battling a tight deadline or budget constraints may choose to skip localization or defer it until a later release. Their localization effort languishes in the team’s growing pile of UX debt, remaining unaddressed until a senior executive receives an angry phone call from a customer, complaining about the product’s subpar experience in their native language or environment.
How can you, as a UX professional, support localization, help reduce the odds that your product might alienate customers, and avoid contributing to your team’s UX debt? In this column, I’ll provide a localization expert’s perspective on this topic, then describe some practical ways in which you can design user interfaces to better support localization. Read More