Why is BP3 a Good Choice for Design Thinking?


Today we are going to discuss why BP3 is a good choice for Design Thinking and Design Sprints. We are going to answer the question of why would people choose to go with BP3 when there are so many options.


Speaker 1: Well, thanks, Andy, for sitting down with us. Today, we are talking about why BP3 is a choice for the modern enterprise when it comes to design thinking and design sprints. There's a lot of people out there doing design thinking, design sprints, doing workshops and classes, but why would people go with BP3 when there are so many options?

Andy: Sure.

Speaker 1: Other than you.

Andy: Right, okay. I would say that what makes us different than other design choices is probably our DNA, and process automation, and basically having all these incredibly smart technologists, right? Whenever you're trying to solve a problem for enterprise, you really need to consider the business architecture of that enterprise. What we see a lot with kind of competitors who do UX, who come in and do research, is they take a very traditional design approach. And the outcome ends up being something that just can't be implemented because it's so blue sky. It's not grounded in the business architecture, it's not grounded in a thorough understanding of the domain, and the interaction models that these users take when it comes to how the business actually operates.

Speaker 1: In a traditional design sprint, you'll see them understanding the business problem, but they won't actually understand the technology that's going to be used to solve that business problem, so they're not designing around that technology.

Andy: Right.

Speaker 1: You're building these huge blue sky, but not being able to implement it.

Andy: Right. In UX, the discipline is very much about identifying pain and solving that pain. But whenever it comes to an enterprise solution, you have to look at that pain holistically in context to the technology that is really kind of almost creating that pain, maybe? Or whether it's the pain is actually because of how the technology was implemented.

Speaker 1: So almost taking developer pain into consideration?

Andy: Right, pulling in that understanding of these legacy systems that maybe they can't be changed, and trying to find ways to solve that problem given those limitations.

Speaker 1: Well, thanks, Andy, for sitting down with us today. You can check out more videos about design thinking and design sprints from Andy here on this channel, so make sure you subscribe.

Interested in more videos like this one click here.