I’ve done some freelance work and I really enjoyed it, but you don’t always get the opportunity to see things through to launch as a consultant. When you’re employed full-time in a UX role, you get to be part of the development team and are able to impact the product all the way through development to release. This level of continued involvement is what I have found to create the best-produced experiences. Here is my process for when I’ve been asked evaluate an existing project and manage the experience through to the new release of that product:
- Data Collection
- Product Review
- Prioritization
- UX/Heuristic Evaluation
- Wireframing/Prototyping
- Development
Data Collection
How can I create the right solution to a problem when I don’t even know the question? I can’t. It is not uncommon for me to be working on a product in an unfamiliar industry. So, the first thing that I do for any UX strategy project or product evaluation is find out all of the information I can about the product. This includes industry research, market research, competitive research, etc. I want to know everything there is to know about this product, what problems it is meant to solve and for whom. I try to get as much information from outside the company as I can (to balance what I get from internal stakeholders in case there is a heavy bias). Once I have all of this information, I know enough to begin to ask the right questions about the particular product on which I’m working.
Product Review
Unless I’m already familiar with the industry and the product in question, I don’t generally seek to perform a detailed product review on my own. Could I still perform an evaluation without this context? Sure, but I am potentially missing some crucial pieces of information that will influence my product recommendations. Therefore, my first pass at a product review will take one of two forms, depending on the type of product:
- If it’s a highly specialized product for a very narrow subset of users in a specific industry and it has a high barrier to mastery (e.g. an ERP for a specific type of manufacturing), I’m going to ask a product owner/expert sit down with me and demo the product. At this point, I am primarily interested in how this product attempts to solve the problems that I know exist in this industry or in the broader technology market (i.e. what major points in the product are creating cognitive dissonance for users as a result of being utterly foreign from those technologies/behaviors with which they are already fluent). This is a chance for me to start to challenge the product against the information I gathered in the Data Collection phase.
- If this is a product designed for broad consumer use and requires no special skill to master (e.g. a B2C eCommerce product), then I will conduct my own product review independently. This is a chance for me, without the bias of experience, to sit down and play with the product. Is it obvious to me what I should do next in the flow? Am I painfully aware that an interface is between me and my goal or does the interface fade away allowing me to easier access to the solution? How many times to a run across interaction behaviors or elements that I haven’t seen before? How many times do I get stuck or need to look something up? Essentially, this is a 30,000 foot view of what I will get during the UX/Heuristic Evaluation later.
The entire focus of this review is not to know everything about the product and perform any sort of assessment, but rather to simply gain enough context for the next step: Prioritization.
Prioritization
When working on existing products, there is, often times, already a product team that includes a project manager, produce manager/owner, development lead, etc; there might even be an established sales and support team. In situations like this, it is important for me to gain their perspectives before I start arbitrarily changing the user experience to match what I think is the “best experience” for that product. For the reality is that I wasn’t party to any of the decisions made before me that drive why the product is the way that it is today. So I need to understand a little bit about that history and find out what the product team has to say about their baby. The easiest way to do that is with a card sorting and prioritization exercise. For any activity like this, it is important to get at least one representative from all of the stakeholder groups in the room. It would be far too difficult to try to loop someone into that conversation after the fact and it is, in fact, their conversations (read: arguments) that will reveal a lot of what I want to know.
In front of each person is are a handful of half-inch plastic cubes (I actually bought a bucket of little cubes to use for this, but you candy works just as well) and a small stack of index cards. All of the participants are encouraged to write down each and every single pain point that they can identify in the product, including those unrelated to UX (although, I would argue that all everything on these cards falls under UX). I want every product pain point on the table, not just those believed to relate to one person’s perception of “user experience”.
Side note: There is something else that I’m really hoping to get from this exercise. I want to ask questions and guide the conversation in a way that fosters a little adversarial collaboration. It would be my hope that the team responsible for this product are at least somewhat passionate about it, so let’s bring some of that out. This will give me not only some of the product history, but also the product team’s history. Who is really in charge of the product, who has the most experience, where is the knowledge base, who do I go to for feedback down the line, how do I need approach some of these personalities, etc. The card-sorting is critical for my workflow, but sometimes the interpersonal information about the team is just as valuable.
I’ll even include some pain points of my own, identified during my product review, just to see if those items get any votes or rank highly in the team’s priorities. Once we have identified all of these pain points, we group them together by topic/category. Once grouped, we merge like concepts and attempt to condense the cards wherever possible. This actually can take a while as we often have to ask questions and clarify meanings or get examples from the submitter. Once all terms and topics are fully clarified and everyone is on the same page, we vote. I don’t give myself a vote, as I’m interested in determining their priorities as a group and I don’t want to taint that with my heavily-biased opinion. I try to give them enough votes such that they have the ability to choose only about 20% of the cards. I also try to make it so that, even if they all voted for different cards, it would be impossible for the collective group to choose every single one, some cards just don’t get a vote. This constraint forces them to think critically about how they value each item. For the actual voting, I encourage them to all go at once and to feel free to change any of their votes at any time. I also will ask them questions about why they are voting a certain way, continuing to foster dialogue between the group. When everyone is satisfied (or after the time is up, if I felt like they needed an additional constraint), then the votes are then counted and marked on the cards.
While everyone is still in the room, we review how the votes fell and I ask a product expert to “walk us through” the first 1-3 cards. I will record his screen as he talks through the pain point and then I can go back to reference this as I’m working later. The whole process should not take more than 3 hours for the most complicated product.
The final, prioritized cards become the basis for my workflow over the next few weeks. I identify which cards I can impact and which cards can only really be impacted by the product owner or some of the member of the team and distribute those accordingly. For example, a request for a new feature that requires new development belongs to the product owner for now. They need to determine ROI’s and champion the case for that feature. When it comes time for us to actually build it, then it falls under UX. With these cards in hand, I have the roadmap from which I will conduct my more detailed product evaluation.
UX/Heuristic Evaluation
Starting with the highest voted experience-related item and working my way down, I begin to perform a deep evaluation of the product. In addition to the standard heuristic evaluation, the most important thing for me in this phase it to identify the following questions:
- What is the solution that this part of the product is supposed to provide to the user?
- Does this current implementation of the page/flow/feature actually provide that solution to the user?
- If not, why was this decision made at some point in the past and what will it take to change it?
Customers don’t buy features. They buy solutions to their problems. So identifying the solution we are attempting to provide is critical to assessing the product from a strategic level.
After answering those three questions for each card and assessing the basic heuristics, I start to sketch out new flows and experiences that will later be the bases of my prototype.
Wireframing/Prototyping
I do all of my initial sketches on paper with a sharpie. I use a sharpie because it prevents me from wasting time over trying to correct minutia. I am only capturing concepts and ideas, so it does not have to be perfect. I will attempt to create no less that four unique experiences before I ever think about choosing something and moving forward. If appropriate, I will also engage with others at this stage to get their input on some of these new experiences/flows. Paper sketches is critical at this stage, you want to reduce the barrier to creativity and you don’t want to be restricted by whatever software you are using or anything that you have built previously. It is also imperative that I have already looked at the product and all of the cards that I am going to be designing for; this allows me to design with the overall product/flow/experience in mind. It would not be beneficial for me to start sketching prior to seeing the vast majority of the product. That type of segmented design would create a disjointed experience as opposed to me being able to sketch something that not only works for this card, but also connects fluidly with what I will need to do for the rest of the product.
Now that the war room is plastered floor-to-ceiling in screenshot of the current product and my proposed sketches, I will choose the best experiences (or combine sketches to form the best experiences) and translate these sketches into digital wireframes. I have used Balsamiq and Axure, but I much prefer Omnigraffle. If you’re looking for something with a flatter learning curve, Keynote is decent for rapid prototyping. Omnigraffle and Keynote both have more flexibility than a tool like Balsamiq and not nearly the barrier to use that you have with Axure. You also have the benefit of it being impossible for development to build directly off of your prototype, like they could in Axure. Whenever products are built off of the prototype, all of the mistakes and poor code have a chance to end up in the final product. I prefer to focus on what I am best at, then let developers build it right the first time, based on my documentation (rather than having to correct my code before they can move on).
After I have prototyped the majority of the product in Keynote, then I will go back and add clickable links so that the prototype functions essentially the way that I want the final product to function. The exception to this being that my prototypes do not include colors, fonts, button styles, element sizes, or even accurate container ratios/sizes. I am solely interested in describing the experience (i.e. how it works). The visual designer then adds to my prototype with all of the information related to how it looks, including final style guides.
Development
Unless something has gone horribly wrong, product management, the visual designer(s), the development team, etc. have all seen what I’ve been working on and have had a chance to voice concerns or provide constructive input. No one should be surprised by what came out of my prototyping phase. Development should already have been given enough information to start working on work-time estimates. My role during the implementation phase of the project is to respond fluidly to issues that come up during development. I’ve been working in a “perfect world” without limitations when I built my prototype and there will, undoubtedly, be things we have to scale back in order to form something that is viable. Every time we do this, we are creating UX debt. UX debt functions the same way that technical debt does and it is my responsibility to record that and ensure that we slot in time to address that debt in future releases. Also, it is likely that there is something that I may have articulated in the prototype that turns out not to be the “best experience” for the user and I will need to re-address how we want to handle that and provide new solutions to the dev team.
That pretty well describes my process when working on existing products.
If you have any questions, please feel free to send me an email!