Let’s start with some assumptions. Most organizations want customer/user feedback; many want more of it than they’re currently getting. Among these organizations, there are many obstacles in getting from current state to desired state. To wit: What sorts of feedback should we be soliciting, what research methods should we be employing? Who should manage this research and how much time and effort will it take? How do we even do all of this in general? How do I prove the value of this fuzzy qualitative stuff? What about coordinating with all the other teams that are either actually, or wanting to, talk to our customers and users too?
There are a lot of questions and unknowns that can stop organizations from being the customer feedback and user research focused companies they want to be.
Jeremy Pallai has helped devise some pretty compelling solutions to these kinds of scenarios at Vistaprint, where he leads several product development teams, including Hatchery, an innovation lab there.
Forge is a program launched about a year and a half ago. Any team at Vistaprint that needed the product development services of Forge—stakeholder interviews, user research, ideation and prototyping, testing, a final idea—could request them.
Forge was a kind of side project consisting of Vistaprint designers, developers, product managers, and analysts who would join on to another team’s sprint and run them through the process. If you’ve read Sprint you’re familiar with a similar framework. The Forge team would:
1. Do internal discovery to determine what stakeholders really needed to learn to move the project forward
2. Interview subject matter experts, front line employees who had real day-to-day experience with customers and the areas of focus.
3. Emerge with 4-6 quite different ideas. Ideas could come from designers, developers, anyone on the squad. This is a huge benefit of working in these cross-functional teams.
4. Interview 5-10 customers and prospective users to talk about each prototype and perform important tasks the prototypes were meant to achieve.
5. Provide the team requesting its services with a strong direction to start implementing.
The team Forge is assisting remains close to the process along the way. The website the Forge team has put together is very helpful in making that happen.
Want more content like this?
Sign up to get our weekly newsletter
+ a PDF copy of this report.
The Forge website is a key tool for recording the process from start to finish, sharing insights, prototypes, discussions, and more within and across teams. Below are just a few examples of what this might look like.
Another core benefit of the web experience is forcing teams to articulate the process and findings, helpful in itself for distilling insights and determining the best solutions for users and business stakeholders alike.
Forge does not exist to permanently augment other teams in the org. Instead, it helps train teams to do the work they do by running them through the process once. Then, they have the basic tools they need to do it themselves.
Like many companies these days, Vistaprint’s product development teams are built around autonomous squads. For squads to actually work as autonomous units, they, of course, need to have all the vital skills to build products. Research is becoming an increasingly vital part of that for many of today’s top tech companies, and embedding that function throughout these squads is vital to making the whole thing work. The “teach a man to fish,” approach employed by Vistaprint may serve as a model to other orgs looking to get away from, or supplement, an overburdened centralized resource.
Ultimately, Jeremy shares that often folks can think moderating a study is really complicated, “but really it’s just having a conversation with another human being.” A lot of making research successful in an organization is simply getting over the fear of talking to your customers, and doing it.
Want to contribute to User Interviews content? Here’s how.
Get "Fresh Views," our weekly newsletter, delivered to your inbox. We feature interviews and point-of-views from UXers, product managers, and research nerds of all stripes.Subscribe
Sometimes, to learn how to do better UX research, you have to fail
Become more childlike to unlock deeper insights