Why we should design things to be difficult to use

  • Interesting piece about design in the Guardian today, which caught my attention with a lovely photo of an antique camera (another passion of mine).

    It got me thinking of my love of the monome hardware and my frustrations with monome software, even in this serialosc/sum world. Maybe ball achingly difficult isn't such an issue after all.


  • Hmmm... my first reaction is that things should not be difficult to use, but they should ideally be easy to use without taking away your decision making ability, or providing you with prepackaged solutions.

    I used Leicas when I was a snapper, simple mechanical cameras with a simple light meter. I found them very productive, partly because I wasn't worrying whether the camera was going to second guess my decisions about focus and exposure.

    Is the monome really so hard to design apps for? I don't think so (very limited experience of course); one of its charms is that the interface discourages feature bloat and promotes clear, simple design. I'm very attracted to that.

  • In app design? I've no idea. I've never really wanted to design apps - I want to make music and unfortunately I've spent as much time trying to set up the monome for different functions as I have making music with it. This isn't a criticism or complaint, as the music I've subsequently made I've been very happy with, but it's been a reality for me.

  • OK, you mean it's difficult to actually use with other peoples' apps? I was barking up the wrong tree then.

  • relevant to this:


    which we were interviewed extensively for.

  • Thanks for posting that very interesting article, Brian.

    Raja - One day I will travel to Japan, and make my own mind up. In the mean time, I shall carry on shitting without further thought on the mechanisms for it's disposal.

  • i have heard these "difficult" interfaces described affectionately as "expert interfaces", but i'm coming up blank on a citation for that.

    many linux users have solved the particular issue of constantly moving between the mouse and the keyboard by instead eliminating the mouse and making the keyboard the main interaction device. flavors of everything from text editors and IDEs to the windowing environment itself are available with keyboard-centric interactions. my favorite anecdote is about a window manager called "ratpoison", the tag-line of which is "say good-bye to the rodent".

    for anyone truly curious about expert interfaces, i would recommend learning to use the vim text editor, which is a brilliant example of what's called a "modal interface". vim's interface exists in two main modes: normal and insert. in insert mode, typing on the keyboard inserts characters into the document (as you might expect a keyboard to do). but, in normal mode, all keys are effectively short-cut keys, and sequences of editing commands can be composed together almost like sentences. for example, "dd" deletes a line, "d$" deletes until the end of the line, and "di(" deletes everything inside of a given set of parenthesis (whichever the cursor happens to be inside at the time). vim is disorienting at first, but i have yet to find any sort of program in which i can work as quickly an efficiently as i do inside it.

  • Designers tend to assume a lot of responsibility in terms of human need. Whilst we need to take some, other times it's just about accepting the reality. People want simple interactions. We have enough difficulty in our lives to mentally engage us. If we were to design things to be difficult, they would be adopted by the expert, not the mainstream.

  • This is bullshit. We should not deliberately design things to be difficult. I can't believe some of you suddenly think the frustrations of setting up monomes ought to be seen in a positive light.

    In my opinion the author of the guardian article misses the point. I interpret "don't make me think" as "don't make me think about things standing in the way, let me focus on what matters". Be it online shopping or using the monome for musical expression.

    Google "Jef Raskin" for some inspiration.

    Read this: http://archive.wired.com/wired/archive/1.06/1.6_guis.html

    That said, I (as visinin) use vim. It's modal as hell and quite charming. But I refuse to think it was created to make text editing more difficult, quite the contrary...

  • indeed the title is misleading, but i think the underlying point rings true. perhaps better phrased as 'design things for mastery' rather than design things that can be used instantly.

    the argument is that limiting yourself to designing tools with near-zero learning curve greatly restricts the potency of your tool. the use of the word 'difficult' is a misnomer, and in context seems to mean 'requires practice & learning', which is not 'difficult' per se and often results in a less difficult / more efficient end process. vim is a perfect example where it enables you to work faster than you could in an 'easy' text editor, and once you've learned the software, the shortcuts become second nature and 'easy'.

    that being said- years ago i spent a while trying to learn the dvorak keyboard layout because it was meant to be 'easier' but found it was too 'difficult' to learn...

  • Time is a huge part of mastery, so interfaces have to be engaging. I shoot with a 1960's rangefinder camera because I find it engaging in every way. I could just hold it for hours and not take a single shot and enjoy the experience.

    Same with the Monome Grid- The fact there are apps like Conway and Bitrain shows that people love engaging and spending time with the interface without even when there isn't a specific function they need to perform.

  • totally - when something is 'fun' you want to spend time with it. people seem to find the ipad 'fun' and spent lots of time with it, but they don't get 'better' at it, because there's not much room to master it.

    contrasted with something like a piano. people love to sit down and twinkle the ivories, with the result that noodling for long enough you start to improve your technique & begin the path to mastering the instrument.

    so the trick is, how to make an object with great potential depth which is fun & engaging (not alienating / intuitive) to a first-time user such that they want to play. if that were a question every design team asked at the beginning of a project we'd have a lot less junk in the world.

  • This conversation reminds me of a lesson that Futureman and Victor Wooten taught at his Bass Nature Camp. They talked about private music lessons and the first thing Futureman does when he gets a guitar or other student. They don't mess with technique, theory, staffs, keys, all that stuff. They sit down with the instruments and start playing notes, music. It is a simple beginning but the focus is to get the student making music or hooked to begin. The instrument will have plenty of difficulty but the way it is taught is actually what draws you in and gives confidence to approaching the difficult part - really learning the interface.

    Some good points here but I agree that the word difficult is not the best choice.

  • Life itself is a very difficult interface to learn, if the user has the wrong attitude :)

    "So it is said that when you know yourself and others, victory is not in danger; when you know sky and earth, victory is inexhaustible." -The Art of War

  • I think this discussion hinges on the assumption that a steeper learning curve begets a deeper experience, either that or it's just about competition/thinning the playing field.

    Ignoring the second possibility, while a deep and powerful "thing" certainly will require time and effort to master, this doesn't mean the process must be difficult. The most successful "things" I think are the ones that shepherd you through this process the most efficiently. The example that comes to mind is Rosetta Stone. (dMaster/dt --> MAX) Surely we measure our teachers (or rather we should) by how much improvement they can inspire.

    I think the best designed software is easy to use and difficult to master, not because it was created with that intention but as a consequence of the control it allows. ProTools is a good example of this. So yes, we should create things that are difficult to use in a sense, arguing about why we need to create things that are difficult is semantics.

    All you're really saying is No pain, no gain - I guess the question is, does this need to be true? Wouldn't a successful design maximize gain while minimizing pain?

    I agree 'difficult' is poor word choice.