Skip to content

You and Your UX Process

Few words can elicit such visceral reactions in the mind of a technologist as the word “process.” For some it has connotations of a proverbial straight jacket, but for others it is endlessly exciting. Regardless of how it makes you feel, I would like to outline how and why it is crucially important for your organization to structure how it communicates and executes on a user experience process.

In my organization, Portal Solutions, I found myself constantly being asked the same types of questions. “I’m responding to a RFP, and I need to demonstrate our UX approach. Do we have documentation for this?” “A client asked how we will be doing the interface implementation, and I need to know how I should communicate that?” These types of questions started to make it painfully obvious that my organization needed to think more structurally and holistically about these important topics in light of a larger UX approach.

I should state at the outset what I mean by “UX Process.” I use that phrase to refer to the overarching guidelines and details for how your organization does user experience design. Can you clearly demonstrate how your organization does user experience design across the entire breadth of your work? Is everyone able to answer in your organization how and why you do UX? If you answered “no” to either or both of these questions then this article is written for you.

What I want to walk you through is the general approach and lessons learned as my colleague, Adam Krueger, and myself embarked on this task for my organization. Keep in mind that this is meant to be a general approach, and you will certainly need to contextualize it to your organization’s needs. Also, this post is not just for UX consulting firms; in fact, the audiences I anticipate will benefit most from this are organizations who work in areas other than UX consulting.

Assessing Maturity

Since I stated at the outset that this article is intended for those without a clear process in place, therefore most likely you desire to formalize UX in your company. Perhaps you are a consultant for other firms, or you are a lone UX ranger trying to change the way your organization works and functions; either way the same goal still remains: evangelizing design methods that benefit both the business and your customers while solving real problems.

When we started our UX process, we first had to determine where we were at currently and where we wanted to go. Since I’m assuming many of you are in a similar situation, I want to explain where we found ourselves.

My company had strengths in select areas of user experience design—namely information architecture and interface development. We did these things, and we did them very well. We also had clear documentation and guidance to instruct other consultants on how to do this for our clients. However, we sorely lacked in some important areas. The most notable one for us was in the area of user research. After much reading, writing, and introspection we realized like many others that no matter how good our designs looked, it didn’t matter if they did not address real user needs, goals, tasks, and more.

I encourage you to think about this for your own organization. What UX strengths does your company currently have? Where are the weaknesses that both you and the organization have? How mature is your documentation on these elements if indeed you have any? When you answer these questions think about past failures and success you’ve had and what you’ve learned from them. These answers help you to know what you need to address as you work through creating your overall UX process.

Setting a Vision

More books have been written on vision casting than I would care to summarize–and for good measure. It might seem frivolous, but I have seen that where vision is lacking so eventually is execution. I want to walk you through some of the thinking we used to create a vision for our process work.

For my company we wanted to have a truly complete process that would enable success both for us and our clients. Here is what we created:

The vision for our user experience process work is to provide guidance to our staff that enables the success of both us and our clients in building solutions on the Microsoft platform.

The vision is clear and it communicates the ultimate aim of our process creation work. We were simply tired of doing rework and spinning our wheels because it impeded our ability to deliver solutions successfully and communicate our UX identity clearly.

Setting a vision involves choosing your strategic end or intent first of all. Ask yourself, “What is the one thing I hope to accomplish in this process work?” Remember, this is not a vision for your entire company or even your UX vision in general; this is only the vision for the task of creating your UX process. Be specific and avoid complexity to ensure your vision is attainable. This vision should function as your calibration point as you work through your process. Always ask yourself about what you are trying to do at the moment for your process to ensure it aligns with your vision.

This is also an important opportunity to ensure that your UX process’ vision matches the overall organization’s vision, values, and objectives. One way to ensure the top of your organization forgets your UX process is to work in a silo apart from the organization’s vision and direction. If possible ensure that your vision is clearly understandable using the familiar language of your organization.

Creating Goals and Objectives

Our field is predicated on tangible results, which is why we are so caught up in metrics. As such, they are very important. It is also vitally important to devise strategic goals and objectives as you move into this process work. This is where we learned a hard lesson: I wanted our organization to grow instantly, but it became apparent this was not going to happen. Being patient and demonstrating that patience to others can have quite an impact on others when trying to get them to buy into your suggestions.

Our goals flow from our vision. Since our vision focused on enabling staff to be successful, it is natural and necessary that our goals and objectives would share the same emphasis. If they don’t, you either need to revisit the goals or your vision. Here are some goals we used (notice how each starts with a verb):

  • Create a clear end-to-end organization and representation of how we do user experience design at Portal Solutions.
  • Enable the sales staff to clearly communicate our UX approach to avoid any miscommunications during project execution.
  • Empower staff to speak about and execute on UX throughout the whole project lifecycle.
  • Change one strategic area of our UX process to change or augment to deepen our UX offering.

Let’s talk about the last one for a moment since all the others are understandable. What we wanted to accomplish, and I encourage you to do the same, is to formalize your existing UX work and choose one strategic area to grown in (Mark Llobrera has similar guidance in a recent ALA article). As I mentioned earlier, we were very strong in UI development and information architecture. It was easy to formalize those things to answer those questions I asked earlier. However, we were deficient in the user research end. We did not have a good balance of attitudinal and behavioral research methods. Therefore, we choose to add contextual inquiry to the process and introduce the organization to it. What this did was allow us to demonstrate to our organization that we were not simply wanting to codify everything we had been doing—we wanted to grow in specific areas to allow us to become more effective at actually delivering on solid UX practices.

Choose wisely and balance being optimistic with being realistic. Your ultimate goal in this is to improve your organization and its delivery, so be strategic. Now is really the perfect time in our field to embark upon this work. Case in point is responsive web design, which regardless of how you define it technically, shook our industry because it was fundamentally a process and paradigm shift. That is just one example of how our field is maturing to think about process holistically and the implications of our chosen approaches.

The last thing to ensure is that you can measure your goals and objectives. After all, I wouldn’t take a goal for a UX project like “increase usability” because there’s no way in that goal to measure its success. In the same way, ensure your goals and objectives have some kind of measurable success factor. Ideally they will be quantitative, but even if you only had anecdotal success verification it is certainly better than nothing. For example, for my third goal on “empowering staff to speak about the process”: I could say my success factor is that 75% of the staff answer a survey positively expressing understanding in our process. That gives me a clear indicator of success for my goal.

So in concluding this section, choose goals and objectives that are realistic and flow from your defined vision. This will be your be gauge to evaluate how successful you are, and if you are not successful, what you need to change to get there.

Confronting Barriers

Here is where we move from foundational work into actually formalizing and expanding our UX process. However, before Adam and I could effectively being the process work, we realized we have several barriers we had to address.

We knew we had barriers before we even started, and most likely these barriers are similar across many organizations. We knew that management would be concerned that due to increased work in our design process that customers would balk at the increased time and cost (after all, the average IT project size seems to be decreasing). Also, we knew that not everyone in our organization would be as excited as we were on by topics like contextual inquiry. To begin alleviating this we began interviewing people across the company for their thoughts and opinions about this process work. This accomplishes three major things: (1) it allowed us to solicit feedback from others to increase the feeling of ownership and collaboration, (2) it helped our staff get excited about what was coming, and (3) it allowed us to demonstrate our process in practice. By doing the interviews we were tangibly showing how we wanted to model UX in our organization: namely doing user research to help us frame the problem and how we would solve it. I will speak in our final section how we addressed the cost concern.

Writing Out Our Process

Next we begin to document and explain the methodology. In my organization we had a very traditional UX process with traditional deliverables, and we were not going to become a Lean UX organization overnight. We found in a Boxes and Arrows article by Donna Spencer a sample UX methodology diagrammed by Todd Warfel. We loved how it encompassed a wide scope yet had the detail necessary to communicate what we wanted to communicate. We decided to use this as a model for us. However, in our context we wanted to expand it to include the sales process. The reason for this is because we found that if we incorrectly communicated UX in during the sales process, it led to difficulties down the road. Here is what we decided (open it to see a larger version):

Portal UX Process
Portal’s UX Process

Notice how the process speaks across the entire spectrum of how my company executes on projects, and in organizing this way we were attempting to allow our UX process to speak into our application lifecycle management (ALM) approach. I don’t expect a lot of what in you see in the graphic above will shock you in any way because it looks like a very traditional UX process. For us, that was what we needed. We were using approaches already familiar to our organization, but we presented and organized the information in such a way that was easily understood. One thing to note is that even though the process appears to be flat and linear, we wanted to emphasize our commitment to iteration. It’s simply a limitation of the graphical model that we wanted to point out to our staff.

Of course, the work does not stop with a graphic. We knew we needed to provide our staff with the content of each section of the process when they needed it in great detail and other times in Cliff Note form. So to accomplish our vision and goals we decided to create two approaches to our documentation: a master document that detailed each section of our methodology and also supporting documentation in the form of presentations that our staff could use to communicate the process and its individual components to clients. All of this work will ultimately made available on our intranet to our entire staff.

To collaborate on our master document, we spun up a collaborative environment in SharePoint (my organization’s chosen platform) and begun working together on a single document. We took the above graphical representation our methodology and created a table of contents and then proceeded to fill in the details. Since the purpose of this document is to have all the detail anyone in my company could need on any part of the process, it was laid out with all the necessary specificity. So for example, in the section on discovery and research, we did not simply talk esoterically about how to interview users, we wrote about everything from framing your questions and creating interview scripts to the importance of rapport and worldview. It is exhaustive enough to answer any question on how and why we choose to include that activity in our process.

We are still in the process of creating these Cliff Note presentation of each major section and areas I already mentioned. So when someone in sales needs to explain how we do information architecture, they won’t have to pull out a bunch of information in the exhaustive document. These presentations will be clear, digestible and readily available. The last thing we want to do is exasperate our co-workers by having to wade through our documentation when all they need is a simple overview.

Internal Evangelism and Continued Refinement

After working on the first two sections of our process (response and estimation, discovery and research), and even though all the details behind the process were not written, we did a company-wide training session on where we were at and what we were thinking. This was an opportunity to get the organization excited about the future as well as to invite others to join in the process beyond our initial interviews. After all, this process should rightly touch everything we do as an organization, so should not we invite others to collaborate with us? It is important to note, as I mentioned earlier, this is not the first time we invited others to peer into our work. We intentionally involved certain people throughout the process to solicit input.

Revisiting the barriers above, they came true when the pushback concerning cost and time for the new suggested UX approaches materialized. Our colleagues would argue that clients are not wanting large discovery and design phases. To counter this in our initial training session, we demonstrated with an example narrative (again use your UX skill set) and sample project plans to show that our suggested process could scale. We wanted to convey clearly to our company that our process doesn’t mean that we were suggesting all our projects needed to be six figures larger than they once were. If you are interested in the slide deck we used, you can find it on SlideShare. We also included completed deliverables in our process to serve a double purpose and provide training materials on our process.

By addressing these concerns proactively we had buy-in almost instantly, and our materials were being used in sales and execution. Of course one of our long-term goals is to make the above process more “lean,” but presenting a process like that early on would have been hard for the organization to adopt. Like any wide-scale organizational change, growing and evolving intentionally and strategically improves your adoption chances.

As evidenced by our company’s experience, socializing your new process is something you have to commit to at the outset. If you think you can simply create a nice graphic and extensive documentation and the company will change, you will be sorely disappointed. But when you commit to doing what it takes to make others around you feel comfortable and help them through it patiently, there is much success to be had.

Conclusion

While we are still in the midst refining certain elements of our process, now my organization has a point of reference to talk about user experience, and we have a platform in which to build on for the future. It is admittedly a tiring but very rewarding effort. I hope that you can benefit from our lessons and that your organization will continue to grow in UX maturity.

Published inUser Experience