“Ask Me Anything” with Dan Brown and Designer Hangout
Author of “Practical Design Discovery”
Dan, thanks for doing this AMA! I’m curious about some techniques on selling design discovery projects, especially because we don’t always know the solution until we do research. Help?
One notion I’d like to dispel: Discovery is not just research.
Discovery is a process of filling gaps in your knowledge, and arriving at a better understanding of the problem as well as a starting point for your solution.
Thinking of discovery as distinct from design will definitely make it harder to sell. Instead. I position discovery as part of the design process, our methods and tools for setting the stage for detailed design.
I’d like to hear some tips or a starting point for huge product redesign efforts. What’s a good way to get a handle of the stories and requirements for design when a client just has a big, existing complicated product and expects the features to be more or less the same, but doesn’t have the functionality documented very well.
Get the team together and do a prioritization exercise like KJ analysis.
When I face big problems like this I ask myself two questions:
1. How can I break it down and surface priorities.
2. How can I get other people to help me do that.
Check out the book Gamestorming by Dave Gray, Sunni Brown, and James Macanufo for some helpful workshop recipes.
By nature generative research can sometimes just validate previous assumptions from the team. How can I defend the future user research projects and ensure stakeholders that our assumptions will not always be met?
I’d love to have the problem, “You’re always right, why should we pay to make sure you’re right!”
I position my work as facilitating a process. The process requires us to validate assumptions. Most organizations don’t want to take these kinds of gambles.
How do you see Design Discovery working in an agile environment? I’ve experienced the pain of designing something, then learning something new and having to change it (because it was obviously flawed, but we didn’t learn that until later). How can you handle this when you simply won’t be given the time to conduct upfront research? For us doing one observational usability testing study takes at least 3 weeks, so we’re already not fitting into a 2 week dev sprint.
Agile is a way of organizing work. Discovery is a mindset. These two things aren’t incompatible. I’d hope you can work with your team leads to dedicate some sprints to learning, or refactor the design scope in a sprint to incorporate some quick research.
Recruiting and testing tools are (a) inexpensive and (b) much faster these days. (I’m a big Optimal Workshop fan) such that getting feedback on design work should be compatible with even fast cycles.
But Discovery isn’t just feedback. I’d hope that you can take time in each sprint to reflect on what you learn about your target audience (filling gaps in your knowledge) and using that to feed subsequent sprints.
On redesign projects for long-term clients, I’ve encountered this sort of push-back from them: “Why do you need to do discovery? You built the original website X years ago.” How do you respond to clients who are hesitant about discovery phases because they believe your agency should already know everything about their website?
Classic. If they’re really hesitant, then you can perhaps suggest a “baseline study”:
Let’s see how the site is performing today so we know what we need to improve.
I like some of the other suggestions, but sometimes taking a big picture approach seems to abstract and overwhelming. A baseline study is quick and cheap and gives you an opening to talk about how things have changed.
Can you share an example of when a successful Discovery made all the difference?
Careful. There’s no “counterfactual” of a project without discovery. Whenever you’re engaging in design, you’re doing discovery:
- engaging your curiosity to fill gaps in your knowledge;
- beginning experimentation to see what works and what doesn’t
Just because you don’t call it that doesn’t mean it isn’t discovery.
The real question is whether there’s a noticeable difference in whether formalized (or structured) discovery is appreciably better.
One reason I like to distinguish discovery from the rest of the process is to remind people that it’s OK to experiment, it’s OK to think of things as in-process.
What are some common deliverables after a Discovery session?
Here’s my article on documenting design discovery:
That said, I think you need to take the pulse of your team: what do they need. You’re documenting for posterity, but also to inspire your team, to inform the design process. What works for them?
I’ve been doing a lot of posters recently because there’s something satisfying about putting this work up in a public space.
But I’ve also just left things in a messy Google doc, too.
Hey Dan! So on the same thread of facilitating the process, there have been a number of articles and thoughts popping up as ‘everyone is a designer.’ Care to share your thoughts on where you’ve had/seen most effective collaboration? And what they’re doing that is really working?
I’m meh on labeling people. Let’s just leave it as “design processes are better if they integrate multiple perspectives.” Otherwise, you get into the business of defining DESIGN.
I was a philosophy major, but even I think that can get tiresome.
Designing Together (my second book) is all about effective collaboration. I believe that great collaboration rests on many things, but here are a few off the top of my head:
- well-defined roles, so people know how they contribute
- an accountable lead
- effective communication channels
How should Discovery-based work and longer term strategic thinking be prioritized against more tactical, immediate fixes that don’t necessarily solve longer term problems? Is there ever an instance where strategic work gets a higher priority than tactical?
This is a great question, and I don’t have an answer. I’ll speculate a bit though…
I believe organizations need to do both well, and they need to understand when to engage one vs. the other. Too often we’re conflating them when we ask, “How do I do research in an agile environment.” The answer is far too nuanced for a one-size fits all approach. What kind of research? For whom? Why agile? Etc.
I’m largely inspired by Dan Kahneman’s Thinking Fast and Slow. I believe there’s a good parallel to the organization. In some cases, the organization needs to churn shit out. In others, they need to be deliberate. This equates to the different parts of the mind explored in that book.
It’s a shame that organizations feel like they need to do either-or. Their resource planning should accommodate both. Short-term losses by taking resources away from the “churn it out” are offset (surely!) by the long-term gains of having a good plan, an aligned team, and informed decision-makers.
Here’s how it should/could work, at least on paper. An organization has a backlog of questions/hypotheses. Some of these are pretty small, perhaps related to a product UI or the desire for a new feature. Some are big: what are the major changes we should be considering.
The organization prioritizes all of these things, both big and small (slow and fast) and establishes processes for tackling both.
Any tips on how to integrate people from other departments into the design process? Or when to bring other people in?
If there’s reluctance, just keep it small.
“Can you take a look at this screen I’m working on?”
Start to creep in more and more involvement: “We’re holding a design studio, and I could really use your input. It’s easy, and only two hours.”
You can’t build design-involvement over night. You can’t build Rome in a day. (I invented that phrase, by the way.)
What about integrating developers into the UX research process? Any tips for convincing PMs and their devs to participate since it takes away from their regular coding duties?
Any organization that doesn’t see the value of having devs sit in on a user interview or two probably doesn’t have user focus as a value.
This seems rare these days, but perhaps people still run into it?
Is there a simple approach in terms of phrasing that you’ve used and it’s worked effectively. Any advice on how to have a smooth design hand-off to dev? We’ll send over the final design files and a doc covering all user flows and functionality. Things usually get missed from the doc or mockups and I end up helping out during the QA phase to review and ensure everything is right or it’ll get pushed up and I’ll have to make notes for fixes later on.
Part of me wants to say, “That’s the design process.” If you’re not going back and forth, then something is broken. Design depends on iteration, on review, on feedback, on conflict!
But it also might seem like that feedback comes too late. One of the great things about modern software development is that we’re all more comfortable with doing things incrementally. Don’t wait until you’re 80% done to show something.
I look at these situations as “how can I change my behavior to get a different result.” It doesn’t work with everything, you know? There are some corporate behaviors that are so ingrained, but I believe we’re all empowered to make small changes.
I worked in the federal government for years, so I’m familiar with taking baby steps against the bureaucracy.
Do you think discovery should be an ever-present item in the backlog?
I think that’s thinking about discovery all wrong. Discovery isn’t a distinct thing like a feature: it’s an aspect of the design process.
Instead, look at the things in your backlog and ask yourself: Do I know everything I need to know to design/build this thing? What assumptions do I need to make to get this done? What risks do we face working with incomplete knowledge.
Right, and as a designer I agree. But when trying to have everyone involved in the design process and getting transparency out there, do you think there could be value in that sense in adding it? My thoughts are if speaking in the “language” that certain players are used to, it could be a better catalyst for adoption.
I think adding a column to your backlog that says, “Needs discovery” may be worthwhile. Does your confidence (or lack thereof) in your knowledge factor into how you prioritize?
I like the direction you’re going in. I’m talking out of my ass a little because I haven’t seen a single organization do this well.
I’m currently in a very young department of a larger organization trying to champion a process and gain adoption from all the players, so In my particular projects I do factor understanding. But I’m a small piece of the larger puzzle.
What would you say are the main things getting in the way of adoption? Is this lack of comfort? Lack of familiarity?
I would say lack of knowledge and familiarity, with a sprinkle of management on-top.
I’d love to hear more about your org, but I suspect that’s a convo for another time. One thing I’ve done is look for friendly faces–people who would support some of your efforts. Lean on them to create some positive outcomes that you can then sell around the organization.
Honestly, we could do a whole AMA on just that. Though we’d have to call it something like You Can Ask But No One Really Knows. YCABNORK. I guess people just call that a discussion.
I’ve been doing conferences and workshops for years. The discussion always comes back to organization change.
I find it fascinating that as long as this business has been around, many of us face the same kinds of obstacles over and over.
Perhaps the details change, but the challenges remain: How do I get my work to align with the organization? How do I get my work to align with another person’s?
You’ll hear a lot of UXers complaining about agile and other new software development methods. If I’m being honest, I can’t say that I completely understand how they work. But I do appreciate the attitude behind these approaches: Do a little at a time; Break down communication barriers; Indulge your curiosity.
How do you make baby steps against bureaucracy with a big time constraint?
A couple things that keep me going:
- Can I make one small positive change? Even after a big project, there’s no way I can make a dramatic change to the organization, but perhaps I can make one small change. Perhaps it’s getting the dev team to work a little more closely with the design team. Perhaps it’s getting them to see the value of user research.
- How does this help me grow as a designer? Take it out of the context of the organization, which perhaps you can’t change. You can learn, however. So I ask myself, what’s one thing I can take away from this experience?
Dan, I’ve repeatedly found that design outcomes are (sometimes unfortunately) tethered to executive decision making. What are some of the best ways you’ve learned to work with non-designer corporate executives? I’m curious what brilliant leadership can look like on both sides when that’s done well.
To be clear, you mean that design decisions are ultimately up to an executive, not the design process?
As an outtie (working at a design agency) I rarely encounter this. I’m brought in to serve as an outside voice influencing design.
That said, I’ve often been brought in when the internal team has a preconception of what they want, and I’m just there to rubberstamp their ideas.
So, I like to clear that crap up right in the beginning, asking questions like:
- What’s my role here?
- What are your expectations out of this process?
- What factors influence your decision-making?
On my end designs are made to accomplish the user issue or problem, but then functionality added to make it easy to use are deemed as ‘nice to haves’ by stakeholders, not added into MVP then never get done. How do you add value to the small items?
I just wrapped up a big intranet IA project. It was rough. Highly political.
At the beginning, the main business stakeholder said that LEGITIMACY was the most important thing to him. I pressed him on this time and again. To be fair, he was very cool about it.
There are a few directions you can go as you think about this stuff:
- Design ROI (an evergreen topic that is wholly unsatisfying)
- The role of negotiation in design (I’ll give you this if you give me that)
- The co-opting of design by business (“design thinking”)
Is it not enough to show upper management how the design will increase profit? Or is there way more to it that a designer needs to convince them of?
The challenge isn’t the profit: it’s the cost-benefit. Can you increase profits the same amount by doing less research? Less brainstorming? The problem is that some of the benefits (cohesive team, increased user knowledge) aren’t quantifiable.
Dan:
Friends! It’s been real! You asked great questions. Hit me up any time on DM if you want to talk process or discovery. I’m going to leave YOU with three questions:
What can you do right now to speak for the user?
What assumptions do you maintain about your users that you should try to validate?
What’s one way you can help your fellow designers and give back to the design community?
Thank you NomNom for partnering with us and giving away copies of Dan’s book!
Care to weigh-in? We are looking for honest uncensored advice that can help the current and next generation of UX professionals advance in their practice. The results will be shared in a series of blog posts with analysis and quotes from this survey.
