My maiden UX voyage: A retrospective of my first Double Diamond Design Process.

Introduction

How many communication apps are on your phone right now? And how many of these apps have you had to use at one time to accomplish your business goals? In a simplified world these apps could be used seamlessly to connect, record, share data, and engage in a face to face conversation while half a world apart.

But as it stands, there are some real issues around remote communications for many people and in my inaugural foray into the Double Diamond design process I set out to discover a solution to support the remote communications experience.

Research

I set my pen to paper in the hopes that a solid list of assumptions would pour out onto the page, launching me into a joyous fit of User Interview Script writing. This became a bigger challenge than anticipated as my assumptions began to oppose each other. At the core of my issue was the validity of opposing assumption and a stubbornness to forgo any reasonable assumption. The following assumptions made first cut:

• User base is mostly working professionals
• User base is mostly teachers and students
• User base is primarily socializing
• Primary user base is between 10–65 years old
• Computers are the primary remote communication device
• Phones are the primary remote communication device
• Users use multiple devices for remote communication
• Users need the ability to switch devices in the middle of remote communications
• Remote communications primarily occur out of the office
• Users are frustrated by the use of too many apps for remote communications

I then pivoted into drafting a script guide for my user interviews and used the observations gleaned from the interviews to test my previous assumptions validity. Immediately after my first interview, a download of understanding washed over me, of how validated assumptions can provide the preemptive answer, to good interview question. This really helped me understand that although I may know how to ask good questions, these questions did not directly translate into good prompts inside of the context of improving remote communications. It’s nice to know what somebodies familiarity and satisfaction are with tech hardware and software but this line of questions proved to be less impactful than those I generated through assumption validation.

User Interview Script:

• What hardware and software tools do you use for remote communications?
• What is your familiarity with remote communication hardware and software rating on a 0–5 scale where 0 was not familiar and 5 was very familiar.
• Tell of a time you enjoyed remote communications and why?
• Tell of a time you were frustrated by remote communications and why?
• How do you arrange your screens for computer based remote communications?
• What is your biggest challenge with remote communications?
• What is your satisfaction with remote communication hardware and software on a 0–5 scale where 0 is dissatisfied and 5 is completely satisfied.

With my initial assumptions now validated (or rather mostly invalidated), I collected the insights from my user interviews and used affinity mapping to elucidate a few core themes between the three interviews.

Core Insight: Issues with multiple apps and integrations

An even representation of observations from all interviewees about a need for simplicity.

Insight: There is a preference for bundling of relevant apps

My first grouping of observations centered around the over proliferation of similar apps with limited integrations leading me to the I statement “I have too many apps.”

Secondly, there was a uniform desire for a simplification that could be stated as “I think remote communications could be simplified.”

Thirdly, there was a real demand for a bundling of the commonly used apps for different business needs. Stated, “I would pay for a bundle of apps.”

From these three core grouping of observations I distilled the “I statements” together into a persona that embodied the most pressing issues.

Grace, a 34 year old single mother of one wants to simplify the way she uses 4 separate apps to communicate, collaborate, share data and manage her remote team.

What does our persona Grace want when it comes to remote communication? Grace wants a simple way to localize and integrate her preferred apps into customized bundled interface.

How might we create a personalized solution to simplify the growing number of apps for specific users’ business needs?

Design

Tying together the themes of simplicity, convenience and customization, I then sketched a story board to give myself a situational awareness of the problem. Next came low fidelity wireframes detailing a few ways to give the user a personalized dashboard that would integrate separate applications used for similar purposes.

First sketches of possible Application Dashboards layouts

These sketches were invaluable in the over all process and helped me build a user flow based around the sign up process. After some quick iterations, I converted the paper sketches into a digitalized low fidelity prototypes.

For this digitization I used the native InVision Studio app with the Apple Pencil, which was not a great use of my time but did give me an understanding of how to quickly make low fidelity wireframe prototypes.

This first pass prototype was used for the initial Usability Tests and these initial results were used to dial in the Usability Test Script.

First draft of the User Flow through One-Dash

I aimed to keep the user flow, sign up process and customization of the dashboard as simple as possible to lessen the learning curve and give the user a conversational experience.

Initial feedback on confusing wording and user flow informed the mid fidelity prototype and the wording was smoothed from Lo-Fi prototype #1 to Lo-Fi prototype #2.

Testing

With the usability test script now honed in, I used my final iteration of my mid fidelity prototype to conduct three usability test on a custom application dashboard service website called One-Dash.

For the usability test, users were instructed through a scenario and task to sign up for One-Dash and create a personalized app dashboard to manage the multiple apps required for their remote communications..

Usability test participants appreciated the conversational tone.

Usability testing revealed that there was no need to determine the users devices, and that users wanted options for other categories of applications such as Google Drive, Slack and RamBox.

All test participants voiced an appreciation for the customization feature of the dashboard. As a side note, all three participants expressed amusement with the choice of wording in the “Any other apps” screen

Results

3 of 3 participants were successful in signing up for One-Dash with only one participant voicing that they would not use this website. 3 of 3 participants also expressed appreciation for a customized dashboard experience leading to a successful Usability Test.

2 of 3 users expressed that they wanted to understand if the system had end-to-end encryption or some form of privacy assurance. Also noted by 2 of 3 participants was the need for a status bar to let the user know how far they are through the sign up process.

Overall the users all had positive experience signing up for One-Dash, pointing to the proof of concept in a simplified dashboard to consolidate multi-application remote communication experiences.

Conclusion

The concept of an app management system is not a new idea and the proof of concept is alive and well in messaging systems such as RamBox. That being said, the real conclusion from this project was not the deliverables of the Double Diamond process but what I gained in delivering the deliverables;

• Assumptions are starting blocks of questions, not the end of a session of siloed deliberations into the problem.
• Sketching is not the solution but sketching will present possibly avenues for exploration into the problem and the solution.
• Perfectly enunciating every word in a user interview script wont make the interview any better. Focusing on being curious about their experience and genuinely asking “why” will produce a better interview experience for all parties involved.
• Having a user flow at least roughly outlined makes sketching wireframes much easier. Surprisingly, even a poorly drawn map makes navigation easier than without.
• Context is King! Although my users were able to complete the task, giving my testers a more complete context as to the “why” this website was being developed or exists at all, produced a more realistic result. Poor context = “This website is too gray and these X’s in the boxes are really distracting, I don’t like this website!”
• Sign up is the easy part. Although all my users were able to complete the task, I didn’t take into account that this was really the easiest part of the entire application. If more time had been allotted for this, I would have liked to test if users were able to customize their dashboard or other more formidable tasks.

While this may have been one of the most challenging project in regards to allotted time, material comprehension and deliverable results, this was also one of the most rewarding project I have had the pleasure of working on. Im excited to take these lessons, compound them with future learnings and push forward optimistically into UX Design.