I’ve always preferred going straight to the source.
In grade school, teachers often have their students play the “telephone game.” The basic gist of it is that the teacher whispers a message to one student, who then whispers it to the next. One by one, each student would pass the message along, whispering, until the final student received the message. The majority of the time, the message would have drastically changed, barely resembling the original. The exercise was meant to teach a lesson about rumors and how misunderstandings can spiral, but on a broader level, it also helps illustrate how a person receives information.
As a designer, I work best when I know the full scope of a project. During my most recent engagement, I was given the opportunity to participate in every step of the Design Thinking process, from scoping to validation, as well as the final MVP (minimum viable product) presentation. To say this was my most successful engagement yet would be an understatement. In some previous projects, my opportunity to be involved was inconsistent. I would maybe be present for interviews, but could never quite dig in to really understand what the user was going through, or get important clarification on the new subject matter.
It’s not a huge leap to say that an inconsistent employee experience will generally result in an inconsistent employee product. Most workers tend to appreciate some variety in their jobs. It can prevent stagnation and even burnout. I would even say having the ability to adjust on the fly is a strength many employers look for. That said, providing some sort of baseline can be crucial to cultivating a positive employee experience, which often has a direct impact on employee performance.
The recent engagement I mentioned is a great example of how the employee experience can impact the quality of the deliverable. One piece of feedback we received during testing was that the solution was “exactly what I was hoping to see”. The prototype we built did go through iterations, as all do, but the changes were mostly to smaller details, not larger concepts. We were able to start with a solid foundation because we had been able to find a common focus in earlier phases of the process. That common focus was discovered through open collaboration with stakeholders and users, and access to those individuals at every step proved to be invaluable.
Being able to speak with not only the stakeholders but end users afforded me the opportunity to learn not just what we were trying to fix, but what we weren’t. Just as important as the “What?” was the “Why?”. Being presented with a problem (the “What?”) and being told to fix it can be a fairly straightforward endeavor, but gaining an understanding of the challenges that the users face (the “Why?”) is a whole different process. Details that might seem small or insignificant can provide important context further down the line, and a lot of those details can come from the interviews and conversations had early in the discovery stage of Design Thinking.
I’ve been involved in past projects where I was more or less given requirements and told to build a solution. This brings me back to my earlier point about the telephone game and prefers to go straight to the source. Even high-quality information, presented second-hand, can lose context. When it came time to analyze and understand the data collected in my most recent engagement, I already felt like I had a head start due to my involvement early on. My continued direct involvement allowed me to really dig deeper when sorting through feedback with the stakeholders.
Another benefit was increased efficiency as the workshop progressed. Having previously built up a general knowledge base from the scoping and discovery phases meant significantly fewer instances of getting sidetracked by explanations of specific subjects, and more time exploring some of the more granular details.
The level of access I had from the very beginning helped inform priority as we worked through the Design Thinking process with the various stakeholders. Not only did I get to see the results of things like dot voting and feature prioritization, but heard firsthand the reasoning behind those decisions. We had narrowed down a few different challenges we could look at solving, and only through these conversations did we find out one solution was already in the early stages of development. Knowing this, we avoided creating redundant work and were able to focus on paths that had the highest potential value for the users.
When it came time to start building out early iterations of a solution, all of the previous involvement was invaluable. I understood how the users interacted with their current tools and more importantly had a clear path to improving their experience. When it came time to create a plan around user testing, the tasks were planned out with the confidence that they would accurately reflect an improved version of the user’s current workflow. In the same way that increased knowledge improved efficiency during the understanding phase, an informed testing plan resulted in higher-quality test feedback and iterations.
As much as I’ve presented this from my own perspective as a designer, the stakeholders and users involved with the testing also had an overwhelmingly positive response throughout the Design Thinking process. Our quality of information and depth of understanding had been amplified by the level of involvement from the start, and that was reflected in our initial prototype. Our confidence in the data in turn gave them confidence in us. They saw that we had been listening, and were able to help us more quickly dial in the details, as opposed to sending us back to the drawing board.
Being able to engage at every phase of the process created not just a better working relationship with the client, but a better employee experience as well. The response both during and after the engagement was overwhelmingly positive, and the final product was viewed as a success.
As I mentioned earlier, I’ve always preferred going straight to the source. Collaborating closely with the stakeholders and users in this project meant I always had that source available to me. Moving forward, I could see this level of access and involvement being the standard, not just for designers like myself, but developers and others as well. Ultimately the result would be a better employee experience, leading to a better client experience and end product.
If you are interested in viewing similar articles, visit our blog, here.
View our LinkedIn, here.
