Rosenfeld Media Announcements Blog

  • UX in all the Odd Places

    Posted on

    I had a bit of a crisis last fall. My pal Andrew Mayfield asked me to keynote UX New Zealand. Of course I was dying to go to New Zealand. But they wanted me to give a new talk, and the very thought makes me sweat. What new things might I have to say about UX? Do I even do UX anymore?

    After all, these days I spend my time putting out books and putting on conferences. Web sites and apps? Not so much. I’m not even sure I know the difference between a breakpoint and a touchpoint. So who am I to talk to UX practitioners about UX? 25+ years in the field, yet here I was, suffering from an acute case of imposter syndrome.

    Many false starts, meltdowns, and 4am Keynote sessions later, I finally had a breakthrough. It’s not that I don’t do UX anymore. It’s that UX applies to way more than apps and web sites. In fact, I’ve spent the better part of the last decade doing extensive UX work on traditional products, like books, and physical experiences, like conferences. So that’s exactly what I covered in my UXNZ keynote. Books and conferences are experiential, so yep: the work still counts as UX.

    D’uh. I guess it’s one of those oh-so-obvious observations that aren’t so obvious when they pertain to you.

    But it is a liberating feeling. And it’s renewed my excitement about UX, because:where doesn’t UX apply?

    Conferences offer almost unlimited opportunities to UX the hell out of stuff. With our last virtual conference—Product Management + User Experience—we found that basing our program on user research was immensely valuable, helping us select both speakers and topics. And many of you agreed; there was a strong correlation between your participation in program planning and your desire to actually attend the event.

    So we’re doing it again with our next virtual conference—Design Research for Everyone, which is slated for some time this fall. Here’s our question: What do people who aren’t UX practitioners need to learn about design research?

    Please help us do our user research by letting us know who should speak and on which topics—and sharing this with others who might be interested.

    What odd contexts are you finding ripe for UX? Please comment below; I’d love to hear your stories of UX in non-traditional places.

    We’re hiring: Events and Corporate Training Manager

    Posted on

    A couple years ago, more than a few people—including some of my staff—asked me why Rosenfeld Media wasn’t producing conferences.

    With a derisive hand-wave, I crabbed that they weren’t worth the bother. We’d tried a few things, and long story short, I didn’t see the value. “We’ve reached peak UX conference.”

    Well, when I’m wrong, I like to go big. Fortunately, those people didn’t listen to me and, in fact, persuaded me that the UX conference business was indeed worth pursuing. We’re about to hold our second Enterprise UX conference, which just might outdo our very successful freshman effort. We’re producing more virtual events (here’s an example), and we also organized our first Advance Retreat earlier this year.

    There’s lots going on here, and we need help. Not just with conferences, but with managing our business of connecting UX experts who teach courses with corporate clients.

    If you’re someone who strides event management, user experience design, and sales—or who thinks they could—let’s talk. Here’s the position description; have a look, and if it’s up your alley, apply by May 22. Hope to hear from you!

    New book: Donna Lichaw’s The User’s Journey

    Posted on

    thumbnail of The User's Journey coverIt’s book launch day here at Rosenfeld Media HQ! And somehow, we’ve reached the quarter-century mark: The User’s Journey: Storymapping Products That People Love is our 25th title.

    Other fields, like filmmaking, have long understood the importance of narrative structure. In The User’s Journey, Donna Lichaw brings that same line of thinking to UX, and demonstrates how storymapping really can help us design and test just about anything—from landing pages to product strategies.

    This last point is no exaggeration. For example, we were carefully following Donna’s advice when we developed last year’s Enterprise UX conference program. Thinking about story arc helped us make sure attendees had energy left over for the conference’s reception after an intense day of presentations.

    So, while I’m biased, I really do think you’ll benefit from reading The User’s Journey, regardless of what you’re designing. And, at 160 pages, the book is short and sweet.


    Get your boss on board and come to Enterprise UX 2016

    Posted on

    Hoping to attend Enterprise UX 2016? Need a little help convincing the powers that be? Here’s our contribution to the growing genre of “convince your boss” lit. But if you have additional questions or need more help, just let us know.

    Reason #1: You’ll get better at designing and researching in and for large organizations

    • Enterprise UX 2016 is built around four curated themes that magnify the conversation we’ve all been having in dribs and drabs: how to create better, more humane enterprise experiences
    • Our main conference program mixes a wide array of session types—two keynotes, twelve presentations, five workshops, four challenge sprints, and eight raucous short-storytelling sessions
    • Our advanced workshops are taught by acclaimed experts, and range far beyond design and research basics
    • Our speakers are amazing, ranging from design leaders at Honeywell, GE, Salesforce, IBM, and Intuit—to authors of the field’s most influential books, likeRise of the DEO, Service Design, and The Connected Company
    • We’re driving our speakers crazy by making them work—together—on their presentations months in advance

    Reason #2: You’ll be learning from true innovators

    • Our speakers are amazing, ranging from design leaders at Honeywell, GE, Salesforce, IBM, and Intuit—to authors of the field’s most influential books, like Rise of the DEO, Service Design, and The Connected Company
    • We’re driving our speakers crazy by making them work—together—on their presentations months in advance

    Reason #3: You’ll make important connections

    • A healthy mix of industries send their people; in 2015, large groups from Apple, Capital Group, Dell, Frost Bank, Google, Intuit, Qualcomm, Rackspace, and Salesforce attended
    • A healthy mix of industries send their people; in 2015, large groups from Apple, Capital Group, Dell, Frost Bank, Google, Intuit, Qualcomm, Rackspace, and Salesforce attended
    • About 60% of attendees hold mid- and senior-level positions—a uniquely high proportion for a UX conference
    • There will be no shortage of opportunities to mingle at the conference and reception

    …and Reason #4: 15% off with this code!

    Register with code 4REASONS by June 1 and you’ll get 15% off your pass. If you do, here’s an estimate of what the Enterprise UX 2016 will cost in US Dollars:

    • $1,186 ($1,356 after March 14): Two-day main program at 15% off (June 8-9)
    • $506 ($591 after March 14): Optional one-day workshop at 15% off (June 10)
    • $697: Three nights at Westin Riverwalk (at $199 for a city view + 16.75% tax);reserve by May 17 for discounted rate)
    • $100: Estimated meals and incidentals (we’re providing most meals)
    • $400: Estimated RT airfare from San Francisco or New York
    • $50: Estimated taxi to and from airport (we’re providing shuttles between the Westin and the conference center)
    • $2,939 ($3,194 after March 14): Estimated total for attending Enterprise UX 2016, including one workshop
    • The first Enterprise UX conference was a fantastic success—and we’re looking to top it in 2016. We hope you’ll be a part of it!

    Want to share this with your boss in print? Here’s a PDF.

    If you or your boss never needed these reasons, why not register now?

    Whose Job is User Research? An Interview with Steve Portigal

    Posted on

    Those of us who conduct user research as part of our jobs have made pretty big gains in recent years. I watched my first usability test in 1995 then spent a good portion of the 2000s trying to convince people that talking to users was an important part of designing and building great products. These days, when I talk to companies, the questions are less about why they should do user research and more about how they can do it better. Believe me, this feels like enormous progress.

    Unfortunately, you still don’t see much agreement about who owns user research within companies. Whose job is it to make sure it happens? Who incorporates the findings into designs? Who makes sure that research isn’t just ignored? And what happens when you don’t have a qualified researcher available? These are tough questions, and many companies are still grappling with them.

    So, I decided to talk to some people who have been dealing with these questions for a living. For this installment of the Whose Job is User Research blog series, I spoke with Steve Portigal, Principal at Portigal Consulting. He’s the author of Interviewing Users, which is a book you should read if you ever do any research on your own.

    You still don’t see much agreement about who owns user research within companies.

    Steve has spent many years working with clients at large and small companies to conduct user research of all types. He also spends a lot of his time helping product teams get better at conducting their own research. Because he’s a consultant, he sees how a large number of companies structure their research processes, so I asked him to give me some advice.

    What Does It Mean to Own User Research?

    “There are two aspects to ownership,” Steve says. “One is about owning the need. The other is about owning the actions where we build on what was learned in research. It doesn’t seem like there’s any perfect model for how research ownership works.”

    As Steve points out, the concept of owning research is much more complicated than a single ownership model can describe. At a minimum, somebody needs to determine which business questions should be answered. Somebody needs to figure out how to get those questions answered. Somebody needs to figure out what to do with the results of the research. It’s not often the same somebody.

    In fact, the different people involved in the research frequently are not even from the same department. Company org structures vary widely: researchers might be their own group or they might be part of marketing, product, or even engineering. The people requesting research and using the results might be product managers, ux designers, or marketers. That’s not even addressing the times when research is done by outside firms or by team members who aren’t trained in research.

    There’s a reason this is so confusing. Despite the fact that various forms of user research have been used to develop products for decades, the widespread adoption of user research in the tech industry is still relatively new. Steve says, “People have more dogmatic theories about best practices, but I’m seeing so much variety and so much iteration as people try to figure it out.”

    Hopefully with a few more iterations we’ll get a better idea of what works and what doesn’t. Although it’s likely there will never be one single answer. The best configuration may always depend on factors like company size, industry, and type of research that needs to be done.  

    Who Should Do the Research?

    Despite the fact that Steve is a highly experienced research expert who conducts research for clients, he’s very upfront about the fact that internal teams should be heavily involved with the research. Often they should be doing it themselves. This is one of the reasons he teaches people how to be better at research and why he wrote a book that explains how to interview users more effectively.

    Not every research study requires an expert at the helm. Quite a few products would benefit from having somebody on the main product team who could quickly get feedback or answers to simple questions. “Even a newbie researcher should be able to answer some factual questions about what people are doing or might want to do. They also have the opportunity to reflect on what assumptions they were holding onto that were incorrect,” Steve explains. “You’ll always get more questions to go with your answers, but hoo boy–it’s better than never talking to users and acting with confident ignorance.”

    There are some questions you’re better off bringing in an expert, though. “The more help you need in connecting the business problem with the research approach and connecting the observations to the business implications, the more expert help you need,” Steve explains.

    We should all know by now that things like usability testing make our products simpler and more intuitive for our users. There’s also a huge amount of information to help you run a basic usability test. But when you’re getting into some of the trickier questions around generating or validating business ideas–or turning early customer research into innovative solutions to problems, an expert can help guide the research process and make these complicated research studies run more smoothly.

    How Do We All Work Together?

    Of course, none of this answers the question of how we all work together. Steve feels like there’s not a single answer to this question, but it’s very important to decide this ahead of time so that everybody knows what to expect.

    For example, consider where researchers live in relation to the people who need insights to inform product design. When your company has expert researchers, they may be part of an in-house silo, embedded in the product team, an outside consultant, or some hybrid of any of the above. Wherever they come from, you should determine five things as part of your research planning process:

    • What do we need to learn?
    • Who are we going to study?
    • What will we do with the outcomes?
    • How are we going to work together?
    • How will we define success?

    A standard predictor of success is how much the client is able to join the fieldwork.

    “Negotiating these elements is part of what a good research person should be doing,” Steve says. “The team structures, the availability of stakeholders – these are all inputs.” In other words, there’s no one-size-fits-all when it comes to determining how research projects should happen.

    According to Steve there is one constant: “A standard predictor of success is how much the client is able to join the fieldwork.” And he’s right. The best type of research is the research that people use to make better decisions. The more involved your team is with conducting the research, the more likely they will understand and pay attention to the results.

    Learn More

    Want to know more about conducting research well? Check out Steve’s book Interviewing Users for practical, easy to use advice on getting more out of your research sessions. You may also like Tomer Sharon’s book, Validating Product Ideas Through Lean User Research, Practical Empathy from Indi Young, and my new book Build Better Products, which will be coming out in 2016. If you prefer listening to reading, try Steve’s podcast Dollars to Donuts.

    Laura Klein is a Lean UX and Research expert in Silicon Valley who teaches companies how to get to know their users and build products people will love. She’s a Rosenfeld Media expert and author of UX for Lean Startups (O’Reilly). Her newest book, Build Better Products, is set for release later in 2016. Follow her on Twitter or subscribe to her blog and podcast at Users Know.

    Product Teams – Who Does What?

    Posted on

    When we started talking about putting on the PM + UX Conference, the first thing we asked was, “What sorts of things should we talk about?” Since the folks at Rosenfeld Media are, not surprisingly, extremely user-centered, the obvious answer was, “We’re not sure. How about we do some research and find out what questions our attendees might have?” So we did.

    The most interesting thing to me was that a lot of the questions people asked boiled down to “Who does what on a product team?” This was curious. I mean, we’re all working on product teams or we’ve worked on them in the past, right? Shouldn’t we know what our jobs are? Shouldn’t we know what everybody else is doing? Well, yes! We should! And yet… when I started to dig around and have conversations with people, I got very, very different answers about how things really worked.

    That was odd. It turned out that, although we all have job titles like Product Manager or UX Designer, many of us have very different ideas about what it is that we’re supposed to actually do all day. Do designers talk to customers? What about PMs? Who decides what features go into a product? Who makes wireframes? Does anybody do usability testing? If not, could they please start?

    Like any good team faced with more questions than they started with, we did some more research. Ok, first we had a couple of stiff drinks. Then we did some more research. I was volunteered to lead the way.

    The Research Methodology

    I wanted to make sure that we hadn’t gotten weird data or misinterpreted the questions being asked- after all, it was a survey – so I conducted several qualitative interviews with PMs and UX designers in various sized organizations. I asked about what PMs and UX designers did at their companies. Incidentally, I also got a lot of “but the way we SHOULD do it is…” answers, but I was focused on reality for the moment. And reality seemed just as confused as the survey results.

    After talking to a dozen or so people, I decided I wanted to collect exactly what tasks were performed at different companies so that we could see how much overlap existed. To get as many data points as possible, I sent out a very simple survey asking people what their role was, which tasks they thought were performed by UX Designers and which tasks they thought were performed by PMs.

    I got dozens of responses from people on different product teams–mostly UX, PM, and researchers–and even some engineers, marketers, founders and managers. Of these responses, I got hundreds of different things that are being done by product teams.I am not exaggerating. It seems that PMs and designers are performing a dizzying array of tasks from generative research to making roadmaps to managing stakeholders to visual design.

    I got curious. Who on these teams are doing all of these things? Seriously, most product teams just aren’t that big, so how do they get hundreds of things done? Who’s got that kind of time?? I narrowed down all the responses by deduplicating things that were similar. I picked the things that were mentioned the most, narrowed it down to 73 discrete tasks or processes–which is still a LOT of things for a team to be doing.

    Next, I did a card sort: I asked people to review each task and tell me whether it was mostly done by designers, mostly by PMs, done about equally, or generally done by nobody or somebody besides these. I also said you could make your own categories for things that didn’t fit.

    I ran the card sort remotely using OptimalSort, which was handy, since that meant that I could gather a lot more input than if I’d had to travel around with a set of index cards and watch each person do the sort. It also made it a lot easier to categorize, and you’ll see in just one second why that was important.

    The Research Results

    82 of you weighed in with how things worked at your company. And, surprise surprise, there was virtually no agreement. I mean, there were a few similarities. Everybody agreed that visual design was done by someone in the design department (except for those of you who said it was done by outside people or people in marketing). And almost everybody agreed that roadmaps were made by PMs. Or by execs. Or by managers. Or by someone else.

    Oh, and nobody agreed about who was supposed to do user research, except that a lot of people made a category called something like “things we aren’t doing enough of” and stuck user research into it. So, that was fun.

    Here are a few of the things people actually agreed on mostly.

    What Are Designers Doing?

    Interestingly, there was far more agreement about what designers do than about what product managers do across companies.

    the top five design tasks


    Visual Design

    The most agreed upon tasks were things like visual design, design specs and style guides, image manipulation, illustration, and branding. Almost everybody agreed that these were mostly done by designers.

    The unfortunate part about this particular agreement is that, while it’s true that these are more “design” tasks than they are “product management” tasks, it tends to confirm the idea that many organizations still see design as limited to visual design.

    Visual design is almost always done by designers.


    Interaction Design

    It has “design” right there in the title, but 10% of the respondents said that interaction design is done equally by product managers and designers, and one sad person said that it’s not being done at all.

    Other Mostly Design Tasks

    Other tasks that were mostly done by designers were what you might expect:

    • Mockups
    • Wireframes
    • Sketching
    • Site Maps
    • Information Architecture

    Interactive prototypes were also very high on the list of tasks mostly done by designers, although at a few companies they’re still being made by engineers or developers. This may reflect the huge number of new prototyping tools available these days.

    What Are PMs Doing?

    There was a lot less agreement across  companies about what PMs were doing, frankly.

    top 5 product manager tasks



    The most agreed upon task for product managers was creating and maintaining feature roadmaps, with 63 people saying that this was almost always done by product managers. In twelve cases however, roadmaps were maintained equally by designers and PMs, and in six cases, they’re being made by someone else or not being made at all. Project and program managers are sometimes the keepers of the roadmap, but very infrequently.

    roadmaps are mostly done by product managers


    Feature Definition, Business Strategy, and Scheduling

    Many of the most common product management tasks, unsurprisingly, are things that involve defining and prioritizing features, creating revenue models, or project management and scheduling tasks like sprint planning.

    But there were really only a few of these tasks where more than half of the respondents agreed that they were done mostly by product managers and there were no tasks where more than three quarters of the respondents agreed were all or mostly done by product managers.

    Business strategy, for example, was reported to be done primarily by PMs in only 50 of the 83 cases. In five cases, it was done equally by PMs and Designers and the rest of the time was done by anybody from executives to finance to nobody at all. In one case, the entire team worked together on setting business strategy.

    What are People Doing Together?

    The most inspiring part of the study for me was how many tasks people are doing together – either as a whole, cross-functional team, or at least across the PM and Design roles.

    In 13 cases, the entire team reported brainstorming new features together, and in 51 cases, brainstorming was done about equally by PMs and UX designers. Hopefully that means that more people are getting involved in figuring out which new features to build for users.

    Perhaps the most evenly split task was customer discovery, which worked out like this:

    • Mostly designers: 17
    • Mostly product managers: 17
    • Equally by PMs and designers: 20
    • Not done: 15
    • Other: 16

    I don’t like to see customer discovery not getting done almost 20% of the time, but it’s good that when it’s happening it’s a shared task. Needs finding had a similar split, as did most forms of generative research. At least, when user research is getting done, it’s getting done by the whole team rather than being entirely run by one group.

    Why Does this Matter?

    Having a shared understanding of what we do and what we’re supposed to do is hugely important to creating a well-functioning team. Imagine trying to build a baseball team where nobody agreed on what shortstops were supposed to do or what made somebody a great pitcher. It would be chaos.

    And yet, every day, we hire people, add them to our teams, and give them titles like product manager or UX designer or researcher, without realizing that the last company where they worked might have had an entirely different definition of the role. Then we’re shocked when somebody who was a fantastic PM at their last company isn’t succeeding. Or we can’t believe that the new designer can’t do what we consider to be a trivial task. Worse, sometimes we have no idea what our coworkers are doing or what they’re supposed to be doing, which is why important tasks can fall through the cracks.

    Learn More

    There is actually one more bit of research that I’ve been doing in parallel for awhile now as I work on my new book, Build Better Products (Rosenfeld Media ‘16). I’ve been talking to teams in order to understand which ones are most effectively delivering value to users. There seems to be a very strong correlation between good outcomes and the teams that report doing certain of these tasks together. Teams that conduct research together are more likely to understand their users. Teams that use that research to ideate together are more likely to come up with feature ideas that users want. Teams that decide business strategy together are less likely to get into arguments about what should be prioritized.

    If you want to learn more about how your team can work together more effectively, check out the upcoming one-day online conference devoted exclusively to Product Management + User Experience (February 3, 2016). I’ll be sharing activities you can run yourself to build team cohesion and get everybody working together. Your ticket gives you all-day access plus unlimited replays to the full program. There are only a few spots left. Hope to see you there!


    Laura Klein is a Lean UX and Research expert in Silicon Valley who teaches companies how to get to know their users and build products people will love. She’s a Rosenfeld Media expert and author of UX for Lean Startups (O’Reilly). Her newest book, Build Better Products, is set for release later in 2016. Follow her on Twitter or subscribe to her blog and podcast at Users Know.

    Just in case you were wondering

    Posted on

    …the answer is: no. We haven’t gone into the dietary supplements business.

    A handful of you have reported receiving “Lean Fatburner” pills instead of Tomer Sharon’s new book, Validating Product Ideas Through Lean User Research. 

    Although both products include the word lean in their names, they indeed are not the same product. We’ve explained this to our distribution company, and they appear to understand the difference now. If you do ever receive the wrong product from us, please let us know and we’ll slim the problem down.

    This is ultmately something of a shaggy metadata story. I wrote a little more about it here.

    We’ve signed two new books

    Posted on

    It’s been a busy week. On top of launching Tomer Sharon’s new book Validating Product Ideas Through Lean User Research and reaching the verge of selling out our Product Management + User Experience Conference, we managed to sign two new books that should come out in early 2017.

    Brett Harned, who helps organize the Digital PM Summit, is one of a new breed of project managers that focuses on the human element of getting projects done. In Project Management for Humans, he’ll explains why everyone should have at least some command of project management skills—and how the work itself is as much about understanding and working with people as it’s about managing schedules and scope creep.

    Our other new signing—About (Design) Leadership—teams veteran UX managers Russ Unger, author of many popular UX books and now at 18F, and Chris Avore, who runs product design at Nasdaq. They’re chock full of practical advice (just check out the table of contents!) for UX people who are moving into management and leadership roles.

    Looking forward to launching these two—and many more great new books—over the coming year.

    Whose Job is User Research? An Interview with Tomer Sharon

    Posted on

    As part of my ongoing series of posts where I try to get to the bottom of who owns user research, I reached out to Tomer Sharon, former Sr. User Experience Researcher for Google Search and now Head of UX at WeWork. He wrote a book called It’s Our Research which addresses this exact topic. His new book, Validating Product Ideas, is also now available. He’ll be speaking at the upcoming Product Management + User Experience hosted by Rosenfeld Media, designed to help teams work together to learn more about their users.

    Tomer recently announced that UX at WeWork won’t have a research department and what drove that decision. I took this opportunity to ask Tomer a few questions, and to learn what suggestions he has for creating a team that conducts research well and uses it wisely.

    Everybody Owns Research

    Possibly the most important lesson you can learn from Tomer is this:  stop asking the question “who owns research?” “Everybody owns research,” he explains. “Research is a team sport. What research is needed is determined based on different sources–decisions the team is trying to make, known knowledge gaps, dilemmas and arguments among and between teams and more.”

    Research is a team sport. The team needs to decide what it needs to know together. – Tweet This

    He encourages people to use all of these sources to generate research questions. For example, if a team has trouble deciding on development or prioritization of new ideas, then a research question might be “What are the top needs or challenges our users have?”

    “Research questions are questions the team needs answers to, not questions that you ask research participants during a study,” he says. That means that the team needs to decide what it needs to know together.

    By making research a key part of everybody’s job, it gets rid of the problem many teams have of ignoring research reports. Instead, research becomes a tool everybody can use to answer important questions.

    Use Researchers as Facilitators and Coaches

    Of course, that all sounds delightful, but it does bring up three important questions:

    • What if people just don’t do research?
    • Should we really let people who don’t have any experience do research?
    • And the most important question (to researchers, anyway) is does this mean we don’t need actual researchers any longer?

    There’s good news for researchers among us. We’re still needed, and we’re not just going to let completely untrained people take over our jobs! But instead of being a service organization, Tomer recommends that researchers become mentors, coaches, and facilitators of research. WeWork’s UX team will still have well trained research professionals. In fact, those are some of the first hires that Tomer wants to make. The difference is that they will be embedded with product teams and work with everybody to help make sure research is conducted well instead of working alone in their own silo.

    Of course, there are a few types of studies that professionals should lead. “In 90% of the cases,” Tomer says, “I’d prefer a non-researcher doing research, supported by guidance and mentorship of a researcher. The remaining 10% are studies such as ethnography, surveys (yes, surveys), and highly complex quantitative studies, in which I’d prefer a researcher leads the project.”

    Other times when you may need to bring in specialized researchers include cross-cultural studies:  where you learn about the behavior and needs of people in a culture very different than yours. If Tomer needs to learn about the needs of WeWork members in China or Indonesia, he partners with a local design research agency (not a market research agency!) to make sure the study runs smoothly and gets insightful results. But even then, all the team stakeholders must be directly involved with the research. Learning about your users isn’t something you should outsource.

    Learning about your users isn’t something you should outsource. – Tweet This

    Turn Research Directly into Design

    Here’s some more good news for those of you who don’t enjoy writing twenty page research reports that are never read (or creating hundred slide Powerpoint decks that colleagues suffer through). Making research an integrated part of the design process gets rid of the deliverables step.

    “Research must lead to design that then leads to more research,” Tomer explains. That’s why his favorite method of synthesis and communication is the design studio or design sprint. During a design sprint, the team comes up with a shared understanding of research outcomes and their design implications through sketching, critique, and quick research on team solutions. “The researcher or key decision maker in the team or company can facilitate a discussion in which the answers to the research questions are shared.”

    Research must lead to design that then leads to more research. – Tweet This

    In other words, get rid of the Powerpoint, and focus on rapid synthesis of research results. Immediately turn them into ideas and designs. This can save you weeks of report writing, and it also means that your team gets a clearer idea of the problems that you’re trying to solve.

    Break Down Silos (even if it’s not your job)

    Obviously this is all easy for Tomer to say. He gets to build the WeWork UX team from the ground up. But what about those of us who work in companies where research is off in its own silo? Do we have to wait until we’re in charge so that we can change the rules?

    Tomer offers insight on this_having spent a lot of his career working at a very large company with a very large research group. “Talk!” he says, “Approach new hires and help them with something not related to research. Teach them how to find the best parking spot or how to change their profile picture on the intranet. The key here is trust and relationship building. From there, mountains can be moved and silos can be brought down.”

    Even if we’re put in silos by management, all of us, whether we’re researchers, designers, product managers, or anything else, can reach out to our coworkers and build teams that transcend silos. It’s not easy, but the results are worth it, since we end up with better team communication and products that solve a need for our users.

    Learn More

    Interested in hearing more about how teams can work together better? Join us on February 3rd for our online conference on Product Management + User Experience. You’ll hear from Tomer, as well as other experts in design, research and product management like Marty Cagan, Christina Wodtke, Jeff Gothelf, Jeff Patton, and (me) Laura Klein. There are even discounted group tickets so you can watch with your entire team. 

    Laura Klein is a Lean UX and Research expert in Silicon Valley who teaches companies how to get to know their users and build products people will love. She’s a Rosenfeld Media expert and author of UX for Lean Startups (O’Reilly). Her newest book, Build Better Products, is set for release later in 2016. Follow her on Twitter or subscribe to her blog and podcast at Users Know.

    New book: Tomer Sharon’s Validating Product Ideas

    Posted on

    One thing that you’ll immediately notice about our newest book—Tomer Sharon’s Validating Product Ideas Through Lean User Research—is that it’s so danged practical. To create the book, Tomer used a radically simple (and practical) recipe:

    1. Interview hundreds of startup founders and project managers about the questions that keep them up at night
    2. Group them into nine critical questions (e.g., “Do people want the product?” and “Which design generates better results?”)
    3. Guide readers through a few quick and inexpensive user research methods that actually answer each of those critical questions

    The results are fantastically useful for anyone who is struggling to reduce risk and increase product success.Validating Product Ideas Through Lean User Research cover thumbnail

    In other words, lean user research meets product management.


    In some respects, this book—our 24th!—is a return to our practical, “here’s how you do it” roots. In another sense, it wasn’t written for UX people at all. Tomer, like so many of us, wants to democratize what many UX people already know. So if you’re a product manager or developer, this book is most definitely for you. But if you’re steeped in user research methods, you’ll still appreciate Tomer’s help in doing what you’ve already been doing: sharing the UX good news with the people you work with.

    Like every Rosenfeld Media book, Validating Product Ideas comes in four-color paperback and four DRM-free ebook formats (ePUB, MOBI, PDF, and DAISY). Enjoy!