There are a lot of examples out there of “ideal” UX processes. A few popular methods I’ve seen recently condense the UX process into a five-day sprint going from ideation to prototype, like the buzzy Google Ventures product design sprint. As a disciplined process, it’s valuable to absorb. Unfortunately, it requires five days of uninterrupted work and full-time participation from everyone from developers to C-level stakeholders, which means it’s near-impossible to pull off if your office is anything like mine.
At Media Temple, a web hosting and cloud services company based in Los Angeles, I’m the UX Architect, responsible for designing the user experience and UI of nearly every product our users interact with. I work with a team of really talented visual designers and front-end devs to turn my wireframes and prototypes into beautiful, functional products. I’m the only person in my role, which makes it fun and challenging, but it’s not a unique situation among companies.
Especially in larger companies with multiple products or at organizations just starting to adopt a formal UX practice, resources and time are limited and pulled in a few directions at once. If you’re the sole UX practitioner for your team, you’re stretched thin.
This isn’t your usual “best practice” article.
It would be awesome to follow a regimented sprint schedule (and make everyone else you work with respect it), but that’s not the reality in a lot of offices, where projects pivot suddenly and you get inundated with last-minute requests. You need to develop strategies that allow you to put out solid work quickly while incorporating collaborative feedback.
I’ll present five strategies for improving your process when deadlines are tight, teams are busy, and you’re responsible for creating easy and delightful experiences when conditions aren’t ideal. This kind of chaos can be challenging, but it also affords you opportunities to be creative with your process. After all, as UX designers it’s our job to make order out chaos.
#1 – User stories are gospel
User stories are the source of truth on what your product will and will not do. They describe how your product works and serve as your initial guide for how a user will navigate, operate, and find value in your product. Not so coincidentally, user stories are written from the user’s perspective – a good example of what they look like would be – “As a user, I should be able to add a secondary credit card to my billing settings.”
Chris Mears has a good description of user stories in his UX Basics series: “The user story from a UX point of view is a discrete piece of functionality or user goal that you will have identified through your user research.” His use of discrete makes this my favorite description. For our purposes, user stories work as a finite, itemized list of interactions we need to design in order to get our product shipped.
User stories are also strategically invaluable to your day-to-day work, since they create accountability for everyone on the team. When you’re on a deadline, it’s liberating to have a list of what you do and do not need to complete for the project’s Minimum Viable Product (MVP). User stories also empower you to fight for the user within your organization. Patrick Neeman has some deeper thoughts on the value of user stories to the UX process in this appropriately-titled article Why I love user stories.
User stories vs. product requirements.
If your team doesn’t rely on user stories, you probably use a list of product requirements. In either case, it’s essential for you as the UX practitioner to be involved in the conception of user stories or product requirements from a very early stage.
Form relationships and work closely with your product managers through your entire UX process. Most importantly, know the product vision and internalize the user stories. I highly, highly recommend reading Inspired: How To Create Products Customers Love by Marty Cagan. It will teach you to think about products holistically, from a product manager’s perspective.
#2 – Everything can be improved through iteration
Iterate, iterate, iterate.
As interaction designers, we have a compulsion to finesse every detail until it’s perfect. But products are never perfect on the first release.
Good design takes time to think and experiment. On deadlines, sometimes you just have to execute your first good option and ship your deliverables. Sometimes, the finer details of your interactions get lost in the shuffle of engineers pushing to get the product built. And that’s okay.
That’s why we iterate.
Work with your product managers to prioritize improvements
Before release, identify areas that you know need some finessing: Does this copy make sense? Are users clicking this button with its current placement? If you can’t resolve these questions with a quick usability test (see #5 below), make your product manager aware of these problem spots so both of you can monitor user engagement once the product is live. If your organization has a customer support team, ask that the agents keep an eye and ear out for on-the-ground feedback, positive or negative.
When it’s time to plan the next sprint, work with your product manager to get your most important improvements into the queue. Fight to treat interaction improvements with the same seriousness that you would squash engineering bugs.
#3 – Include Everyone
Brainstorm with team members
There’s a reason UX authorities (like Leah Buley and Google Ventures) advocate inviting your teammates into the ideative, sketching, and prototyping phases of your process: Great ideas happen when you get a bunch of smart people together. Ideally, everyone in your organization – from accounting to HR – is invested in the user’s experience. Our most thoughtful products are those that were conceived in a two-hour session in a room with the stakeholders, a whiteboard, and plenty of markers.
Unfortunately, if your teammates are as busy as you are or if there’s any sort of product backlog, it’s really hard to get everyone together in a room for an hour – much less to get commitments for a few days of UX sprinting.
Make allies from other departments
Cultivate strong relationships with teammates across the company and outside your discipline. You need to be able to count on your peers understanding your role, “getting” and absorbing wireframes, and making UX decisions when you’re busy on other (higher) priority projects or when a pinch decision needs to be made in order to move forward.
For example, dozens of little scenarios pop up when building a UI, especially if it involves a picky third-party API. No one is going to be able to quickly understand these issues and resolve them like the engineer in the trenches building the UI. You need to know that the engineer will make the design decision that’s best for the user.
Create opportunities for “targeted collaboration.”
It’s easy to work in a vacuum, but you need to create opportunities to invite teammates into your process. It will help you make allies, communicate and teach UX thinking to others, and help you brainstorm solutions for any design problems you’re having. Most importantly, your teammates will help you validate or challenge your current design thinking.
If you’re hesitant to bring outsiders into your process or if your team’s bandwidth is too limited, try this: flesh out your design 90% of the way, until you find those final few interactions you’re getting stuck on, and then invite some stakeholders to help you figure out that last 10%. This targeted collaboration makes the best use of everyone’s time while tackling the toughest design problems. Paper prototyping (I’ll get to that later) and card sorting are powerful and quick collaboration tools for this purpose.
#4 – Keep a Working (Whiteboard) Sketch
High-fidelity sketches are powerful ways to share and review designs and prototypes.
We work in what’s almost a completely digital industry. Our process is a long chain of digital documents that we pass between team members. Sketches are novel in that they are a physical artifact that viewers interact with off screen. People understand ideas better when they can point and touch and gesture, and a paper sketch’s physicality aids the kind of kinetic learning that fosters better understanding.
High-fidelity sketching is an important part of the process that your team expects.
Ideally (there’s the “i” word again), you can invite your teammates to brainstorm with you early in the process with some low-fidelity sketching. But in most cases, it’s just you, huddled at your desk, ripping through notebooks and sticky pads in a fever brought on by too much coffee and Sharpie fumes.
If that’s the case, it’s important to still share the final outcome of that process in the form of a higher-fidelity sketch, whether it’s on a fat piece of paper or a whiteboard. Low-fidelity is great for “thinking out loud” about an interaction, but once you’ve settled on your path of execution, take your time to carefully render it.
For some tips on improving your hi-fi sketching, check out Peiter Buick’s Smashing Magazine article The Messy Art of UX Sketching.
What should it look like?
Your sketch should be editable. Whiteboards work especially well. A whiteboard is large enough to allow a group of people to gather around and discuss, and it’s engaging and interactive. It also lets you command-Z in real-life, until your sketch is finessed to your liking.
I’m a huge fan of using paper, Sharpies, scissors, and sticky notes to create paper prototypes. These materials are great because they’re cheap on time and money, they turn reviews into interactive experiences, and they make it easy to quickly re-organize the layout of the UI based on feedback. Check out Shawn Medero’s canonical article on paper prototyping in A List Apart. Building a paper prototype is also a huge boon for simple usability testing, which is a great segway to my next topic.
#5 – It doesn’t take much to test
It goes without saying that usability testing is hugely important to the UX process. Some experts even go so far to say that a product hasn’t been truly “designed” until it’s undergone usability testing. I’m inclined to agree. But what “they” rarely say is how much of a time-sucking ordeal it can be to do it thoroughly. You need to write the script, find suitable testers, prepare a space, pick session-recording software, plan how you’ll interpret the data, pick out the snacks you’ll provide – oh and you have to fit it into your next sprint before the scheduled review.
Luckily, you can get great feedback without making the usability test into a big deal.
First off, you really only need five participants to get quality feedback, according to Jakob Nielsen in his immensely useful article How Many Test Users in a Usability Study?. Any more than five, and the feedback you get back starts becoming repetitive. Any critical flaw in your design thinking will clearly reveal itself during those first few tests.
Getting your sample of five participant can likewise be headache-free. “Starbucks testing” is a recent trend where a designer sets up shop for an afternoon in a coffee shop and recruits patrons for quick usability tests in exchange for a cup of coffee.
In the case that your product is a little esoteric or comes with a steep learning curve to non-customers, try doing internal coffee shop testing in your office. For a recent project at Media Temple, I recruited five users from a few non-engineering departments like marketing, sales, and HR, and conducted a series of fifteen-minute usability tests on my laptop using a prototype I built with InVision. The control panel in question was technical enough that a random patron’s feedback at Starbucks wouldn’t be helpful (we’re based in LA, not Silicon Valley), but I rightfully assumed that anyone within our company would be literate enough in web hosting to provide valuable insights.
UX is a messy process. You have lots of stakeholders to deal with, lots of moving parts, and above all, your own desire create a solid product up to your standards
The perfect process isn’t developed overnight, especially if you’re the sole UX practitioner or new to the practice. But just like a product, it’s important to evaluate your UX process and work to constantly improve it. Look back at your last product release and ask yourself:
- Do the product’s interactions need work? Take note of what works and what doesn’t at the end of each iteration and include UX improvements in the next sprint.
- Did all the stakeholders understand your vision for the product? Improve understanding with a visual aid like a whiteboard sketch or paper prototype. Or include your teammates in a session of targeted collaboration.
- Were people unsure of how a product is supposed to work? Try getting everyone to endorse user stories as the source of truth for your team.
- Need to do more user testing? Grab five people from around your office, offer them coffee, and conduct some quick usability tests.
I also highly encourage you to check out Leah Buley’s fantastic and relevant book The User Experience Team of One, written for solo UX practitioners.