Why Design is Hard (and why Iterative Design isn’t)

bkbwxqy

Design is easy. Just reduce the clutter, use lighter weights of Helvetica Neue, and use some new modern gradients and suddenly you are the next Jony Ive, right? This week will be a lesson in admitting you know nothing, and ways around it.  Along the way, I hope you learn a little about design for disability and why it is so tremendously exciting.

I will preface this post with the fact that I am definitely not a designer, but I was lucky enough to find two people who understand this on a deep level to give me a peak into this world.

f2-large

The first step of solving any problem is to understand the problem itself and the hurdles that block way to its solution. In my case, I wanted to build a Parkinson’s symptom tracker that would empower patients to take control of their progression. One of the most characteristic symptoms Parkinson’s Disease is the characteristic shaking. Countering this is a fundamental problem in the design adaptive technology for CNS-disorders and is frankly a still unsolved one. I hope I will be able to describe to you one solution, even if it’s not the only one.

Touch screens are hard enough to use with full mobility; buttons are often small and finicky, spinning menus are often imprecise, and clicking and dragging is a monster. Now imagine doing all the things you do on your phone with your non-dominate hand, this is similar to early stages of Parkinson’s disorder. Next attempt to use your screen with your non-dominate hand, while shaking your dominate sporadically; you are getting closer and closer to the experience of millions of Americans with CNS disorders.

Good design is hard enough in the first place, let alone design that holds up no matter the user. For lots of Apps in our vertical the solution is simple, design as you normally would and count on the caretaker to use the app for the patient. This works fine, and often will lead to objectively more beautiful content, however this isn’t better design. Design is entirely a product of context.

For us, this solution wasn’t enough, we wanted to give Patients the power to monitor their own symptoms. This meant fundamentally changing how mobile app design normally works, below is our solution.

enablemockup2-001

This was our first draft of our home-screen. We learned two important lessons during this stage.

The first of which is that design is not about the tools you use to create it; this screen, and much of our app, was designed in Apple Keynote. While sure we could have paid the hundred dollars for Sketch and the fifteen dollars a month for Photoshop and Illustrator (which we since have), we dove into our design process with a tool that we knew, and a tool we didn’t have to pay for. If we had dove right into Sketch right away, the learning curve would have made rapid prototyping much harder. By using a simple tool and building more prototypes instead of fewer more beautiful ones we got more feedback much quicker that we can then act on. This process is called iterative design.

The second lesson is on design for disability, and it is rather simple; if users are having a hard time hitting targets, just make them bigger. Normal UI design principles posset a button should be as small as it can responsibly be for labeling and comprehension. However, we flipped this principle on its head, and made the buttons as large as could be in order to see how precision would increase with a bigger target. The results were clear, bigger buttons means better accuracy.

Screen Shot 2016-09-18 at 8.46.41 PM.png

Our final design reflects what we learned in our initial rapid prototyping, although with a little more polish.

Another great example is our patient survey screen. The crux of our progression algorithm is a fifteen question once daily survey that allows us to get a little more concrete insight to build a progression model from.

EnableMockup.001.jpeg

Our initial design played with a smiley face design; but patient trials showed that this was both confusing and the horizontal movement was hard to target. So using the principles we learned in the home screen design, we went back to the drawling board.

screen-shot-2016-09-18-at-9-02-47-pm

Our current design has solved the problems experienced in our first trails. The new vertical scale is much easier for patients to use and colors provide cues to allow quicker development of muscle memory.

Perhaps its challenges like this that make Design for Disability such an exciting challenge for our team, being able to create something, get rapid feedback, and iterate through that process several times has been life changing for our design process. Rapid prototyping and iterative design has allowed us to build a groundbreaking UI that allows patients to take control of their own progression.

Next week we will be diving into the technical side of design, iterative prototyping, and UI work. To the joy of some readers, and the bemoaning of others, I promise they’ll be some calculus next week.

Until then, in the comments below describe what you would do different with the two interfaces below. What would you change? Where do you see difficulty?

3 thoughts on “Why Design is Hard (and why Iterative Design isn’t)

  1. kevinwang11

    You did a great job illustrating the difference between a good design and a bad design with the example of the “patient survey screen.” I totally agree that a good design should be achieved through user feedback collection and continuous prototyping.
    The two screenshots you posted at the end of this blog, from my perspective, do not represent good UI design. Users might be confused since neither of the screens explains its purpose.
    Since your application targets Parkinson’s patients, I would highly recommend that you take a look at a concept called “inclusive app design.” There is a WWDC session on this particular topic: https://developer.apple.com/videos/play/wwdc2016/801/

    Reply
    1. willmanidis Post author

      Hi Kevin – thanks for your comment. We’ve actually explored IAD extensively and throughout patient trials we have overwhelmingly found it is not effective in our use case and the model we are using has shown much greater effigy. We’ll probably have a white paper out on it soon I can forward you.

      You’re definitely right about the second; UI design is all about providing context and not instruction. The two screens are unusable without instruction, and as such represent candidates for improvement. There are also, if you’re feeling curious, more corrections to be found but some will require a knowledge of HCI-principles.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s