Until recently, I never saw the value in customer journey maps. In fact, throughout my career, I’ve even struggled with the value of personas and scenarios. Many times, stakeholders would just skim over them after our presentations or use them only to prove we were making progress on a project. Design teams, with the best intentions, made every effort to keep personas alive and breathing, only to succumb to other project pressures that demanded annotation, use cases, and itemized requirements.
So why have I written an article on the value of customer journey maps? How did I manage to reach the conclusion that customer journey maps are not only a worthy and effective tool, but also a crucial element on large, enterprise user experience (UX) projects? Because I saw them have a significant impact on a recent project with The Boeing Company, and I’m now a believer.
In this article, I’ll attempt to illustrate the virtues of customer journey maps, the necessary ingredients that make them an intelligent deliverable that encourages conversation and collaboration, and the role they can play in effecting real change in large organizations. Read More
We’ve all read monotonous reports and struggled to remain awake during boring presentations, but must all deliverables be interminably dull? Conveying user research findings so people can understand them, believe them, and know how to act on your recommendations can be challenging. And providing enough detail without boring your audience is a difficult balance. But there are some best practices in communicating user research findings that can make them more effective—and even entertaining. Read More
A common complaint about bringing UX designers onto a project team is that they waste time creating design artifacts. This is purportedly antithetical to modern development methodologies that value code over process.
However, this is not my experience at all. I’m not arguing that creating design artifacts is all that design is about. I default to fairly light documentation myself—and not one in 100 project teams or clients wants as little design documentation as I would typically provide by default.
One of my more common jobs is to improve or replace the design for an existing product for a client. All too often, these projects have no historical documentation of any value, which frequently causes projects to take months or even years longer to build.
Good documentation allows consistency in design and execution and serves as institutional knowledge for organizations. It enables us to remember what we’ve built and why, to check reported bugs and new feature requests against the documentation, and to more quickly react to necessary changes or updates. Read More