The FedEx UX Journey, Part 1

Underlying FedEx’s global shipping and logistics business is a complex technological infrastructure with many digital customer touchpoints. FedEx has recognized the need to improve the user experience of its systems, and has taken strong steps toward not only creating a UX practice area, but also toward moving the entire company to pay closer attention to UX in its customer-facing products. This interview is the first in a set of articles we’ll be running over the coming months to examine how FedEx is building its UX competency and practice. They’re still early in what they call the UX “maturity model,” so this interview focuses on the genesis of the effort and some of its early goals and successes.

This article is part of UX Magazine’s Business UX Leaders series. You can read more about the series, read other articles in the series, or sign up to receive future articles in the series by email.

Downey: Hello everyone, this is Mike Downey to UX Magazine and for my day job, I work at Microsoft on rich client technologies. This is the first of a multi-part series talking with shipping giant FedEx about how they’ve implemented a UX discipline across their company, and we want to find out more about that. With me, we have Tom Wicinski, he’s the VP of Digital Access Marketing at FedEx, and he has a member of his team with him: Brice Stokes, who’s a manager of digital user experience. Welcome, gentlemen.

Wicinski: Thank you, good morning.

Downey: So Tom, I thought maybe we’d start off with you. You can give a little bit of background on yourself and your group, and what you guys do at FedEx.

Wicinski: Sure. I’m a 17-year veteran with FedEx, having come up through multiple areas of the company. For the last two and a half years, I’ve been in Digital Access Marketing, which in essence is the product management role for all of our software products that we put into customers’ hands around the key goal of automating and making faster the way they interact through transactions with FedEx—whether it be shipping, whether it be track a package, any of those types of interactions—trying to turn all of those interactions into electronic-based as opposed to a phone call or manual type paper airbills.

We have several products that we implement, obviously one of the most well-known ones is fedex.com from which you can actually perform many different types of activities—whether it’s ship a package, track a package, learn about FedEx services, pay your bills even is available. So we’re turning it into a true channel for customers to interact with FedEx. We also offer software products to meet particular customer needs. We have an enterprise-class level of software that we implement directly into customers’ business operations—whether it’s running a fulfillment center that generates packages and labels at very, very high speeds to match their operations. We also offer a software product geared towards the desktop that allows customers to very easily integrate with their own customer databases and very quickly generate labels.

So we’re a traditional product management company in that sense, with very much of a software focus.

Downey: So a lot of people I think probably think of FedEx as a very operations-centric company—they’re the shipping company. But it sounds like that’s not really doing it justice, right?

Wicinski: Yeah, I think over the last several years, for sure, as we’ve taken a very strong shift towards trying to manage the customer experience as well. We found that customers, while we have eased the process of generating a transaction, they want it to be quick and easy. They’re looking for us to make their jobs easier. And with that shift in mindset, as we’ve had to shift our own mindset and take more of a user-centric design approach into the way we do our software. It’s not just around, “This is the way FedEx wants to do it,” customers are now demanding that we make their lives easier and we’re adopting those kinds of design principles into all of our software products.

Downey: So that’s really the sweet spot, I think, for what we want to talk about. So you mentioned user-centric design; to kind of set the tone for our conversation, why don’t you explain how you define UX? How is UX important to FedEx?

Wicinski: Sure. It really shifts the burden the opposite way of the way we’ve been doing things as far as inside-out. We’ve really tried to attempt to take an outside-in view, and be able to look at what our overall experience of our software is, as opposed to any just one feature.

Being an operationally-focused company as you described, we’ll launch a new transportation product or a new service periodically looking for new revenue opportunities, new market niches. And what was occurring to us over time is our software looked like an accumulation of a bunch of projects—every time we added a new one. And I think that the shift that we’ve taken is we’ve taken a more holistic approach now into our design process, and rather than designing for any one individual product or project, we’re now taking a holistic approach in designing the overall product with those capabilities in mind.

So we’ve already started to see some shifts in our thought process, in our design capabilities, and ultimately in the output we put in customers’ hands—where it is starting to make it easier for customers and we’re avoiding those kind of pain points that can often occur when you don’t think holistically.

Downey: So it sounds like you’ve been able to establish a pretty strong discipline for UX across the company. I work, myself, with a lot of large enterprises who continue to struggle not just to understand UX, but to understand how to get it implemented in a noticeable way, in a consistent way, across a large organization. Tell me about that. How long have you guys been able to have this kind of cross-company discipline, and what were your challenges in getting to that?

Wicinski: Yeah, and what I don’t want to overstate, either, is we’re still very early in our journey. I do think we’ve made some great success with as limited of time as we’ve been at this, because really we’ve only started this, truly committed, in June of this past year. So we’re quickly approaching our first year on this. It was one of those worries that the topic had been brewing for some time but the commitment didn’t really come until June. And when I say commitment, I’m talking organizationally, resources, everything else that goes with it.

But I think out of the gate in June the first step that we took was really around understanding roles and responsibilities, empowering a team in terms of the decisioning process, and committing the resources and process to make it happen. So we really had started to institutionalize it because we attacked it on those domains. Again, once we got it implemented as part of our standard product development process, that was probably one of the biggest items for us in terms of getting other to understand it, because it now became part of a core process.

Downey: So how did you get the ball rolling? Is this something that you tried to adopt principles in small ways and then branch out from there? Did you just sell a vision and dive into it? How did you actually get this process started so that you could get it implemented?

Wicinski: We sold the vision. We had enough examples as to where we’d failed against the experience that the FedEx brand promises. So we had some pain points that we needed to overcome. We had a very solid plan around where we wanted to go. So yes, we sold the vision pretty quickly and easily.

And then getting it institutionalized into the standard processes probably took the next amount of time for us to crank through. But we’ve successfully done that. And we did that by jumping into a handful of projects very quickly and showing the difference in the mindset, showing the value that we’d would get out of it, and then, like I said, empowering the team enough to say, “Hey, this makes no sense,” and forcing the team to rethink around how they’re doing things, ultimately leading to a better outcome. So we had some very early successes as well that really helped fuel us along.

Downey: I think related to that, I’ve found myself that in a lot of especially large IT organizations, there’s often an under-appreciation of design and really the function of design in all aspects of the company. Where were you guys when you started this endeavor, and did you hit push-back along the way as you tried to integrate UX and design principles into your different products?

Wicinski: Great question. Actually, it happened very easily for us, but not necessarily intentionally. And what I mean by that is, we actually started about a year ago with iRise as a visualization tool primarily intended to generate better business requirements. So we had a very strong IT support from that tool standpoint. The subtlety that helped us move along is we didn’t necessarily see iRise solely as a business requirements tool, but as a way to really start UX-type practices. So we had a common ground to work from—different objectives originally, but a very common ground to work from along with our partners in IT. And I think that has helped move us along because we’ve gotten better at the use of iRise, and not only is it helpful to solicit business requirements (which was their main intent), but we’ve also been able to use it to evangelize design opportunities for consideration to the various project teams.

Downey: Good… So I like the more tactical examples because I find—and you probably find this, yourself—when you talk about UX so much of the conversation is at a very high level and I think in a lot of case the disconnect is between the high-level principles and the actual tactical implementation—how do you make this stuff work? How much has that changed at FedEx now? Have you organizationally changed how you approach your customer experience and how you implement these principles?

Wicinski: Again, Brice’s organization didn’t exist prior to June, so the easy answer is “yes.” Where we are in our evolution is we’re actually on the cusp now of deciding what is our next step organizationally, because we’re fast approaching the cross-over point of what we can do as we’re currently organized. But we’ve made significant progress by putting this one team in place. So we’re starting to see where the additional opportunities are. So we’re just now starting to have those discussions around what does the future state of the organization look like.

So, as an example, there’s a few skill sets that we simply do not have in our organization today. We’ve been able to get to this point by outsourcing it, but again as truly being committed to customer experience, some of those skill sets we think need to be in-house.

Downey: And how are you dealing with that? Are you finding it hard to find good people to manage that? Is there a shortage of that type of expertise?

Wicinski: I think that there is, generally, but we haven’t… again, we’re kind of in the middle of that phase right now. So I can’t say we’ve been out aggressively recruiting yet for that. It’s starting to show up internally, that need. So this is kind of where we are in terms of the maturity model.

Downey: Right. So then let’s turn to Brice for a minute, then. So Brice, you’ve been kind of the tip of the spear, it sounds like, for this practice. What have been some of the big challenges that you’ve faced as you’ve been starting this process internally?

Stokes: Sure, good question—it’s probably the one I’m asked most often. The challenges that we’ve had right from the beginning were immediately finding opportunities to show value. The user experience buzzword looks great on a business card and it’s fun to talk about, but unless you’re really able to help others and help your peers in both IT and marketing, you could just be seen as another layer in the process. And so I think early on our original focus, in terms of our own evangelism internally, was finding those projects that we could work on helping with user flows, doing more of the process mapping—so some of the more tedious tasks that the teams in the past have struggled with, or aren’t as glamorous as, say, working through visual designs.

My team really was quick to roll up their sleeves and help others. Defining success metrics in a much broader term than just a launch date I think was another important objective. But there are many pieces of the UX practice that we were adding to our traditional product development cycle. And so coming to teams and saying, “we’re going to be doing extra work,” the original reaction was, well, that’s going to require more resources on their end. But turning the opportunity into one where we could help provide assistance helped demonstrate the value the UX team was going to be providing.

Downey: So again, to get a bit more tactical, when you have those types of conversations where you’re going to another team and saying, “Hey, I think we essentially need to add another aspect of your project planning process,” by implementing some of these UX studies, and customer-centric design, and interviews, and all those different tactical things that you do, how do you manage all of that internally? Are you only approaching a few teams initially and then using them as examples to other teams that you approach? Are you lending resources from your own centralized organization out to those individual product teams to help with that?

Stokes: Yes, and yes. So one key team member that I have on the UX front is our traffic manager. And so we have a very, very large, visible whiteboard that all of the corporate initiatives that are strategic to FedEx that we all need to be providing resources for and ensure that they are realizing success upon launch—all of those projects are added to the whiteboard and we overlay that with our UX activities. And our traffic manager fills out the required… basically it’s a request form that you would use for any agency that we would entertain in our past lives.

But this is something similar that we would use with all the project teams, and then we assign our own team members to really not increase the work load on those project teams, but to show that we’re going to take on that work load ourselves and provide value. And then track that progress and report on a regular basis with executive management. And I think having executive management involved early and often throughout the process and providing accolades and real engagement in terms of what the teams are building has been a real asset in terms of increased morale, and crisp execution on what’s most important to the targeted customers.

Downey: Great. So Tom, back to you again. Brice mentioned that executive support was really important; how have you managed to make all of that happen, and how have you kept the momentum rolling?

Wicinski: To me, movement always ties to visibility, and I’ve stayed very visible on this topic—particularly with this team in general. I meet every week, every other week, with this team directly as far as what challenges they’re running into, what opportunities still exist. So it’s something I’ve definitely dedicated time to, to make this team got off the ground and moving forward.

Brice and I talked at the beginning about how this is going to be as much of a content job as change management because we’re changing the way we’ve done things for many, many years. And to me the sense of urgency necessary for change was very clear. We heard from our customers the pain points they were feeling, so the sense of urgency was actually very easy to maintain with the team. And then it was around visibility and knocking down barriers for them as we moved along each step of the way. I’m not sure it came out real clear with Brice when he was talking through his example, but we found some allies very early on in the process. Some of his peer managers on his team all of a sudden became proponents of the work he was doing. They saw it first hand, how it influenced their product. So we rode a wave of good news.

Downey: That sounds like it’s really critical to sound the trumpets and make sure people throughout the organization realize the value and the ROI for this work. How do you guys actually measure and articulate the ROI for this practice?

Stokes: Well, it’s always a little difficult to quantify one particular activity. But when you look at the end-to-end process of all of the activities that roll into the entire software development process, you have metrics around time-to-market, quality, defects, customer satisfaction, and increased loyalty. And those are metrics that we’ve been monitoring for a number of years. Conversion rates inside a project or a product are critical to success. But defects—there’s a tangible cost associated to fixing a defect in production or addressing a customer experience issue in production versus addressing it early on in the requirements process. And I think focusing on production—either defects or customer experience issues—and reducing that number has been the key driver in terms of metrics that we’ve had a laser focus in reducing.

Downey: So in making this case for this heavy investment in UX initially and trying to articulate the ROI, what were some of the outcomes early on that you expected from this practice?

Stokes: You said outcomes?

Downey: Yeah, what outcomes were you expecting and has that changed since your initial assumptions?

Stokes: Okay. Well, early on we had a specific project and, without going into details, we had a number of features that we had to add to our invoice payment application. And typically, if you would have followed the pre-user experience practice, we would have sat in a room, we would have went through a Word document, we would have had our own debate, and then we would start building, and we’d see what launched.

Well, by working with our peers in both IT and marketing, and using iRise simulations, and doing more up front requirements gathering processes, and walking through concepts early on, my expectation was that we would make changes early and often and see a rise in our customer satisfaction scores in terms of the prototypes and the concepts that we were building. And we were able to demonstrate real data through multiple iterations and working through multiple concepts to say, the features that we’re implementing on round one of the design have been drastically improved, and the customer experience had improved by 20% or more after rounds two, three, and four.

And so therefore you had supporting stakeholders in terms of the improved requirements that we were passing along to them for the next phase, and as well understanding that our go-to-market communications and products that we were going to be releasing were going to meet or exceed customer expectations.

Downey: So it sounds like the real data that you were able to model and discuss and articulate with the rest of the business was really helpful. Did you think there was an appreciation, though, for the more intangible or immeasurable benefits that you get from an investment in UX?

Stokes: I definitely do. I regularly receive notes of appreciation on behalf of the team members that are working on the projects. There’s more of a customer focus, there’s a different way in terms of creativity and problem solving where teams are getting out from behind Word documents and email and really thinking about the customer as they’re doing some problem solving. That’s refreshing, and I think it builds teamwork and increased innovation in terms of concepts that the group’s coming up with, because you’re really having a dialog across multiple stakeholder groups. And I think it just drives increased energy across the organization.

Downey: Now is that something that is a bit of a surprising outcome to those who have now been involved in this UX practice? Or early on when you guys were really selling the idea internally, do you think people were appreciating those intangibles?

Wicinski: I think they appreciated them. And I say that as we’ve done some of this, but we primarily did it with agencies on the outside. We never really empowered our own internal folks to do it. So I definitely think they can have appreciated some of the softer benefits that come along with it. We, for some time, have stated our goal was really ease of use of the software from an experience standpoint, so that didn’t change. But there is a sense of greater ownership now that it’s in-house as opposed to something that we were outsourcing through agencies.

Downey: Right. That’s an interesting topic, as well. I know a lot of, especially the larger enterprise IT groups do look to outside agencies to assist with this type of process. Do you have any advice on how to do that effectively, so that if your end goal is to bring more of this in house, how can you best leverage outside agencies to help you with that?

Wicinski: I think it really comes down to figuring out where you want to make the commitment and where you don’t, and figuring out how to supplement those places where you have no business either staffing or building because you simply don’t have that capability. And we’re still working through that as well, trying to figure out what role the agency’s going to play even in this new work.

So we had a sense coming in, with what we started with, we had a sense as to where we want to grow, which means that as we grow our reliance on certain agencies will decrease to some degree. But without question there’s always going to be a role for them, and that’s what we have to work our way through. So it’s really a roles and responsibilities question, and then deciding where do I want that internal capability to reside.

Downey: I think a lot of people think of agencies as: you go to them, you tell them what you want to have built, and they build it. Have you found that there’s kind of a new discipline among agencies where they do more consulting on helping coach you to implement some of these things internally? Less about taking an RFP and turning it into a deliverable, and more about…

Wicinski: Based on where we are on the maturity cycle, that’s what we are expecting more from our agencies now, as well. Because that’s a key skill set that we’re still trying to build internally, that’s exactly what we are asking agencies to do more of today than we probably did traditionally. And again that’s simply because they can’t always come in on a per-deliverable basis and understand the holistic product. That’s why we’ve decided to build some of this internally and have that expertise where we could take that more holistic approach. But yeah, we definitely count on agencies from a thought-process standpoint, from a current trends standpoint—they can certainly supplement what we have. This was never positioned as a model to completely cut out agency costs.

Downey: Right, so it sounds like the role of agencies is starting to change a bit, at least specific to how you guys operate your business.

Wicinski: Yeah, I definitely think so.

Downey: So that’s one aspect of it: bringing in the outside agencies. And then there’s enterprise IT, and I work with a lot of enterprise IT organizations and I’ve found that there’s definitely understanding and appreciation of UX now that there probably wasn’t within the last few years. How do you guys work with IT, and what’s that process been like?

Wicinski: I think it’s been very positive for the reason I mentioned earlier: again, having that common ground of a toolset has helped because they’d already done some extensive training on that—this is iRise in particular. So the organization that we work with very closely has kind of been on this path already, but for a different reason. So I think it’s been exceptional, actually, because we’ve been able to use the same toolset to draw multiple benefits out—obviously, UX being one of those benefits.

Downey: In my experience, I’ve found that one of the common things organizations like yours will encounter with IT is resistance to change and resistance to taking on more support workload, basically. If we implement new technologies that are “UX technologies”—rich media platforms and such—then they have to re-train their staff to support it and they’re taking on more responsibility. In a lot of cases, IT departments are already overburdened with that. How have you guys been dealing with that? Has that been an issue at FedEx?

Wicinski: Resourcing and priorities is always an issue—you’ll never get away from that. We have made the commitment to do it, we have seen the training get implemented across a large number of individuals, the teams are working very well together on a day-to-day basis on the projects, so in that sense it’s been a very good move forward. Like I said, the big gain for IT out of this is: by using these tools, the requirements development process—the systems development process—has gotten significantly better. Because we now have something much more tangible to work with through our prototyping work up front. We’re making less adjustments deeper into the development cycle.

Downey: So to kind of summarize some of the things we’ve talked about, let’s describe a scenario: if I’m somebody who’s a champion of UX inside of a large organization right now, and I’m in some kind of position where I can actually exert some influence, what’s the advice—the high-level advice—that you guys would give to me based on your experiences over the last year or so since you’ve implemented this inside of FedEx?

Wicinski: One, I think, is being able to tie together the pain points your customers are feeling along with the soft benefits that a UX-type focus will provide. I think being able to layer a hard metric on top of it, as well—something that you’re going to strive for improvement—would be the next big one. And then after that I think it is very heavy change management. You think around, okay, how am I going to get this organized to move around this. For large organizations, that’s often the largest challenge.

We definitely spent a lot of time around effecting change within the org, creating that sense of urgency around why are we going to go do this, getting those early successes where people can see the tangible benefits that are going to come. Finding that one voice that was going to help champion you, or champion your efforts across peers, across organizations. I think that’s the way we’ve been able to ride.

Downey: That’s great, great advice. So we talked about how you guys sold the vision initially, organized yourselves to start implementing a UX practice, and how you’ve slowly started to implement that in different products. What, now looking back at it, has been the biggest payoff? How has this changed FedEx as an organization?

Wicinski: I think that the biggest that came around it is again, if you look at the way FedEx is organized, we’re a large company, we’ve got multiple operating units—Express, Ground, Freight, and so forth—it’s really forced the discussion around when and where those units operate differently. And driving the experience because of those differences sometimes created disjointedness from our customers’ perspective, and I think that’s the obvious…business rules across OpCo’s became a focal point for us. And we’ve seen great benefit from there as to where things don’t make sense, and ultimately don’t make sense to our customers.

Stokes: And I would add that, from my perspective, I’ve seen an increased awareness at the executive level. So being able to capture executive mind share in terms of what we are releasing to market, being able to have those trade-off discussions early on in the requirements gathering process versus having surprise discussions when you are either near a launch date or post-launch date has really been refreshing. It’s a great dialog; you still have something very tangible that you can walk through with the executive team and to help build consensus and understanding about what’s going to be released to the market.

Downey: That’s excellent. So my last question for you, then, is: now that you’ve gone this, and are continuing to go through it, what are the biggest surprises for yourselves individually about UX—what things are different now than your assumptions were before you got started?

Wicinski: Whoa, that’s a tough one.

Stokes: Yeah…well, I’ll begin. For my team, I think when we first started it was a team of people that were doing a job previously that was not UX, including myself. And I was a little nervous about the capabilities on the team, about whether or not we would really be able to go through training, roll up our sleeves, and use the tools—even across both marketing and IT. I’ve been really surprised in a positive way to see that there’s a true passion for this space, that I’ve seen an eagerness for learning.

We have team member from all areas, not even all in my group. But there’s an interest across the entire organization to use UX practices within their own project, and I frequently receive requests from across the entire organization for more training and more understanding, and more practical application of some of these processes. I wasn’t sure if we would receive that wave of interest early on, or if we would be perceive as just another layer in the process.

If I was speaking with any other company of FedEx’s size, I would say: look, take the first step and I believe you’ll be really surprised in the results. You’ll see metrics, of course, that are going in a positive direction, but I think you’ll see the soft benefits in terms of morale and engagement increase tenfold.

Wicinski: I’ll extend that thought a little bit. I mentioned earlier around one of the things that we’ve done with this team is really empower them, that they basically had the authority to stop a project if we weren’t able to solve the UX issues that were in front of us. And the surprising part about it is, while we’ve empowered them with that, they haven’t had to use it. Meaning we’ve been able to build enough of a case through our prototyping efforts and our UAT efforts and so forth that it never got to that degree, that it was much more visible to our various stakeholders on the UX position. We’ve avoided those debates completely because we made it so obvious that it needed to get fixed. And I was expecting a little more internal tension on that than what we’ve actually seen.

Downey: Gentlemen, thank you very much for joining us today.

Wicinski: I really appreciate it.

Stokes: Thank you. Thank you for coordinating.

Downey: Tom Wicinski and Brice Stokes, UX gurus at FedEx. This is Mike Downey. You can catch my blog at richplatform.com. Thanks.