I'm proud to work with a diverse and talented team of people who comprise Cisco CHILL. Today, I've asked Whitney McGowan, our amazing user experience designer, to share what it means to design an experience focused on the user, not the technology.

I'm a designer, so when asked to write I often explain I'm not much of a storyteller, I'm more of a shapes and colors kind of gal. But I do know how to have a conversation. And that's really what being an experience designer is all about. An artist may strive tocreate an experience that speaks to its viewers, but a designer strives to create an experience that engages its users like a good conversation.

A good conversation leaves you understanding one another in meaningful ways, gives you direction and insight on the topic you engaged in, and inspires or provokes beneficial action. That's why it's such a powerful tool in helping to frame your user experience design strategy.

It's easy to think of design as dressing up a web page or app so it's easy for users to enjoy using a product or service. But if you want to craft a successful experience you have to approach design with an understanding that it's so much more than decorating an interface. You have to understand and design for the needs of the user.

In Cisco CHILL, we serve as a co-innovation catalyst for Cisco's$12 billion Customer Experience team. That means customers are at the center of all we do. The CHILL innovation methodology is built on a foundation of "massive inclusion," bringing in the diverse perspectives of everyone who is touched by the challenge we're working on. We accelerate time-to-outcome with rapid prototyping and instant user feedback. In fact, users are the ultimate arbiter of whether we further develop the idea, or take another approach. These are the very same principles you can use to inform your design decisions as you innovate and create a new user experience.

How to design with a story

It all begins with questions. Every question creates an opportunity to collaborate and the more inclusion there is in the process, the richer the data you have to work with to make informed decisions.

The questions you can ask about a particular problem or solution can seem like an endless road of distractions. This is why I kick off creative development for a project by getting the stakeholders together and asking everyone to write out all the assumptions we are making about the users, the problem, and the journey we see the users going on to overcome the problem.

What does this approach require from your team? A little bit of role playing, diversity, collaboration, and a lot of empathy for the users. We've all likely had the experience of being on a project where you slaved away at the features list making the perfect product, only to finally get it in front of your end users to find they don't connect or understand how to use it.

On a recent CHILL project, we spent two days locked in a conference room mapping out all our assumptions related to a complex technology service. In the end, we realized our biggest hurdle wasn't in perfecting the technology aspect of the service, but in addressing a very human problem-fear associated with big ticket purchases. Once we identified the problem, the solution became clear. While the technical execution of building a product is always important, users don't typically want to know how your product works, they simply expect it to work. The key to making a successful solution is in your team's ability to identify the underlying needs of the user and intuitively meet those needs while solving the user's problems with your product/service.

Listen and observe

How do you uncover those underlying needs? All you need are the same skills you use to have a good conversation: listen and observe. While we didn't cram all this into a two-day workshop, we took the learnings from interviews with potential target users and mapped out their feedback into a journey map. We were able to tie our assumptions about the user's experience with their current buying experience to feedback received and map out an idealized journey map for our solution. By mapping out the experience we were able to step back and see if the technical solution would meet the user's needs and solve their problem. In order to validate this with users we had to translate our journey map into actual screen designs.

This is where role playing comes into the picture. By synthesizing learnings from that two-day workshop into the form of a conversation, we're able to use that information to create a framework for the experience the user would have when they engaged with the product online. Information architecture doesn't feel like such a complex task when viewed through the lens of a conversation. We simulated the conversation a user might have with a sales person and translated that exchange into page features. By crafting the experience into the form of a conversation, we were able to create a story for the user and guide the experience users have in more meaningful ways that encourage engagement in mutually beneficial ways.

Product engineers may tend to lead with technology and features, but by leading them through a conversation to understand the user's point of view, we can ensure that the product features grow out of the foundation of the user's needs, not just cool technology. And when we put the prototype in front of users for validation, we'll find out how well we listened.