User experience is most often thought of in the context of public-facing designs, like e-commerce sites and, more recently, mobile apps. Increasingly, however, organizations are becoming aware of the benefits of UX to what they do internally.
Most companies have spent the last decade attempting to shed as much cost as possible in order to remain competitive and maximize profits. Having tackled many of the obvious areas of spending and workforce productivity, they are now looking to new areas, such as the efficiency and effectiveness of applications that are used inside the organization.
Anyone who has ever used a business application can testify that they are often confusing, slow, and buggy, requiring a certain amount of training to use. Not only does this lead to tasks taking longer, it can also result in poor data collection, from which the business then makes ill-informed decisions. In some cases this disconnect negatively impacts the customers’ experience as well. Phoning a company only to hear, “Sorry, the computer’s running slow today,” does not leave a great impression.
All of this costs money in terms of poor productivity and lost revenue. In addition, there are the costs of a small internal industry of training and support that is built around such applications.
Where does UX Fit in?
The fundamental challenge with most of these applications is that they are owned by internal IT departments. Business requirements are fed to development teams whose focus is on the technical delivery of features, with little consideration for the end user. As applications evolve they can become increasingly bloated and complex. The UI becomes confusing and users are left frustrated. Companies get away with this because of the huge investment and because their users have no choice but to use the software.
By injecting a UX process into the application lifecycle, these applications can become easier to use, more intuitive, and faster to learn. This increases productivity, reduces training time, and increases workforce morale. The impact on the company’s bottom line is unquestionably positive.
This all sounds great but there are challenges both for the organization and the UX provider.
IT departments are not like sales and marketing teams in that they have not purchased services that would fall into the “creative” category. Therefore they are often wary of UX providers, creating a cultural clash between IT and “design.” Some from the UX world may think that this is similar to any project where developers are involved. However, in this case, the developer is firmly in charge. There will be resistance to UX providers, and more than ever the concept of UX will need to be evangelized at all levels from the board director down.
Donating Skills
There is also a skill issue as developers in this environment are hired for their ability to write complex code, not because they understand CSS. This might also ring true in other development environments, but again it’s important to remember that IT has probably zero experience of working with the design community. There are many technical teams out there where none of the developers have ever met a designer.
UX can be evangelized from the top down, but not imposed. Members of the UX team will need to be embedded in the developer teams. Otherwise, what comes out of the development process will not be what went in. Working as part of a UX team myself, I have seen developers provided with usable HTML, CSS, and JavaScript that was completely ignored. The development team started again from scratch with poor results. The team did not have the skills to create HTML/CSS/JS code that matched what the UX team produced, or the skills to integrate that code into theirs.
Working side by side, UX teams are able to make their code work and teach the developers a way of UX thinking. The development team feels more involved in the process and like they are contributing in a significant way—far more so than when decisions are made outside of the team and work is imposed on them.
Meet the UX Developer
UX providers also need to think about their own skill sets. A great benefit for my team is that I am a developer by background and therefore in a good position to build relationships within the IT community; something someone with a strictly design background might find difficult.
This raises the issue of the “UX Developer” role, which I feel is under-represented in today’s UX workforce. The UX world tends to pull its people from design backgrounds, looking for designers that have development capabilities. I think it’s time to start encouraging many more developers who understand design.
After all, it’s the developer who actually delivers the UX. If we want applications with great UX, whether public-facing or for internal consumption, then we need developers who value the importance of UX and have the skills to deliver it. It’s the development teams that take on the UX role after we’re gone, so their buy-in and ability is crucial to ongoing success.
The Process for Internal UX
With regards to the UX process, the approach is generally one that practitioners are familiar with. Methods such as cognitive walk-throughs, ethnographic analysis, user interviews, and so on can be used but with a strong focus on objective quantitative data. Senior stakeholders will care much more about measured improvements in efficiency than employee satisfaction.
The users are a far more defined group: professionals within the organization with a specific skill set that the software is tailored for. As a UX provider, you need to appreciate that these users bring knowledge and experience with them. For example, if the application is for use by finance professionals then UX practitioners cannot pretend to understand it as one would with a shopping cart. Therefore you will need to rely on the user and their input much more than you might with fundamentally simpler experiences.
Data on application usage will often be harder to come by than in the world of websites (you will not find Google Analytics for example). Instead you will either need to implement analysis software or rely on other sources such as indirect business data (last year X number of people processed Y applications and therefore each application takes Z).
I previously mentioned HTML and CSS, however in the enterprise environment there is no guarantee that the technology is web-based. Applications can be desktop installs built in VB, Java, or C++. Therefore, when prototyping, consider that you may need to use such technologies to provide an accurate representation of the final experience. It is also worth investigating any limitations that such technologies have: for example, the use of color may be impossible.
Where the browser is an option it’s very likely that the latest technology may not work. I’ve yet to come across a client whose internal IT infrastructure would allow HTML5 to be used. Think Windows XP and IE7 not Windows 8 and IE10. On the upside, you know that the software environment is locked down, so if they do have IE7 then you don’t need to worry about IE8 or 9.
With business apps you also have the advantage that the functionality is king. There is little need to worry about brand or other marketing type collateral. You focus 100% on the tasks that the user is carrying out and only what UI is needed for those tasks.
Whereas a company may have only one website, there can be thousands of internal applications and a single user may need to use more than one. Consider UX not just in the context of one application but the complete set. If a user has to switch from one app to another then there should be consistency and commonality that allows them to do this easily. If they have already used one app, then they should be a long way toward knowing how to use another. Of course, it can take a long time to work through a full UX process for multiple apps in order to achieve this, but it’s worth considering upfront.
This also means thinking about how UX is delivered within the organization, as it could mean covering multiple business units who will act like individual clients. At Howard Baines, we always suggest some sort of UX oversight group made up of senior stakeholders that pulls in application-specific stakeholders (such as product owners) when required, with a core group carrying a consistent UX approach through all projects. This oversight group also serves to educate areas of the business prior to the UX provider becoming involved.
Conclusion
While a company may have a single website which represents one UX project, internally, the employees may be using thousands of applications that represent thousands of potential UX projects. The benefits to the organization of embracing UX internally are clear. Working on such projects may be the less glamorous side of UX, but the opportunities are great and you actually get to see the benefits to the users on the ground as well as the business as a whole.
Image of eye peeking through fence courtesy Shutterstock.
