Clutch spoke with Deanna Dial, Director of Product Strategy and Design at Praxent, on improving product success with human-centered design.
Tell us your name, title, and what your function is at Praxent.
Since joining Praxent in May 2017, I have served as a solution architect. In this role, I am our team lead, our client lead, and serve as product owner when our client is not present. I make a lot of the strategic decisions to direct the product strategy and design.
Share the human-centered design philosophy for Praxent and how it's changed over the course of the business.
Human-centered design is a philosophy whereby you arrive at a solution by focusing only on the people who have a problem. In contrast to the common practice of creating an idea, building a solution, and then forcing it on users, human-centered design ensures your solution actually resolves a pain point for real people.
It involves identifying and narrowing down your target users and defining the exact root of their problem. Often, it is not what people identify as the problem but the underlying causes of the problem. We use real people’s input along with creative facilitation to craft a solution. Then, we always check in with the end users to ensure the solution we plan to implement actually solves the problem and adds value to people’s life.
If you’re serious about your product’s success, this all should happen in design before coding a digital solution. Praxent has an internal product that we call ClickModel(TM). It’s generally the first phase of any custom software engagement we kick off. During the ClickModel phase, we conduct user research to gather empathy for the end user. We try to understand who the user is, where they are, and what their context of use is and identify their pains, motivations, and frustrations. We put this information into a clickable prototype called ClickModel, which helps to refine the solution. ClickModel is a core part of our practice and where we start with all of our clients.
Traditional software development is broken. Starting with the engineering is the worst possible approach. It wastes money and time on developing features that are often unnecessary or built in the wrong way. By creating a prototype first or taking a human-centered approach to building a digital solution, you can uncover a lot of potential friction points and pain points and basically improve the overall user experience before you start coding.
This makes the entire development phase and overall budget more efficient. It also means that sometimes we have to tell our clients their idea is not validated in the market, and they should consider a different direction. Praxent is unique because we have the courage to tell our clients this upfront and potentially save them hundreds of thousands in the long run. By starting with product design, if the idea is not validated, we don’t move forward; rather, we refine and pivot to find an idea that is validated by the target market.
Elaborate on how you convinced your clients to take this design-centered approach.
Some people believe they have the best possible solution, and there’s no way it can be improved. When I’m talking to this type of client, I help them realize they don’t know everything by asking questions that make them think and often help them realize they can’t answer all the questions.
I try to think ahead. I think from a user’s perspective and ask challenging questions. When you get to a place where they say, “I hadn’t really thought about that,” that’s a great point to respond, “You know who is thinking about that, is your users. If you want your users to use this thing, we need to understand who they are. We need to talk to them, and unless you want to set a bunch of money on fire, we need to put this product in front of them to validate that this is the best direction to go forward before you lay down code.”
Then the client says, “But what about timeline? I’ve got to get this out in the market in six months.” In that case, it’s more of a financial discussion. I explain what it takes to do the research and create a clickable prototype for a human-centered design approach and the cost to build the software. I weigh that against the cost to start with building the software and then the inevitable cost of iteration. From a financial standpoint, starting with design is almost always going to be less expensive than if you start immediately with engineering.
In my experience, individuals who don’t understand this are usually those who don’t have design experience. They don’t understand what it is and don’t see the value. Showing them examples of an engineering built product versus a designed product is usually a pretty stark difference. To ask them, “What’s an app or a company or service that you really like that you think has a great experience?” They’ll say, “Zappos!” or “I love to use Lyft.” How do you think they got to this really simple, seamless user experience that you like so much? Is it the same that you would experience in the enterprise software you use? The difference is the user experience design.
We draw parallels between something that is designed and something that is engineered and then use that input to demonstrate that engineers like working from design. When an engineer can work from a design, it helps them narrow the scope of what they have to do and focus on writing the best code possible. It makes everyone’s job much easier and clearer.
Additionally, we have another internal asset, which we call the Cone of Uncertainty. This is an illustration spawned from a research study by Steve McConnell on a large number of long-term software projects. He found that over half of software products are a failure. Either they never launch, go twice over budget, or take twice as long to build, and about 68% of features built in the software are never used. It’s a huge waste of time and energy in every direction. The last resort is sharing those statistics to help the client realize this is not just an idea or a gist but the way that you build software if you want to have the best chance of success.
What are other strategies your team uses to help a client realize the value once you've convinced them to try?
If someone thinks that they have the answer already outlined, we facilitate a workshop and go through the workflow and design the system from their standpoint. We whiteboard what users will do and think about it from a workflow perspective. We then step back and try to identify everything that could possibly go wrong. It’s a good way to help the client realize there are holes in the idea, and things need to be thought through. It’s a quick exercise to immediately identify any gaps.
Another simple tactic is a competitive analysis. We take a look at not only direct competitors or people who offer a similar product or service to the client but also a tangential landscape analysis to see what companies who are one or two steps away are doing. We look at this and try to find areas to differentiate. A big part of coming up with the vision is to define why this idea needs to exist in the world. You have to define why it is different, unique, and valuable compared to anything else. Looking at both the competitive and general landscape is a quick and effective way to identify what can be differentiated or what their unique ‘why’ is compared to other options available to the consumer. We also do some brainstorming and positioning work and take that output to do some light market validation.
With respect to market validation, there are a lot of strategies outside of scheduling multiple interviews and spending a lot of time with people. Depending on who the target user is, you can do guerrilla-style user testing. For instance, I’ve stood outside of a coffee shop and asked people who are coming in and out, “Can I take five minutes and buy you a coffee and show you this thing and get some feedback on it?” You can even start by reaching out to friends and family and asking for their thoughts on the idea just to get an initial direction. Those are strategies to help hone in on what we’re doing, why we’re doing it, and what approach we need to take.
How do you help the client understand which of the items on the list are more urgent from the user perspective?
Recently, we went through a whole process with a client and invalidated its idea. We outlined all of the features and organized them in terms of frequency of use. If your product is going to do 10 things, what is the user going to do most often? That’s a super easy way to prioritize and help clients realize that some of the features they wanted to add are not a core function, and those can be delayed to a later version. We do a lot of work to come up with the MVP (minimal viable product), which I define as the most limited one or two things that an application could do in order to provide value. We look at the frequency of use in order to knock out about half of the things, and then we go back to the unique "why." What’s the point of this application? We look at the five or six things remaining and see which one of those contribute to the overarching vision. This is where we start.
We’ve had many clients in the past that want to have it all. We explain that the given budget and timeline will not allow us to fit all of the requirements. One way to show this and help narrow the scope is by first outlining every core feature on a sticky note, then put them all up on the wall and draw a line to designate your MVP. We walk through each piece and determine how important it is and whether or not it needs to be above or below the line. You may want to start with a goal of how many things will move below the line or remain. You walk through every single one of those items and prioritize. Often with this exercise, the result is a fairly streamlined MVP, because, through the process, you realize some features are simply not as important or core to the primary value prop.
What are the most common challenges you face amongst your company and your team in confronting design thinking?
Design thinking is a little bit new to our company. The biggest challenge we have is time. Scheduling and conducting interviews takes time. The more important parts of the process, sympathizing with what you learn and generating meaningful insights, are also time-consuming. Since it is a fairly new process internally, everyone is eager to move forward and wants to define the solution before we’ve even done the research. The challenge for us is allocating and giving ourselves enough time to be able to do the research and do a proper synthesis before we jump to solutions. Even in the initial pitch, when you’re talking to the client, they’ll often have an idea of what the solution is and I, as a software person, have an idea of what their solution is. I tell them to put those solutions on hold and assume that is not the solution, so that they can go through a meaningful research process and not just rely on their initial thoughts. The biggest piece is giving ourselves enough time to learn, listen, and explore before we run on a solution.
What are the external challenges?
The biggest barrier to doing research is finding the right people to talk to. Honing in on the target user can be a challenge. You have to screen people to find the right type of person who meets the demographic or persona. Outside of convincing the client of the need and justifying the expense of doing the research, finding the right people to talk to in order to receive the right kind of feedback is a huge barrier.
One of the most challenging types of clients are existing businesses that want to build a new digital product and believe there’s no possible way that anyone could teach them anything new about their business. They think that because they have been doing it for a long time, they know everything. We first have to help them understand they are not the user; they aren’t building this for themselves but want other people to use it in order to generate external revenue. Many clients don’t understand this and think they’re the user. They think we can just talk to them and they’ll validate the ideas, but this doesn’t work. Having stakeholders understand they’re not the user, even if they’re someone who will be using the platform, is also a major hurdle to overcome.
How do you decide what lessons to learn from failure, and how does that define and inform your design process?
When we’re thinking about a potential solution, we often try two user tests with the most important parts of the application, but often it comes down to the biggest friction point. If there’s a question around whether or not someone would create an account or whether or not they would sign up for something, that’s the biggest point of friction. If they don’t do that part, they can’t experience the rest of the product. This is something in design that I would user test upfront. I always try to approach pricing strategy in user testing as a way to validate product market fit and whether or not someone is willing to actually take out their credit card and pay for the solution. These are the types of things you can learn through design. You fail all the time in design. That’s why you can never really define how many iterations will be necessary. You come up with something and you go out to the market. You might hear, “Oh, that’s awesome. Just make these couple of tweaks.” You go back and make the tweaks. You go out to a different audience and they all hate it. You go back and do another iteration. You come back and they love it.
There are failures that happen in the design process, but we try and prioritize areas we think will be the most likely to fail and test those upfront. Then, we start development when we have a rough idea of pricing. We know people will pay this percentage of the service or they’ll pay this range of dollar amounts.
When it comes to a pricing page and using a credit card, that’s something I would test with A/B testing. This a great place to learn from failure. You want more people going through the funnel for anything transactional. To really narrow it down, it has to be real. People might say upfront, “Absolutely, I’d pay $50 for that.” However, you need it to be live and real, in the actual moment to see how people will really behave.
How do you see design practices changing and evolving within Praxent specifically?
The design practice is changing at Praxent. The organization traditionally thought about design as a one-time activity. We did the ClickModel phase upfront, and once it was done, the rest was engineering. This has changed because design is never really complete. There is always a lot to be done. Design must dictate how everything works and essentially, leaving no decisions up to the engineers, in terms of functionality. What designers do best is solving problems and creating an optimal interface and experience for the users. Engineers are best at writing code in the most efficient way possible to support the experience.
Praxent now infuses design throughout the entire process with the understanding that design is not just an initial input but a stakeholder in the entire project. It’s not just important in terms of creating the right assets and making sure the engineers have everything they need. Designers also have a lot of context. The empathy they gather in the initial research phase is just as important as someone in my role who is leading the strategy and the overall vision. I always have a very strong design slant to what I do. The actual designer who is laying down the pixels has a valid seat at the table as well.