Two Concepts Diverged in a Design Wood

Inspiring prototyping through user testing

Daphne Tan
MHCI 2018 AllScripts Capstone- HIT Squad
5 min readApr 20, 2018

--

Our team has gone through several design sprints and ideation sessions — collectively as a team, in smaller subgroups, and individually. We’ve been thinking about clinical workflow design week after week, especially how technology can provide new tools to enhance its documentation and feedback process.

Our design phase has been structured all around design sprints, as @Selin mentioned and wrote about before. However, the output of these sprints need feedback from the people we’re designing for. Prototyping is an arduous task, and a great one to use so that we can get closer to formulating a product. Yet, a successful prototype needs qualitative reactions and quantifiable evidence to help designers and product teams appropriately measure the value of its designs.

Following three weeks of user testing, I’ve uncovered 4 attitudes design teams should consider as they prototype and user test.

User testing fuels future prototypes

Before we even began our design sprints, I found it vital for the team to prioritize user testing. Scheduling and sourcing users, though a mundane task, was something I wanted all 5 of us to commit to. Interfacing with users by showing them our prototypes is a key method for all of us to remain grounded — to be reminded of user pain points and most importantly, validate user needs.

User testing was and is a means for us to continue researching and probing. Were we inventive in a way that was too much of a stretch or did we fail to serve the users we were designing for? User reactions give us a better sense of product direction, helping us figure out where to dig further and quickly recognize where some ideas might fail.

A design sprint post user testing session.

Users don’t know everything, and neither do we.

As designers, we often tell ourselves to design for the user who isn’t like us. We may then inadvertently weigh our users’ needs and thoughts far too much. However, what we’ve found during our prototyping and user testing process is that neither party is an expert, and that incorporating end users in the design process allows us to architect better experiences.

What do I mean by the above? Synthesizing from user stories and personas sometimes isn’t quite enough. Formulating ideas together with the user through co-design sessions are worth the time. It allows the user to actively think and share his/her processes and attitudes in a non-invasive way. It sparks unique discussions, enabling designers to then take these insights and dream of how design can make an impact. Where users lack an understanding of technology stacks or design frameworks, we make up; where we lack depth and expertise of a domain, users bring to the co-design session.

Co-design discussions with local healthcare experts and EMR users.

Prototypes are conversation starters.

“Give something for people to react to.” This was the first piece of advice from our dear faculty advisors and since then, that phrase has stuck with me.

In truth, users have no idea what they want. By presenting them a tangible artifact, we were able to elicit more extreme emotions from our users. Extreme emotions revealed to us where to probe further and continue designing towards. A lack of emotion or neutral attitude, on the other hand, implied that a given concept or idea did not hold as much worth as we thought. And trust me, our team definitely experienced that with one of our main concepts. In cases like these, as much as we want the prototype to move forward, we pick up the pieces, decide on where there’s a tinge of value, and keep honing in on that feature rather than the entire prototype.

Without these prototypes as a forcing function to give concepts more form and structure, we wouldn’t have been able to quickly identify product direction.

Dream big — all the way to Mars — and let the users bring you back down to Earth.

At one point, our team began to converge on designs after two sprints, simply because we had spent too much time thinking together. This lack of imagination led us to parallel prototype instead. Everyone took a “How Might We…” question and ran with it. We created concepts and prototypes that didn’t really think about the constraints of our client’s tech stack or even what we believed the stakeholders would feel is implementation ready within the next year. Rather, we just focused on the the problem at hand.

I challenge designers to create something that doesn’t conform to preconceived notions. You’ve already done the research and have context, but letting that bog designs down limits our creativity and prevents us from potentially interesting and valuable ideas.

User testers sharing with us about existing workflows and imaging the future state of healthcare.

And that’s where user testing comes in. We can use it to allow us designers to see where our creative prototypes land in reality as we process our ideas with the user. Help your users by envisioning the new, elevated experience and they’ll in turn tell you how concepts can be adapted and modified for their use case.

So here we are…

So here we are, more than halfway through the design phase and we have two concepts at hand. We’re standing in the middle of a design wood, trying to identify existing synergies among our concepts — if any. User testing has helped us better qualify our research findings, allowing us to further explore problems deeply and challenging us to simply start creating.

But wait! Though the team finds itself diverged in a design wood, I see creativity and exploration at the end of either path. For us, we’re going to take either path and make it the one less traveled by because we’re always working at our best to reimagine experiences. And that my friend, is what will make all the difference.

Article title inspired by Robert Frost’s The Road Not Taken

--

--

Daphne Tan
MHCI 2018 AllScripts Capstone- HIT Squad

Product designer, photographer, and maker of things. Writing to my own beat, always.