Generally, when a person attempts to put themselves into somebody else’s shoes, they end up doing just that. They take their own thoughts and opinions, and consider the other’s position, while remaining in their usual mindset. However by doing that, the person isn’t really perceiving things through another’s eyes. They’re still within their own perspective, just in a different situation. Listening with an open mind and understanding how someone else sees things, is what it truly means to be in a person’s shoes.
When I was first offered the chance to design and develop a new project idea, my first instinct was to learn more. I have the general tools to develop the project itself, but there was still some things that I didn’t know. Who is the client’s target audience, and what do they want/need? These two questions were constantly repeated to me, not only in class, but in articles, interviews, public speeches, etc. I thoroughly researched the potential users and surveyed numerous people. I believed I had a strong understanding of what they wanted, and began to design the wireframe. The concept and design was thoroughly discussed with my team, and changed multiple times, before we had finally come to our first official prototype.
To get a grasp of how useful (or terrible) this first version was, I decided to hold my very first usability testing session. I gathered a group of 6 people, who fit the profile of our target user, and guided them through the prototype. I booked a working space for 2 hours, believing it would be more than enough time to carry out the testing. My team and I had gone over everything several times ourselves. However, before I even knew it, my time was up and the post-testing surveys hadn’t even been handed out yet.
By the end of it, I realized how unprepared I was for the feedback to come. Finding areas of improvement was not as simple as just gathering some research and testing within the team, especially for the first prototype. Going into the session, I assumed that the prototype was close to being ready for development. So I predicted the feedback to be short and simple. However, this was very much not the case. Not only did the group have several suggestions, but they also brought new ideas to the table. I didn’t account for the time it would take for each person to explain their ideas, in addition to simply stating them. Also, the group would further weigh in on a suggestion, to either support it or debate it. Then, as the facilitator I had to explore each idea as needed, to gain a stronger understanding of my potential users, before moving on.
In addition to discussing existing features, the group gave ideas for new ones. I could see that their intention was to extend functionality, in order to make the app more attractive. Immediately, I was concerned because I’ve seen other apps fail, as a result of doing just this. I had purposely designed the app in a minimal way, to avoid making that mistake. I almost considered refusing suggestions for additional features entirely, as the clock was ticking and it didn’t seem productive to be discussing them. However, as the facilitator I wanted the group to feel comfortable in discussing their ideas, so I let it continue. To my surprise, in the process of exploring different features, they had actually come to some very useful ideas that supported the primary function. Despite how infeasible one idea would sound at first, taking the time to delve into each one turned out to be rewarding. I suddenly realized how incredibly naive I was, to think that the first prototype would only take 2 hours to test and analyze.
The session turned out to be much more enlightening than I had expected. I originally predicted the feedback to be as simple as a few small changes in design. What I discovered instead, was a variety of interpretations. There were suggestions that were easily agreed upon by the majority. However, there were also criticisms that were quite unique to each participant’s own experience. As differing as these perspectives were, each one proved to be equally informative. So the challenge I was then presented with, was to take these varying experiences and somehow, determine a common thread. Thus with that knowledge, I could understand how to improve the user’s experience in a way that would be most effective for everyone. By falsely putting myself into the user’s shoes before, I ended up with a design that was much further from completion than I thought. Moving forward, I need to remember what it really means to understand my audience.
