Does this series of images look familiar? Do you frequently hear, "that's not what we asked for" or "it doesn't work the way we expected it to"? You're not alone! Research over the last decade demonstrates that between 30% and 60% of customer relationship management and enterprise collaboration initiatives fail. But why? Some would blame the technology, others might focus on the business process or lack thereof. But, let's stop for a moment and take a look at people.

People by nature tend to choose the path of least resistance. This is true even in a workplace setting; and many times folks on the front lines have a multitude of task based responsibilities to complete during the course of the workday or week. When the technology solutions they use aren't meeting their needs, they create shortcuts and find work-arounds. Lot of them! Everything from excel spreadsheets to completely separate standalone apps. So when it comes to delivering solution architecture, configuration and development that meets the needs of the business user, often times the issue isn't vague or changing requirements, it's a lack of thoroughly understanding the user personas.

So how do we remedy the approach in order to deliver a better outcome? Many organizations rely on a business analyst to capture the needs from the users. The analyst then translates those needs into business requirements. Which then get translated into functional specifications and then on to technical specifications as needed. Have you ever played the telephone game? Player number one whispers, "I love to go to the park" in player number two's ear. By the time it gets to player ten, the message heard is, "Eagle hooves glow in the dark"! I'm pretty sure eagles don't have hooves!

Instead of assuming the analyst understands what the user needs by hosting interview style sessions, why not ask the entire development team to really focus on and understand that user persona? First gather as much information as you can about the role and typical person sitting in the seat. Are they desk workers or road warriors? Do they live and breathe in email and other systems, or are they on the phone a lot? What is their age? Are they tech savvy? Are they task based or strategic in nature? You get the idea. Once you've outlined a solid picture of the typical persona you're trying to support, use it in every single project they are a part of. Hang up the personas in the conference room where the project status meetings will be held. Share it with every role on the team as a part of the kick off procedures. Revisit it along the way as requirements are getting fleshed out. Bump change requests up against the needs of that persona along the way to help with the approval decision making process.

What's next? Be empathetic. Conduct work with sessions or ride-a-longs and record them to be able to refer back to them later. Be super mindful of the process. This shouldn't feel like a training session where they're showing you what to do, this should literally be observing the creature in its natural habitat so to speak! Ask questions only if you're trying to understand why they're doing something a specific way. Any questions asked at this stage should always start with why… in fact don't be afraid to dig deep into the why. This is where the hidden treasure is found… the real pain points, gaps or roadblocks.

Remain action oriented! Ask your subject to keep the emotions at bay if at all possible in order to avoid clouding one another's judgement from the needs versus wants point of view. The focus should always be, how can the solution aid the employee in completing his/her work accurately, timely, and efficiently. Take the time to understand cross-collaboration too. This is important, as the handoffs between teams tend to be where we see the most gaps or roadblocks. Multiple teams may need to see and use the same data, but the way in which they do so may need to be different.

Do your best to identify the answer to the question, "what's in it for me?" from the user perspective. Why should they want to use the solution? What value is it going to deliver? How is it going to make their job easier? From there, compare the needs and wants the user listed to the needs of the business. We like to encourage clients to be "rigid at the core and flexible at the edges". So, consider what it is that the business needs to accomplish with the tool, the non-negotiables, that represents your rigid core. Next consider the ways in which you could accomplish the delivery of those needs and marry that with the way your persona works best, that's your flexible edge.

Lastly, remember to keep the persona immersed throughout the entire project life cycle. Show them what you're working on, don't just tell them you're getting it done. Use the ongoing feedback to continuously refine the deliverables. Use proof of concepts and pilot groups to test out new methods. And be certain not to just send them off with a test script during user acceptance testing. Sit with them again, watch them work through it, pay attention to where they're getting hung up. This information in invaluable in identifying where the interface is or is not intuitive and efficient.

You might think it sounds a little scary to have your developers interacting so closely with your users. It's really not, I promise. Remember, they're all just people, trying to get their jobs done as efficiently as they can. When you take out the red tape and give them common ground, partnerships are formed and amazing things can happen. Remember, they're just people!

Need some help getting started with personas or translating those ride-a-longs into an action plan? Drop us a line here, we'd love to help!