GoPro’s UX Design Team
At GoPro, we have a big design organization that spans hardware and software. Our team has UX researchers, UX designers, prototypers, UI/UX designers, and content writers.
Our UX designers tend to focus more on the earlier stages of the design process, such as helping to shape and interpreting business requirements and user insights, creating interaction flows and wireframes. We work very closely with product managers and user researchers to define the user problem, question why we’re designing something in the first place, help prioritize features, and keep everyone honest about the design or feature goals at all times.
Our UI/UX designers are more on the visual design side of things so they’ll focus on the visual polish, fine micro interactions, motion transitions, and things of that nature. They take the design to its final stages and work closely with developers around the implementation stage. They also define the visual language and develop our style guides which is hugely important to us given our product line is growing every year.
Our UX researchers are the gatherers and guardians of user pain points as well as leading generative research efforts. They are also well plugged into the various product roadmaps and help product teams balance and prioritize any new feature requests or changes against the backlog of known user pain points that need addressing too. At the end of the day, everyone’s going to have a new product idea or an improvement idea, but the UX researchers keep us all honest about addressing actually known, important user pain points and user problems specific to our products.
Another integral part of the UX team at GoPro are our content writers and prototypers. Besides continually defining the GoPro language and making sure all texts are easy to understand to humans in a growing number of languages, our content writers also help us optimize UX flows. Our prototypers help us bring the more advanced interactions and product ideas to life either for user research purposes or for stakeholder reviews. Mind you, we also prototype with our developers directly in working code. It depends, really. All UX disciplines work very closely with the product, development and QA teams. We are all mostly co-located or at least in the same time zone, which makes collaboration like that much easier.
Balancing proactive and reactive research
You often hear about research being seen as a product development bottleneck, where research — such as user testing — is being done reactively at the final stages of launching a product in the middle of the inevitable organisational madness.
Ideally, you want to balance well-timed generative research with frequent and regular user testing in your organisation’s product development lifecycle. That way you can discover user pain points and opportunities early on in order to help inform the product roadmap in the first place, then use usability testing methods to continually check the product development process is headed in the right direction.
It is helpful for researchers to join meetings that involve sprint planning, backlog grooming, and strategy development for your product roadmap.
Showing stakeholders the value of UX
Earlier in my career, when I was working for agencies, some clients didn’t see much value in spending time and effort (read: money) on user research. On one of these projects we’d be working on a 2-week sprint basis without any user research done whatsoever.
We felt challenged to think creatively about how to inject some user validation without adding any more to the project budget. We came up with a light-weight but thorough agile testing method, mostly unmoderated, similar to usertesting.com, that would feed results directly into the sprint’s design output. Sometimes we would even manage to get two rounds of validation within the given sprint.
After a necessary period of fine tuning this process we developed it into a reliable vehicle to drive client discussions around design problems. So, sneakily like that, we got the client involved in UX research without even fully realizing it at first. It took only a couple months before it felt obvious to the whole team, including the client, that we should always be doing this, as the just-in-time user validation insights were invaluable. And it was still on budget!
What do designers schedule their work around?
At GoPro, we, of course, are trying to do agile, or a flavor of agile. Every company is doing a flavor of agile, obviously. *Laughs*
As such, UXers will attend a lot of the usual types of agile development meetings to ensure good flow of information around the cross-functional product development team. These meetings give people a good understanding of release schedules, what goes in each release, what the various delivery deadlines are, etc. Aside from meetings, we use Wikis, roadmapping software and physical artifacts on walls or TV screens that further communicate all of that.
On top of that, we have design-specific reviews, ideations, and critique sessions. As in just about any other company, though, we’re trying to strike a balance and not overdo it with meetings to ensure that designers have enough time to get into the “zone” to produce standard UX deliverables. For example, we experimented with blocking off about 4 hours of “do not disturb” time every day in our calendars. It worked pretty well.
Communicating with engineers
Early on:
It’s never a bad thing to over communicate. It pays dividends to get buy-in from the whole cross-functional team and act preemptively by getting the goals and requirements of the project across to everyone. You can’t just hand off a finished comp to developers and QA engineers out of the blue, without context. Instead, create meetings to review designs and have cross-functional team members poke holes in them.
It’s even better if you can get everyone (or key representatives) around a whiteboard, ideate with them, hear their suggestions, and have the chance to explain your design rationale, constantly referring back to the given user problem and established design principles. As you build trust and rapport with your team this way, you will find that there will be fewer opposing design opinions or specs that are not implemented the way they were supposed to be.
Throughout the process:
There’s always going to be things that fall through the cracks. What we do to try and minimize this is we engage in regular UX QA bug scrubs at the right times in the release schedule and assign them severity and priority ratings from the UX perspective. Those are then negotiated in the context of “standard” bugs with the rest of the team.
Sometimes, we find it more efficient to directly sit with developers in an informal session where designs are being implemented in real time, simply because there can sometimes be gaps in specs or specs can sometimes be open to interpretation. Maintaining good rapport with the rest of the team is really important so that you have a way to casually bring up any design intention discrepancies and deal with them earlier, rather than later.
Crunch time:
Be prepared to vocalize the importance of fixing a “UX QA bug” if you have arguments or, better, data showing it’s critical to fix it before we release. Even when there is a mountain of difficult technical bugs that need fixing as well. The UX team at GoPro has the right to stop ship in those scenarios. I hope yours does too. At the same time, you do need to pick your battles. Sometimes you just need to push your precious UX QA bug to the next release.
Everyone will have a design opinion
At the end of the day, a designer’s or researcher’s role is to be a good facilitator; to open up a conversation and create alignment in the cross-functional team around the user’s needs. For example, we use the early meetings around planning a new initiative or an upcoming release to dig deep into the business requirements (or user stories) to understand why we should be creating a particular feature and whether it’s the right solution to the given problem. In these conversations UX designers facilitate the development of the experience goals and core principles of the solution so that everyone on the team stands by them throughout the development process.
This way, in any subsequent discussion on design decisions, you’re able to refer back to the core principles that were agreed upon. It’s not enough to rely solely on this, though, so you’ll also always want to conduct user research to further test the hypotheses you’ve so carefully come up with together as a team.
Tips for New Grads
- Attend networking events, meet professionals out there and share your challenges and perspectives with each other.
- Try and get a mentor in your field. Meetup groups are a great place to look for them. Contact the groups’ organizers about that.
- In London, where I moved here from, I see a lot of young UX professionals who often stay in a company for only a few months, max one year, before they move onto the next thing. You can see that to some extent here, too. I always wonder how one can really get the experience of going through the full cycle if they skip some of its phases. How can you really see if your designs worked? In this sort of job hopping, I think you’re actually robbing yourself of the opportunity to learn, grow, and make an impact in a company. This can lead to superficial work where designers focus more on the appearance of their work, rather than seeing if their design solution was actually implemented, used by customers, and solved the right user problem. Our line of work doesn’t bear fruits immediately. So my advice would be to have a little patience and keep at it.
SDXD events
I’ve enjoyed the hands on SDXD workshops with people from different backgrounds the most. For example, the event last year where a lawyer presented on negotiation. I like that the workshops are tangible with takeaway points you can act on in your organisation. I feel like one of the main challenges for modern UX designers is to become true leaders in their organisations so events focusing on that have been great. More of those, please!
SDXD: Jakub Uradnik, Senior UX Designer at GoPro was originally published in SDXD on Medium, where people are continuing the conversation by highlighting and responding to this story.