Scale human insights across all your teams
Get feedback on any experience with custom test creation
Get quick answers to critical product development questions
Get fast feedback on marketing campaigns, messages, and creatives
Platform capabilities
Connect with your exact customers
See, hear, and talk to your customers
Uncover insights about any experience
Share key insights across your organization
View all platform capabilities
In a recent webinar, Pradeep Nayar, Director of UX and Product Design at Allstate, explains how Allstate is adopting a lean startup culture and embracing an extreme agile methodology to 'fail fast' and learn from their users to make relevant digital products and services. We had a great Q&A session with Pradeep and included some of our favorite questions below. Enjoy!
We have users involved as soon as we have something. If we are actually in the early part of the project and we are doing discovery and framing, we have users involved from day two. If we are actually further along in the project, and we are executing in a project, we have users involved every week to every other week. We have users involved all the time through some form of either exploratory, interview style exploratory sessions, or usability testing.
We try to aim for every week to conduct research. I think where we are right now, we get it to every other week. We do most of our research using remote tools. We don't do as much in person when it comes to deep kind of initiatives.
Now, if it is for a mobile device, we actually do go out and spend time with the users. Sometimes it's five people and sometimes it just an interview. The key is to make sure it's a regiment, that you actually have that as a recurring thing because there's nothing better than having interaction with users to kind of ground everybody on the team.
We get buy-in from our senior executive leadership. But I would say that's not all you need. You need a lot more support from people in the middle and all the way on the bottom because it needs to get propagated all the way down.
We're dealing with organizational change and organizational shift. So I think the most difficult thing is making sure people understood why they're doing this. When we started off, we started with a proof of concept and there were a lot of people who didn't believe in it but as we started showing success, people embraced it and jumped on board.
If you are in the execution phase, usually, maybe a sprint or two. It would be nice if you are four or five sprints ahead but you kind of are designing in a vacuum then. We like to be as close to development as possible.
It's a different culture where it's not about putting things over the wall. It's more about that communication and collaboration. Because there might be things that are very design-heavy that need more time. Then it's just a game of prioritizing what's next.
Well, with lean research you are not spending a lot of months planning. You don't have a test plan that needs sign-off and gets everybody to buy in. The focus is on making sure you get out of the building.
With us, it's a lot more lean in the form of how we actually execute the research. The leanest part of the research is in the insights that come out of it. We do the research on Tuesday, we synthesize right after the research. And the stories are written right that day. So it's not like you're waiting for somebody to create a fancy deck that needs to be presented to somebody's manager's manager before it gets presented to the team. It's a lot more rapid.
I have two managers. And the managers actually are overseeing lab locations and are there to provide one-on-one support to a lot of the product designers.
Beyond that I have senior product design practitioners that also provide mentoring support. A lot of times it really boils down to the team being an embedded part of that cross-functional team. And the managers are supporting them in making sure that they have what they need from a career development standpoint and giving them advice and counseling on how to actually move forward.
Usually when you are doing a research study, let say you are doing it on Tuesday, the prior week you have already planned for that Tuesday so you're planning ahead. Now, planning doesn't mean you need to come up with a project plan. It's a lot more rapid. But we already have an idea of what we're testing the prior week. And that's usually a week or two weeks ahead.
The product owner which is essentially the product manager. But the idea of ownership is very different. We use the word product owner, product manager kind of interchangeably here. But the product owner represents the business in this scenario.
What's different though is it's a shared ownership like everybody has skin in the game. The product owner is not going to make a decision without counseling everybody. It's more collaborative and more participatory. So it's a lot more conversational, a lot more focused on getting the team in the same direction. And having the team aligned.
When we first did a POC we were trying to see if there any way we could actually show some return investment. We started trying all sorts of things to try to measure that. And then we got to a point where we talked with some of the other individuals that were doing this, other large companies. There's the Ford's and Home Depot's of the world and a few other companies that are actually kind of in this model. And they advised that you may not get what you are looking for because of how different the model is.
So what we did was we started a POC, took a product that was in our old methodology, just estimated as something that would take 30 weeks to do. We got it done in 13 weeks. And it was also tested, validated, and it was the fact that we had it out in 13 weeks that people absolutely loved.
So that speed was one thing that got people excited because that's not how we usually operate. The beauty about it is actually getting something in front of the users sooner, right? And making sure we're not making these bloated features that nobody uses.
So we ended up just doing a POC to prove our case. And by seeing the results that were being achieved by the teams, I think everybody else fell in line. We didn't have to make the case as much.
We're actually in the process of evolving it. And just like any component library, it's never complete. We had to create a pattern library that's essentially a library of components and pieces that can be used and leveraged. And we are in the early stages of doing that.
Get our best human insight resources delivered right to your inbox every month. As a bonus, we'll send you our latest industry report: When business is human, insights drive innovation.