Process in Enterprise UX Can Be Different

When working on projects in an enterprise company:

You never know at what point you will be pulled into a project.
With groups that are more UX-centric, you'll get to start earlier. With other groups, it can be as late as just before release to do UI cleanup. A UX designer has to be able to jump in at any point in their process and complete the work needed.
You work with a business analyst. Business analysts' work and techniques intersect with UX.
Unless your process is defined by the enterprise, you have to find the spot where you are both comfortable in giving up part of the work you might normally do. But the advantage is that you feed each other's process. In the descriptions below, "we" means my business analyst and me.
Access to users is usually limited.
That limitation can be no access to access only allowed with upper management accompaniment. You have to come up with other methods to indirectly get to know your users.

I still follow the normal process:

Discovery
Analysis
Design
Test

But, I work tightly with the business analyst and upfront with the development team.

Discovery

Stakeholder Interviews and New Process

In conjunction with the team's business analyst, we discuss the goal of the project and what the business stakeholder wants to achieve with a project. Sometimes this is creating a new application, replacing and application or introducing work that must be completed for new government regulations.

We also want to know what their vision new process should be. In situations where we are replacing entire applications or creating new applications, we may work with upper level business directly to create a story map for the new process. Or we may take what we hear and create a map of the process.

Current Process Research

The business analyst and I will spend time interviewing local product managers from pre-selected branches throughout the world. Our goal is to get a bigger picture of the various processes influenced both by culture and government regulations and find their common components. From a UX point of view, I'm also looking for solutions they've come up with they will not be willing to change or will be difficult for them to change.

User Research

Being able to do serious, deep user research can be unpredictable in an enterprise company. Often direct user research can only be done under the radar. I've learned to research employees indirectly using representative users, Linkedin, Facebook, YouTube, generational research and job descriptions and advertisements. Where I've had direct access to employees, I've used surveys, interviews and observation.

Current Solutions Research

I will review and learn the application our employees may currently be using. I may also do a heuristic review on the current applications to determine what is and isn't working from a usability view point. This work helps in our discussions with business and their expectations.

Competitive Solutions Research

I may do a comparative review with other companies' applications as much as is possible through their website and images posted on the internet. I look for the assumptions they've made about their users skills and abilities and the expected process/task flow.

Analysis

Personas and Design Guidelines

Using user research I will either augment, update or create personas. I've found at my current company, our personas do not go stale as far as attitudes while technical skills and environmental factors may change. I'll do full persona rewrites about once every five years.

Between direct and indirect user research and personas, I create a set of design guidelines for the project. These along with the business analyst's requirements will act as my checklist for my design work.

To-be Workflows, Journey Maps and Pain Points

During user research we will identify current actual workflows. I will usually formalize these in a document and document pain points at the same time. In addition the business analyst and I will work with business representatives to identify the expected workflow combining both expected workflows and pain points.

User Scenarios and User Stories

User research also informs use cases and user scenarios. We will often find out employees are doing work or processes our business representatives were unaware of and we have to determine if our project will support and/or include this work. While I will rarely write user scenarios or use cases, due to the agreed upon division of labor between business analysts and UX, I will review them and advise of changes that may need to be made based on my analysis.

Design

Wire Framing and Initial Application Architecture

During the initial project scope work that the business analyst leads, I will have discussions with development to determine where the application will be placed in our enterprise tools environment. In several of my current projects our applications replace part or all of legacy technology, but must be launched by that technology to keep the flow of our employees' work intact.

Each discipline usually has a concept for the flow and work within the application. I will take all of this input and make sure I discuss any technology expectations and limitations with development to create initial wire frames for the project. This acts as a starting place for discussions about business and development expectations before I start any work on mockups.

Design Work to Prototyping

Once a project moves from the scoping stage to initial iterations, I move from wire frames to designing in more detail. I will e-mail questions about process or to review small design elements to business representatives and employees. While business will have a proposed process within the application, I want the design to support both what business wants and how our employees will really use

My business analyst and I usually work hand in hand. As he or she gathers requirements, I will take those and create design. We review this together with the business representatives and refine both the business requirements and the design. Development is always with us at the table and we often have discussions about direction both technically and UI design-wise. It's also important to me to understand my technical boundaries especially when creating new interaction patterns.

Informed Design

I make sure that the designs I'm creating are based on informed design. Informed design is based on sound psychological and physiological principles reflected in standard industry and corporate UI patterns, employees' technical and digital experiences and expectations and well-thought out business process. I spend time researching new interaction designs, both the supporting psychology, determining the most commonly used industry pattern and determining any modifications that need to be made to them.

While my design work may start out as physical paper and pencil sketches, it all goes into a mockup/prototype. The amount of interaction is dependent on how soon the work is needed and how much interaction is needed to inform the development and test teams. My prototype is used as the UI specification, although I will usually add additional notes with the business requirements.

Development Phase

During the development phase, I work with development and QA to make sure the design is implemented as close as possible. I work out any issues that come up either technical or business requirements-wise. Because I have a development background I will often help out with any HTML or style issues. I've even researched how-tos for middle tier development for junior developers. At different milestones I will do a testing pass through the application to identify UI bugs.

Testing

Usability Walkthroughs

Once we have the majority of functionality defined, our team will do remote usability tests. Sometimes we use a development build of the application, otherwise we use my design prototype. A lot of it depends on how difficult a testing environment is to set up, how functional the prototype is and how much realistic data the prototype contains.

Usability testing is a team effort or it wouldn't be doable within an iteration or two. Making it a team effort also creates buy-in from all of the disciplines on the team. I'll identify the type of employees we want to test. Business representatives work with regional and branch managers to identify operation-level employees across the world to invite to testing. Our business analyst or program manager will send out and set up meeting rooms. During this time period I'm identifying our goals, writing scripts and communicating with our participants. If we're using a development build of the application, development and QA are setting up the environment. They will also pull in production data or create it.

When we do the testing everyone is present. Development and QA are required to attend one to two sessions depending on the number. Our business analyst, program manager, most all business representatives and at least one developer, who is responsible for answering any technical questions and helping work through any bugs we might hit, attend all the sessions. Directly after each session we document everything we saw and heard in a debrief meeting.

Because I moderate the walkthroughs, I watch the video of each session afterwards and takes notes on all issues and combine them with the debrief notes from the team to determine what needs to fixed, left as is, business rules that may need to be supported and determine recommendations of how issues should be fixed. As a team we look at the results and determine what will be fixed.

Post Release

Depending on the complexity of the back end of the application, the development team will determine if we need to do an alpha and/or beta release of the application. In this case I'm working with our business analyst to determine what issues employees are seeing both in the business rules, performance and the UI. Once issues are identified, changes are made for the next release.

System Usability Scale (SUS)

Once the application release has been out and in use for three to six months, I send out a System Usability Scale survey to employees who have been using the application. I also add in 3 free-form questions about their experience in the system. This gives us both an idea of how usable the new work is according to our employees globally and what reasons may be causing any low scores. We'll often find out where training has failed and what smaller functionality needs to be re-emphasized. We also find out any major issues that may not be coming up from our business representatives or what functionality employees really need to make the application better.