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
Many of our colleagues still do not understand the function of UX design. This problem is systemic in many companies, cascading from a C-level where there is a gaping User Experience void—and no leader to fill it adequately—and fueling misconceptions at every level of the organization.
As a UXmatters reader, you probably don’t need me to educate you on the differences between User Experience and user-interface (UI) design. But many of the people with whom you work probably do need to better understand the differences—so they can more effectively engage your efforts and you can engage with theirs. Do you have time to sit each of them down and explain to them the fundamental differences between User Experience and UI design? Not likely. So, in this column, I’ll describe some ways in which you can progressively educate your colleagues on the differences between User Experience and UI design, as follows:
tactfully responding to misinformed comments
advocating for user-centered requirements
producing deliverables that reveal the why behind your designs 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