Here’s a whirlwind-paced, bird’s-eye-view video
(Length: 3:33. Go on. You’ve got time.)
Now delve into this case study
(Creating a new returns experience on eBay. A lot of reading.)
I recently undertook a large-scale initiative to redesign eBay’s returns experience. I outline some of the more interesting points here, and aspects of the process I followed, here. My cardinal rule when designing anything is always to ask a lot of questions (short of the level of persistent nagging ordinarily associated with 2 year olds)—but to be more specific, questions like these: “Why is this? How do we know this-or-the-other? How sure are we? Now what do we do to make it better?”—then re-apply for the set of answers that these yield.
Also, I must add that, while I outline a process here, it’s really just that: an outline. The creative process can be a slippery thing to quantify, so bear in mind that there was a lot of leaping across and between (and repeating) these steps as the project so often necessitated when new things came to light.
1. Problem exploration and definition
As with any project that involves a redesign, the reason why you’re changing it is rather important—perhaps the most important thing—in determining what happens next. The reason for this redesign—and the overarching principles that sprung from it—was straightforward: Something about the returns experience was so off-putting that it made users not want to come back to eBay—and the company was losing users (and thus business) because of it.
What was wrong with the experience?
When a user enters a return experience, it’s quite likely they are either disappointed or downright upset. Given that, and the fact that the person who sold it to them may have their own less-than-friendly policies for handling returns, the opportunity for both buyer and seller to enter a downward emotional spiral is high.
There was a large body of qualitative feedback from users on various forums (discussion boards, user interviews—individual and panel), as well as more quantitative data about when users dropped off the flows and/or called the customer support center. The main concerns the users raised were these:
I don’t know what to do next.
I’m not sure what I just did.
I don’t understand what all of this means. It’s so complicated.
Can’t you just remind me instead of dumping everything on me at once?
It’s not clear how long this is going to take. I just want my money back now.
I have a life, you know. I don’t have time to take this to the post office and send it back.
I undertook user interviews to add color to these findings, and also to check on the veracity of the data—to ensure that I wasn’t just following information that had become dogma, and may not necessarily still be indicative of the current user mindset. It turned out that the prevailing impression of the user was accurate though:
Defining the problem
I conducted various heuristic evaluations of the experience to establish a cause-effect relationship between it and the user feedback. Here’s a sample of one of the earlier heuristic evaluations I did: My intention was to reveal the experience’s flaws to key stakeholders so as to have this redesign put on the roadmap for the upcoming year.
With this freight of critique, I was able to go through the most well-trodden returns flows with my teammates and identify trouble spots, and group these into broad categories. With these established, the next step was to look at each of the problem categories, and create the associated design principles which would form the basis for the solution (ie. the redesign of the experience).
Because use cases were legion, and the variations of these numbered in the 1,000s, I worked with the technical team to extract the most well-trodden group of flows. I mapped these out, with all the possibilities of what could happen at every step: when time-outs could occur (when the users didn’t take action); escalations to eBay customer service, and so on. All of the flows followed the same overarching format, more or less—and it was this format which would be challenged (as well as all the more granular issues) in the concepting phases.
Now, with the predominant use case mapped out, the problem areas clear, and a set of preliminary design principles in place, I could move on to the first concepting cycle.
(But not quite until we mapped the top 10 use-cases out—just to be sure we didn’t miss anything. See below for an impression of what this looked like on paper.)
Identifying the target audience
While there were some SMBs (small to medium businesses) operating on eBay that used this flow to manage their returns, the majority of them used other dashboards that made use of the returns APIs instead (the same applied for the larger sellers).
The target audience for this returns experience was the smaller eBay seller. There were various areas of the old flows where the primary user wasn’t clear, and this caused problems for users with the experience: for instance, information that only pertained to medium-sized sellers (such as inventory codes) was requested in the flow for small sellers who didn’t use these codes, causing—at best—a blip in the intelligibility of the flow; and—at worst—a call to customer support asking what the meaning of this mysterious field was. So it was with considerations like this in mind that the new flows, in their fundamental form, targeted smaller operators.
2. concepting and design
Once a page/flow level inspection has been completed, it is perfectly natural to gather up all of the problems to solve, and break out of the existing flows/design frameworks to determine how to solve the problem. Questions arise: Does the flow have to operate like this? Do we need this step? Is there a way to turn this thing on its head and entirely change the way people return items? How can we change our business policies, and can we encourage our sellers to make their returns policies better to ease the burden on the buyer? Can we bypass the need to return items altogether?
The explorations in the concepting rounds were broad—but not potentially as broad as they might have been has the experience already been up to what was regarded as industry standard. While there was a clear intention to explore the future of returns, there was a very real objective to bring the experience up to par first: to create a baseline for later improvements, since the experience fell so far short.
One conceptual exploration around reducing the physical effort involved with a return involved how to make use of the free USPS parcel-pickup service, making it part of the returns flow through the USPS APIs (since the physical act of going to the post office to drop off a returned item was well-documented as a recurring pain point for buyers).
Another exploration yielded a change in on of eBay’s returns policies: For items worth less than $5.00, eBay (not the seller) would—on occasion—automatically refund the buyer (and subsidize 100% of this refund), and both the buyer and the seller would not need to do anything more. This turned out to be a real delighter for both buyers and sellers (reducing the aforementioned effort for buyers, and providing a monetary bonus for sellers).
Here’s a sample of what this looked like. It’s worth noting that I am not showing all the storyboarding it took to get to the design below, which appears in its final form. What you see here is the tip of the iceberg: much debate and iteration lay behind this (and all the other designs shown here).
I find that there’s never a bad time in a process to make a prototype, whether it be to check that the design actually works and makes sense in the wild; or to test concepts with users (as was done—albeit guerilla-style—with this project, since it had limited budget for testing with users after an initial design sprint). Time spent setting up a sound production pipeline early on in the design process (tying in tools with design libraries, creating input and output paths between all production tools), is time well-spent: That way one is freed from the drudgery that could arise when having to prototype regularly without a proper pipeline; and one can be free to be creative, rather than worrying about how on earth to create a prototype in time for the round of concepting/design in question.
Here’s an example of a prototype I created to show the final design for the seller refund flow:
4. a note about wireframes
This was one of the areas in this project where the overarching feeling in the team was that wireframes could be approached slightly differently: rather than keep them traditionally spartan, library visuals could be applied to them early because of the free availability of these libraries; and I was willing to give the approach a shot despite my nagging doubts as to its efficacy. My usual, fairly dogmatic stance on wireframing is that (a) it should always be done, without question, and (b) the wireframes should look like wireframes, and not anything like a more finalized design (even though, with the surge of design element libraries out there now, you can whip up a design that looks final very quickly—still a wireframe, but with a degree of visual polish. This may well indicate a shift in the design process—a good one—but I think a degree of mindfulness and discipline should be employed when making such a change in process).
In retrospect though, for this particular project at least, I think there’s a strong case for keeping wireframes traditional, and sticking to their original purpose of allowing designers to not get precious about the finer points of visual design when they should be concentrating on messaging, flow, and function (it depends on the designer, and the project, of course). And once they get those right, the wireframe then helps them build up the visuals in a way that is markedly different from the actual barebones wireframes. I do feel that, if a complex project is not approached this way (as in the case of the returns initiative), there’s a risk of the team and associated reviewers getting caught up in visuals too early, and during the functional/flow phase at that; and, because the design looks ostensibly polished even though the visual phase has not actually taken place yet, there’s a risk that the visuals won’t get the attention they deserve (the more one looks at visuals and gets used to them, the more they’re likely to stick, sometimes). And as a result, the final product tends to look very bare-bones—and almost like a wireframe (ironically). So I think one needs to be very mindful when using this approach to wireframing. Call me old-fashioned 🙂
5. Interactions with coders
I collaborated very closely with the coders on this project, and involved them throughout. For those key handovers—providing finalized mocks, and feeding back to them on coded pages—I used Zeplin for specs, and Invision to demonstrate interactions. JIRA was used to document any adjustments that needed to be made to the coded pages after I examined them (for visuals, accessibility, and interactions), along with annotated screenshots.
6. In conclusion…
That’s all! Well, not quite all—I haven’t covered every single aspect of this project here, but my aim was describe the significant milestones without writing the Magna Carta (on a single page).