With a career spanning 25+ years, Jeff Veen’s experience has spanned design, business, and venture capital.
He’s lead design teams at WIRED, Lycos, Google, and Adobe. He’s co-founded three successful companies: Measure Map (acquired by Google), Typekit (acquired by Adobe), and Adaptive Path (acquired by Capital One). Now, he’s advising startups (like us) on design and product strategy as a Design Partner at True Ventures.
We figured he knows a thing or two (or many, many more) about how to practice design successfully in an Agile process. So we sat down with him for an hour to learn from his experience.
From hybrid processes to conducting user research and running retros at scale, here’s his most useful advice.
Want more practical advice on Agile UX? Download the new Definitive Guide to Integrating UX and Agile.
You founded Typekit, lead teams at Google and Adobe, and now work in venture capital. How do you balance UX with Agile?
I’ve seen a lot of different methodologies come and go, or come and merge.
We adapted practices from Extreme Programming, Agile, and Lean Startup (which I think is an evolution of both of those ideas). We didn’t follow “agile with a capital A”, but just treated it as another inspiration for our hybrid process.
The most steadfast “rule” was that every single person on the team is doing UX, whether they’re a back-end developer, front-end developer, or designer. A Database Engineer is just as important to delivering the end-user experience as a Visual Designer.
To make that hybrid process work, we found it helpful to merge the UX and development team. I just made one team and said, “You all have different roles towards making the best possible product, now let’s follow a design process that works for all of us.”
For example, our daily standups weren’t by the book at all. If you read the books about Agile, you’ll find lots of discussion about tacking index cards up on the wall and moving things around. I don’t really do a lot of stuff, but I love the spirit behind checking in every morning to gauge progress and morale.
Once our teams grew, we scaled the format to accommodate size (sometimes 40+ people). You don’t have ask every single person, “What did you get done yesterday, what do you want to do today, and what’s blocking you?” Instead, you can appoint key people who have emerged as leaders in the organization to report out on these answers so the format is more “Here’s what’s happening in our company and team”.
Then, as a leader, you’re better able to see if there’s energy here or if you need to dig deeper into problems.
Was it hard getting buy-in for that more hybrid design process?
It was definitely more challenging for companies that were still following a waterfall process.
For example, you go to a place like Adobe, which is really entrenched in an org chart with separate disciplines and everybody is centralized around their discipline, and engineers with years of experience will say, “Would you just please give me a mockup, so I can go build it?”
That can be really challenging. To get buy-in for a more hybrid process, I would always try to show progress by tackling smaller projects for quick wins. That way, others could immediately experience the improved process versus what happens when a design team is battling priorities from a department that has nothing to do with the current product.
What do you like most about those different methodologies that inspired your design process?
Shifting the thinking so that every technical project must be rooted in an identifiable user need.
The other part I liked is that Lean, Agile, and Extreme Programming are all structured around momentum. And that means going fast, doing small amounts of work, and launching as quickly as possible so you learn from the real world.
That turns a design process into a much tighter prioritized set of goals. Instead of designing a complete architecture and launching all 150 features at once after 6 months, we launch two things next week and learn how to immediately improve.
Once you’ve shifted that mindset, it’s so much easier to follow a flexible process based on the project needs. Everyone ends up feeling good about their work, they’re getting constant feedback, and they’re shipping quickly as opposed to these death marches towards giant releases.
What pain points did you face in your hybrid design process?
Flexible methodologies are always difficult to introduce to talented people who are already well established in their career.
When I describe this hybrid collaborative process, a lot of people can believe that it sounds like a waste of time and we should spend that time coding. You need to build trust in the team to say, “Look, we’re not typing at our computers for the next week, we’re doing work that helps us understand the problems we need to solve”.
On the other side of the coin, going fast all the time with sprints can be frankly exhausting. It’s like you’re sprinting through a marathon. Leadership needs to regularly gauge the overall sense of fatigue in a team.
Sometimes we needed to go a little slower and we planned a few sprints to pay back the technical debt we accumulated from moving so fast. You need those “payback” sprints because you want the team to feel satisfied with work that reflects their reputation.
For this hybrid design process you tried at Typekit and Adobe, how did you decide who was the product owner?
We always designated one person as the product owner, but that person wasn’t a pure product manager.
I tend to look for product management skills in developers and designers or even user researchers. For the product management and product owner role, I find people are more successful if they first have a strong background in a design or technical role and they’re shifting to this role for more influence over the product.
At Adobe, a lot of the product management were MBA types. It’s not a bad thing at all, but their method of working was around developing models, spreadsheets, and Powerpoint decks. Very little user research involved. They would examine problems like “What’s the total addressable market, and how do we achieve that?” Those questions are totally important, but your method of achievement must be based in user-centered design.
Therefore, in order to capture that market share, you need clearly designated product managers and product owners with a solid grasp of UX.
Jeff Veen at Adobe in 2013.
How can enterprise designers better sell the value of user research in an Agile process?
You can use some sleight of hand in the beginning of a project, and say “We need to work on all these big things. We need to develop some kind of overall architecture. We need to choose a technology platform. Oh, and we need to do a bunch of customer research to make sure none of that goes sideways.” You place user research in the same category of upfront work as technical scoping.
You also frame the research in a way that generates revenue.
When working at Google on their analytics and Adwords platform, I said “Look, we have to talk to people paying for AdWords and find out their reporting needs so that we can help them spend more money.”
As a result, we spent our first few sprints (a couple months) diving deep into understanding ad spending, online marketing, and publishing efficacy of customers.
We met with hundreds of potential customers in the agency world and in-house teams at large companies. When you listen to even 20 people with the same job talk about their role, and you visit their office and you see the sticky notes on their monitor and all the other workarounds, you see a ton of trends emerge. You analyze the transcripts of all of these interviews and say, “This is a task, and this is a task they do, and this is a task.” Group the tasks together and you’ve built a solid mental model and product architecture.
All without coding anything or designing any screens.
On the other end of that spectrum, how did you fit user research into the the process you practiced at Typekit?
Same approach. We did two large research sprints upfront to learn about web designers and people who design and sell type for a living, then continued to follow up throughout the process.
In the beginning, my cofounders and I would spend 30 minutes at a time interviewing a total of 40 users (Skype, coffee, etc.).
From those interviews, we learned about critical issues and had plenty of source material to adapt the rest of our design sprints.
At Google and Typekit, I didn’t write up a research brief with a protocol and a structured plan. I just told everyone “No, I should go talk to as many people as I can to figure out if I’m going crazy or not.”
In this hybrid process, did you run post-mortems and retros on a regular basis? If so, what format did you find successful?
We ran post mortems and retros all the time.
That’s incredibly important for freeing everyone up to be creative. You don’t look for blame or credit, but simply “What did we learn from what we just did”.
For each post mortem or retro, someone on the team was tasked with investigating the situation and returning with insights. They’d share them with the rest of the team for alignment, and then we’d dive right in after the morning standup.
The “investigator” would share the vetted results with the team, then we’d start an open discussion based on the 5 Why’s of Lean Startup to dive into issues discussed. We kept the post mortems and retros short and focused to prevent them from becoming a complaint session.
And of course, during post mortems for projects that failed, leadership needs to identify the circumstances, not the attributes, of the people involved.
What would your ideal design process look like?
I’m not quite sure I have a perfect process because there’s no perfect team.
The most important thing to remember is that a team is just a collection of humans. Humans have some combination of rational thoughts and emotional responses to everything. And every process must account for that particular blend of rationality and emotions.
Here’s the three key elements crucial to any design process:
- A deep understanding of the people on your team.
- From that comes culture, a clear mechanism for communication that everybody buys into.
- That culture encourages a sense of momentum in which everybody feels like progress is happening and they’re thrilled everyday to see the product get better and better.
The best process is a flexible process. Steal the best techniques from multiple methods, then adapt them to the context of your product and team.
That approach always scales over time.
What collaborative tools do you think help facilitate Agile UX?
I’m a huge proponent of any tool that facilitates collaboration and communication across teams. I’ve seen the power of this when working in highly productive teams who embrace tools like Slack or Trello or Asana.
But what I’ve been most interested in lately are processes and tools that encourage collaboration around design artifacts – the files that designers use to communicate their interface solutions or interaction flows.
As an investor, that’s where I think UXPin really shines: it allows not just teams, but whole organizations to seamlessly work on designs without emailing around images and haphazardly collect feedback. It’s super efficient and organized, and I think more and more Agile companies will be embracing this type of design-centered collaboration in the future.
Want more advice and case studies on Agile UX?
Download the 99-page Definitive Guide to Integrating UX and Agile.