“This isn’t what I expected.”
Whether we’re ordering a pizza, buying a new home, or taking a vacation, we hope that what we’re spending our money on is worth it in the end. As customers, we believe any investment we make will meet our expectations and, occasionally, exceed them. It’s for this reason that we believe aligning on expectations is the key to any software project. At Dynamit, we take extreme measures to ensure we never hear “this isn’t what I expected.” But what does it really mean to not meet customer expectations?
Imagine you order a pizza. It arrives half an hour later than it was supposed to and it’s no longer warm. How would you feel? How about if the wrong pizza was delivered as well? Chances are you wouldn’t be ordering from that pizza place again anytime soon.
In our industry, failing to meet customer expectations is often a fatal blow, not only to a particular project but to future work and the customer relationship as well. When expectations aren’t met, customers are left frustrated, angry, and feeling as if they’ve been lied to. In addition to these negative feelings, customers must then face real consequences as their career and positioning at their company are negatively impacted, threatening their livelihood.
Customer expectations in our industry involve much more than showing up on time and with the expected toppings. The problems our customers are facing are complex, meaning the solutions we create are complex as well. As with the delivery of a pizza, customer expectations come down to effective communication. Customers expect the software they’re paying for to look and function as they’re told it would, and when they’re frustrated with the outcome of a project it's often due to a gap in communication or the lack of it altogether.
But how can gaps in communication be prevented? How are customer expectations managed the best? It really comes down to the people, processes, and tools that the project team has in place. It’s why we have regular touchbases with clients and our project managers are in constant contact with everyone on the internal team as well as the customer’s team.
A lot of agencies will use this by using requirement lists, and while they’re definitely beneficial to a project, there’s just something about seeing what an application will look like that customers love. It helps set next-level expectations for the customer and for our team that is developing the solution.
We use our interface-driven development process (IDD) to not only organize our projects, but to align and deliver on these next-level expectations requirements with our customers. As Practice Group Director, Josh Amer outlined in detail, the IDD process uses 3 key tools to prevent information loss and improve project communication, the package index, information architecture, and the UXD (user experience design). These tools use a shared language that the project team can reference at every project stage, from kickoff to launch. Each tool contributes heavily to the project, and while the package index and information architecture are critical for project organization and estimation, the UXD is the tool that shows customers exactly what their application will look like and how it will function. It’s the visual tool that we use to not only align with customers on their expectations but also help align their internal teams on the final product, no matter their level of technical knowledge.
Why the UXD Aligns Expectations
The UXD is a comprehensive document that shows every interface of an application and includes annotations that detail the functional and non-functional requirements. Before any development work is ever begun, we document each and every function of the final application. We then review the UXD with the customer, allowing for collaboration and feedback to improve the accuracy of the document.
Customers must then sign off on the UXD in order for us to begin development on the application. By showing the actual images of what the application will look like, as well as the details for each and every interaction on the site, our customers don’t have to guess what a screen may look like once development is complete. They already know.
Following customer sign-off, the UXD is then given to the development team and used as the foundation for what we build. By providing heavy detail and documentation for every interaction, the development team is armed with the knowledge of exactly how they need to build the application.
As a company, our mission is to build things worth building, and only things worth building, based on our ability to meet or exceed our customer’s expectations. As a full-service digital agency, we work on a wide variety of projects, but if the customer says at the end of a project that “this isn’t what I expected,” then we probably didn’t do our job. Our customers trust us to guide them to create solutions to real problems, and in return, we encourage them to expect more from us.
If you're considering a project and want to learn how we guide our customers with the UXD so they know what to expect, email Billy Fischer at email@example.com and he'll be happy to walk you through a UXD and how we can put that to work for you.