UX process to take over a internal application

Question

I am currently in the process of taking responsibility for a larger application. It is an internal application that will have about 200 users when it goes live.

It has been in development for two years and has little to no documented requirements. Everyone has their idea of what it is supposed to solve but only the general outlines are documented. New features are added based on the process owners experience. So finding out what the system is supposed to cover and what business value it brings is a bit of a hassle. I am responsible for creating new user stories, documenting requirements for new functionality and generally getting the project on a track within the next four months. My initial thoughts are to start mapping out what exists in now and what should exist in the future using these tools:

• Stakeholders interviews
• User Journey Mapping
• Service blueprint
• User testing / observing users using the existing ("un-finished") app (as is).

This to get a overview of the state of things. Soon I will start helping the process owner describing new functions (you can't stop a runaway train) and get acceptance for user involvement.

The reason I am asking here is that most tools we use refers to how to use them with a website in mind, not a process application for enterprise. So if you have some articles or books on UX for larger applications and enterprise, much appreciated!

Answer 1

Interesting question... I'm not sure it matters that much whether the project is internal or external (besides the fact that you may have less of a deadline for an internal project, but that's not always the case!), but if I were you I would focus on fundamental systems engineering - requirements. I think you must determine what your system is supposed to do, even in the general sense. You really can't go anywhere until you figure this out, unless it's purely a experimental project. Perhaps the stakeholder interviews is where you should start?

Given that this an enterprise app, this is even more of a reason to define a systems engineering process, for things get less efficient and more chaotic the larger they get.

Sorry that I don't have any UX books to recommend for this: I would go with a good systems engineering book or manual.

Answer 2

It sounds like you're on the right track. The first step is establishing two things:

1. What people use the tool for
2. What people think the tool does

Interviews, exploring the tool, and reviewing your findings with key stakeholders are all good ways to achieve this. Depending on the complexity of the app, it may be best to do this at a higher level than at the nitty-gritty level--but listen carefully to mismatches between 1 and 2.

Along the way, you're invariably going to get a thousand feature requests and reports of painful interactions. Take note of these, but remember that you don't have any data (yet) on their priority or severity across users.

Once you have this understanding in place, you can figure out the delta between where the tool is, and where it could be. What goals was it intended to support? Does it still support those goals? (As companies grow, and software evolves, it's really easy for these to get misaligned--a tool that worked for a 30 person company isn't going to work well for a 300 person company, or a 3000 person one.)

At the end of this inquiry, you should be able to articulate what people use the tool for currently, what it can do that people don't use it for, and what people think it can do but can't (or does, but with bad side effects). Then, as a part of planning improvements, you can merge this with requests for improvements or expansion, and decide what makes sense to change.

And one overall caveat: any tool in use, no matter how painful, has some goodness in it. It's tempting to throw the whole thing out and start over, but the tool has evolved in some particular directions to support your organization. Find out why they exist before you change things that seem 'dumb'.

Answer 3

Seems like the right approach to me except I would add few things in the process, I had the same challenge recently. As you mentioned it's an internal application with 200 users. You are sitting on gold mine of user base which is easily accessible.

One thing which I did differently and worked for me is co-creation. I involved users and stakeholders in the design process using workshops for assumption validations, user journey map, prioritization (defining MVP), design studio. It worked great in decreasing the time needed for research, development and filtering of ideas. More on co-creation:

https://uxplanet.org/co-creation-the-user-as-a-co-designer-2db32c844035

https://uxdesign.cc/empowering-and-engaging-through-co-creation-389c41904efc