New Book: Designing Interface Animation

The most interesting places happen at the in-between places.

Val Head’s new book, Designing Interface Animation: Meaningful Motion for User Experience, sits smack dab in between two sub-genres: books that provide broad overviews of animation, and books that show you how to implement animation for interactive products.

Designing Interface Animation is the book you should use to make sense of animation so that you can create a plan for using it in your site. It won’t explain animation’s history, and it won’t show you how to code interactive animation. It provides the missing link—to help you develop a pragmatic, practical plan for where and when to use animation in your products and apps.

Timing couldn’t be better, as it’s getting so much cheaper and easier to take advantage of animation. That’s all the more reason to think it through—before taking a blind and potentially disastrous leap into coding.

Designing Interface Animation is now available for purchase in paperback and four DRM-free ebook formats. You can also pick up a copy from Amazon. If you want a taste, head over to the book site, where there’s an excerpt as well as an FAQ, lots of nice testimonials, and a really swell foreword from Ethan Marcotte.

---

Val Head is a web & UI animation pro specializing in motion style guides and web animation training. Her newest book, Designing Interface Animation, is available for purchase. Follow her on Twitter or subscribe to her UI Animation newsletter and Motion and Meaning podcast.

Whose Job Is User Research? An Interview with Celia Hodent

 

This is part 4 in the series Whose Job is User Research.

In this series I’ve been gathering perspectives from experts who develop different types of products. This time I spoke with Celia Hodent, Director of User Experience at Epic Games, a company known for cutting-edge technology and design in the video game industry. Celia also holds a PhD in Psychology so she has tremendous insight into how to use user research to improve the gaming experience.

Who Owns the Research?

It turns out that building games isn’t that different from building anything else. The user experience is a concern for everybody on the Epic Games development team. Research helps them understand more about their design. “The goal of UX research is to test whether design intentions are the ones actually experienced by the target audience,” Celia said. Research also identifies all usability issues that need to be resolved.

Like other great UX designers I’ve spoken with, she says that research should not be separated out from the design process. Research informs and supports the whole design process–which means that everybody needs to be involved.

“Owning the research is not just about conducting the research,” Celia says. “It guides the product team so that they ask the right questions, pose hypotheses, and make sense of the research results in terms of actionable items.”

Who Does the Research?

At Epic Games, Celia relies on expert researchers to conduct the research in the best possible way.

“When it comes to research methodology though,” Celia says, “the people handling research should be the ones who know how to design and carry it out.” Celia outlines four key steps: 

1. Defining the right experimental protocol to test the product team’s  questions
2. Running the research
3. Analyzing data
4. Communicating the results to the entire development team, as well as with other support teams such as Analytics or Customer Service to cross-check results against their data

Professional researchers, and sometimes outside researchers, can also help to reduce bias. “It is very hard to stay neutral when conducting research, even more so when you are part of the development team,” Celia says. Therefore, an expert researcher is more likely to get to the bottom of the research questions without preconceptions or confirmation bias.

When Do You Call in Researchers?

A common mistake Celia has seen companies make is reducing research to usability testing. Too often, product teams forget to involve researchers until after design is complete. By then, all they can do is find bugs.

Instead, Celia recommends bringing researchers into the entire game design process. “Whenever design iterations are conducted,” she says, “which happens as early as pre-production, the designers should pair up with a researcher to run quick-and-dirty tests.” You can use paper prototypes and interactive prototypes–before engineers start implementing a feature. It saves a great deal of time. You’ll find the high level UX issues early—they are cheaper and simpler to fix before you’ve implemented anything.

What To Do If You Don’t Have Researchers?

The truth is that many teams simply don’t have people familiar with good user research techniques. Celia has six tips to running research yourself:

1. Prepare your test well: be clear on what your design questions are and design the test to obtain relevant answers.

2. Tailor your protocol to your research questions and what you’re testing. For example, to test how gamers understand your heads up display (HUD), you can simply take them through a survey showing screenshots. But, if you’re testing how a new feature is introduced to a player, you’d use a “think aloud” protocol. Ask the participant to play through the game while explaining what their thought process. This shows you if they understand the interface as they go.

3. Test with people who don’t know you or your feature. People who know you will be more motivated to make an effort to figure things out just to please you and won’t be as open or honest in their feedback.

4. Encourage participants to ask questions out loud during research sessions. Avoid answering their questions to see how difficult it is for them to figure it out on their own. You won’t be there to help customers when they play them in the real world.

5. Ask fact-based, non-leading, exploratory questions. For example, “describe how you can use this feature” or “what was the objective of the mission you just played?” Avoid opinion-based questions like, “Was the feature easy to grasp?”
   

6. Look at everything as a whole when analyzing the results. Avoid highlighting only the part of the results that confirm your intuition. This is called “confirmation bias” and it can mislead you.

Learn More

Want to know more about conducting research well? Check out Interviewing Users by Steve Portigal for practical, easy to use advice on getting more out of your research sessions. Or join us this October for a one-day remote conference User Research for Everyone, featuring 8 of the most respected experts in the field.

---

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.

 

UX in all the Odd Places

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

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

It’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.

Enjoy!

Get your boss on board and come to Enterprise UX 2016

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

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. Or join us this October for a one-day remote conference User Research for Everyone–featuring 8 of the most respected experts in the field.

---

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?

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.

 

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.

 

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.

 

Roadmaps

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.

 

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. 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 recordings 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

…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

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.