How Do You Design Interaction?

Advertisement

If you have to design an interface it’s almost obvious to think to begin the process by drawing. But is this the best way? I once casually started by writing an imagined human-computer conversation, and only afterwards I continued by drawing.

This changed my way of thinking and I never went back to drawing first. This article will explain the reasons behind my decision.

I have always been a huge admirer of the guys at Basecamp1. Some time ago, I was reading a tweet by Jason Zimdars, one of its designers:

1-design-interaction-zimdars-tweet-opt
Zimdar’s tweet2

“UI design starts with words.” He wasn’t joking. The comment got a lot of retweets, a lot of favorites. Everyone understood what he meant — except me.

Writing Conversations

When I’ve had to design an interface interaction component, I used to start by sketching possible solutions. (Product design is made up of many layers. See, for example, Jesse James Garrett’s layers3 (PDF) and Intercom’s4. Here, I’m referring to the interaction layer.)

2-design-interaction-intercom-4-design-layers-explanation-opt5
Intercom’s design layers (View large version6)

I used to start by using a pattern that I know or by copying other people’s solutions to the problem or to similar problems. Imagine that you have to design a website’s registration form. You could start by “stealing” other designers’ solutions. Or, if you feel confident, you could read the requirements and start to draw.

But I started by drawing.

I once had to design a shopping-cart process for an e-commerce website. I don’t know why, but at the time, before researching possible solutions, I imagined what I do when I go to pay at the supermarket. I wanted to reproduce a similar experience on the web, possibly improving it by exploiting the web’s digital capabilities. I wrote down what happens at a supermarket checkout counter:

Cashier: Hi, do you have a loyalty card?

Me: Yes, please. [I give it to her.]

Cashier: Thanks.

Me: Thank you.

Cashier: Do you need some bags?

Me: Yes, two please.

[And so on.]

I realized that imagining the conversation was much easier than drawing on a white canvas. I’m not sure, but I suppose that is true for most people: Conversation is an intrinsic part of human nature. We have evolved as a talking species.

Also, when I imagine a conversation, I draw from my real-life experience, which is good for design — less abstraction. If a user’s interaction with a computer resembled a real-life experience, then the interface would probably be considered easy to use, wouldn’t it?

Moreover, I pay a lot more attention to words and their meanings when I write than when I draw. The benefit is that when I get around to sketching, I will make fewer mistakes in the copy. Because copy is7 an extremely important8 part of any interface, this is a great side effect of writing out conversations.

A Real Example

While imagining a conversation is easy, imagining a variation of that conversation is also easy. Back to the supermarket example: I can easily imagine the cashier asking me whether I need bags before asking for my loyalty card. It’s easy to imagine the cashier asking me a different question. This may or may not change the sketch of the interface. It wouldn’t matter if it doesn’t change anything — what’s important is that I’ve taken it into consideration. The more variations I can think of, the more confident I will feel that I haven’t missed anything in the final design.

I usually go from product requirements to a list of use cases to a mockup (i.e. a low-fidelity sketch or a high-fidelity wireframe, depending on the situation), which becomes the base of the HTML prototype. Ideally, this process would be linear; in reality, it’s a loop, in which each step provides feedback for me to change something in previous steps.

3-design-interaction-writing-in-design-process-opt9
My design steps (View large version10)

Because writing enables me to see more variations, it improves the effectiveness of the loop between “use cases” and “sketch.”

Let’s see this in an example. The following conversation comes from an actual project, a web app called Mediaddress, a press office software. It’s an archive of journalists’ addresses. One of the requirements of the project was that people should be able to send emails to one or more recipients.

The use case I was considering was this: A user has mistakenly selected 5 people from a list of 100 and has forgotten to deselect them and instead would like to send an email to the entire list of 100.

Variation 1

Human: I’d like to send an email.

App: Just to the five you’ve selected or to all of them?

Human: All of them.

App: To write the email, would you prefer to use your email program or my editor?

4-design-interaction-variation1-flow-500px-preview-opt11
Flowchart of variation 1 (View large version12)
5-design-interaction-variation1-sketch-opt13
Sketch of variation 1 (View large version14)

Variation 2

Human: I’d like to send an email.

App: OK, I’ll send an email to the 5 you’ve selected. To write the email, would you prefer to use your email program or my editor?

Human: No, wait! I meant to send an email to all 100 of them, not just the 5 I’ve selected

App: OK, no problem, I’ll do that. To write the email, would you prefer to use your email program or my editor?

6-design-interaction-variation2-flow-500px-preview-opt15
Flowchart of variation 2 (View large version16)
7-design-interaction-variation2-sketch-opt
Sketch of variation 2

Based on the use case, I’ve written a conversation that can easily be translated into a flow and sketch. Then, I imagined a variation of the conversation, which produced a different flow and sketch. To understand which flow and sketch was better, I compared use cases.

I took the case of the user selecting 5 people from the list but wanting to email the entire list. Was this the most frequent case? I didn’t think so. Wouldn’t optimizing for a user who actually wants to email those 5 people make more sense?

Design consists of trade-offs. We have to always weight the costs and benefits of our options. But I don’t want to get into the details of how I decide which solution is best. I follow many criteria. My point is to show why a written conversation is a useful design tool.

I jump back and forth between written conversation and flowchart and sketch. But the guiding tool is the written conversation. I find it to be the easiest tool to imagine an interaction. The diagrams and sketches (or wireframes) come afterwards. They create order and help me to see the steps clearly. They are also a better tool to communicate with developers and other stakeholders.

To summarize my points:

  • Imagining a human-computer conversation and then sketching it is easier than drawing the interface directly.
  • Imagined conversations are drawn from real-life experience, while direct sketching is drawn more from remembered design.
  • Copy is fundamental to any interface, and writing first and sketching later enables you to concentrate on it at the right time.
  • Imagining different conversations is easier than imagining different sketches, which makes it easier to come up with more design options.
  • When I write, I am more creative (because I can imagine more variations), and I tend to copy other people’s solutions less.

What About Jason’s Meaning?

In the end, have I understood what Jason meant by his tweet? Why not ask him directly? I wrote an email asking for his opinion on the method that I’ve laid out. He was very kind to answer me:

So, I read through the article and I think you’ve pretty much figured out what I was trying to say with the tweet. Imagining a conversation between the user and the computer is a neat way to think of it. I do something slightly different in my own work. Instead of thinking about the computer at all, I try to imagine how Iwould explain the feature to a friend. This has the effect of being conversational, clear and helpful. I think it’s especially helpful to not think about computers because it’s so easy to fall into the patterns we’ve all seen before; “computer speak,” which is terse, leaves out words and sounds nothing like anything people actually say. I want my UI to read like I’d say it, and that means natural language and full sentences.

I’ll certainly rewrite many times in the form of sketches and continue to refine all the way through the process. It’s much better to trim and optimize the words than start with too few. That’s why I prefer this method to drawing. When you draw, you think too soon about the layout and the available space and what’s too long to fit on a button. Those are too many constraints to deal with at once. I find it better to get the words just right and then figure out the visual design.

Here’s a quick example. First the computer-speak version you might draw:

“Delete file”

[OK] [Cancel]

Now a version you might actually say:

“Are you sure you want to delete this file?”

[Yes, delete it permanently] or [No, I want to keep it]

That’s a little contrived, but you get the idea. I feel like the computer-speak version is an easy trap to fall in when you draw first. I could certainly whittle the second one down to that if space was extremely limited, but why not start with your best version and then consider any compromises?

Here are the lessons I’ve noted:

  • “I think it’s especially helpful to not think about computers because it’s so easy to fall into the patterns we’ve all seen before; ‘computer speak,’ which is terse, leaves out words and sounds nothing like anything people actually say.”
  • “That’s why I prefer this method to drawing. When you draw, you think too soon about the layout… I feel like the computer-speak version is an easy trap to fall in when you draw first.”
  • “It’s much better to trim and optimize the words than start with too few.”

I followed up with one more question, asking Jason how this method helps him to figure out flow, if it does. I wrote:

Let’s say you have a feature and you start to write. Does writing make you think about the flow or the feature, and because of that you change the flow or the feature? Or is the flow or the feature a separate thinking process? Maybe I would make myself more clear with an example. Imagine a bookmark app:

Me: Save this web address.

Computer: OK.

A second version:

Me: Save this web address.

Computer: Before I save it, do you want to change the title of the page? And do you want to add a short description of the contents of the page? And do you want to tag the page (so that it’s easy to retrieve it later)?

The second version changes the flow. Now, when I want to save a web address, a forms pops up. In the first version, I would just see confirmation feedback.

Here is Jason’s answer:

So, how the flow factors in depends on the situation. Many times features aren’t completely isolated. They fit into existing flows and screens — or at least start from there. So, I may have some idea of the flow already in mind. But I’m always open to improving that if the writing leads me in another direction. But even if it’s something completely new, I’ll start with writing because that helps me figure out the flow. If it takes a lot of steps to explain the flow to your friend, then maybe it needs to be broken up into similar literal steps in software. So, a typical writing sketch might include several blocks of copy as I figure out the flow. I think the important part of the exercise is figuring out how you might think of it in the real world, rather than simply thinking of it purely as a software problem. That leads to fresh insights.

These two emails seem to validate my method. They also give me new insight. Coming from a superior designer, the feedback fills me with joy. I thought I had an original idea, but maybe it was just a side effect of having carefully read what the smart guys at Basecamp have written17. I’m not joking either.

Further Resources

(cc, il, al, ml)

Footnotes

  1. 1 https://basecamp.com/
  2. 2 https://twitter.com/JZ/status/364882720914026496
  3. 3 http://www.jjg.net/elements/pdf/elements.pdf
  4. 4 http://insideintercom.io/the-dribbblisation-of-design/
  5. 5 http://www.smashingmagazine.com/wp-content/uploads/2014/07/2-design-interaction-intercom-4-design-layers-explanation-large-opt.jpg
  6. 6 http://www.smashingmagazine.com/wp-content/uploads/2014/07/2-design-interaction-intercom-4-design-layers-explanation-large-opt.jpg
  7. 7 https://gettingreal.37signals.com/ch09_Copywriting_is_Interface_Design.php
  8. 8 http://www.gv.com/lib/5-principles-for-great-interface-copywriting
  9. 9 http://www.smashingmagazine.com/wp-content/uploads/2014/07/3-design-interaction-writing-in-design-process-large-opt.jpg
  10. 10 http://www.smashingmagazine.com/wp-content/uploads/2014/07/3-design-interaction-writing-in-design-process-large-opt.jpg
  11. 11 http://www.smashingmagazine.com/wp-content/uploads/2014/07/4-design-interaction-variation1-flow-large-preview-opt.jpg
  12. 12 http://www.smashingmagazine.com/wp-content/uploads/2014/07/4-design-interaction-variation1-flow-large-preview-opt.jpg
  13. 13 http://www.smashingmagazine.com/wp-content/uploads/2014/07/5-design-interaction-variation1-sketch-large-opt.jpg
  14. 14 http://www.smashingmagazine.com/wp-content/uploads/2014/07/5-design-interaction-variation1-sketch-large-opt.jpg
  15. 15 http://www.smashingmagazine.com/wp-content/uploads/2014/07/6-design-interaction-variation2-flow-large-preview-opt.jpg
  16. 16 http://www.smashingmagazine.com/wp-content/uploads/2014/07/6-design-interaction-variation2-flow-large-preview-opt.jpg
  17. 17 https://public.basecamp.com/1679267/projects/343643-bcx-exporting/todos/5157955-design-the-ui-for
  18. 18 http://www.gv.com/lib/5-principles-for-great-interface-copywriting
  19. 19 https://gettingreal.37signals.com/ch09_Copywriting_is_Interface_Design.php
  20. 20 http://insideintercom.io/the-dribbblisation-of-design/
  21. 21 http://www.jjg.net/elements/pdf/elements.pdf
  22. 22 https://public.basecamp.com/1679267/projects/343643-bcx-exporting/todos/5157955-design-the-ui-for

↑ Back to topShare on Twitter

Luca Leone is a freelance self-taught interaction designer with a background in macroeconomics from his formal studies at Milano Bocconi University. He works with small and big companies on websites and apps projects.

Advertising
  1. 1

    I like this article, it leads to the concept of Narrative, something I first heard in connection with web UX from a good friend of mine, way back in 2008.

    It’s such a fundamental approach, yet so often completely overlooked.

    We all draw flow charts – steps in the process of creating an effective UX, but how often do we bother with the *narrative* behind that flow chart?

    This article has reawakened that conversation I had so long ago – rather than starting with a flow chart, write the user experience as if you were *talking* to the interface, expecting a reply.

    It’s an age old concept, that, as I mentioned, is often unconsidered in web projects, but you’ll find this concept explained all over the web:

    http://www.smashingmagazine.com/2010/02/11/better-user-experience-through-storytelling-part-2/
    https://uxfactor.wordpress.com/tag/narrative/
    http://blog.kissmetrics.com/narrative-web-forms/?utm_source=wptwitter&utm_medium=social&utm_campaign=blogtwitter

    1
  2. 2

    Nice read Luca :)

    0
  3. 4

    Nice ideas. I already use these conversations because it’s a more humanistic approach. Flowcharts are more adequate to machine behavior.

    What I usually do before write an application is try a real world experience. Go to a pizzeria with your friends and watch how they talk to the waiter. Go to the supermarket with your S.O., let him/her pay and watch how things roll.

    Take notes, use them in your project and have a case based in reality, not abstractions. :)

    0
  4. 5

    Achim Schlemmer

    July 22, 2014 5:51 am

    My projects always start with a written draft, followed by a concept paper. Always the same since 1998.

    1
  5. 6

    less process + clear communication = UX ?

    2
  6. 7

    Great article which raises some of the steps people may ‘think’ but not too actively.

    As a side point, a few of my friends at this end are worried about the conversational nature of some messages in browsers and one I saw recently as part of MacAfee.

    To put this into context, we feel that conversational is fine for messages are part of the normal application flow, but such informal wordings may trivialise serious errors.

    We have an LOB app which uses a Silverlight component. Unfortunately this crashes more often than we like, and users are very frustrated to see an “Aww, snap” error. They may have lost half an hours work and they are not particularly receptive to this kind of language in this kind of situation.
    Couple this with the fact that “snap” seems a very region (USA) specific way to describe a problem and it leaves people confused.

    Another example I saw recently was a with MacAfee antivirus on a laptop I don’t often use. I attempted to go to a site which MacAfee picked up as dodgy. It presented me with the message “Whoa!, are you sure you want to go there?” I felt this was potentially either at best making light of the issue (not formal enough to exhibit a formal reaction) or at worst a little patronising.

    So in summary, I believe that the article is correct in what it communicates, but I’d like to add that there are some situations where thinking about interface language conversationally, can be a little inappropriate.

    2
    • 8

      Interesting observation. I agree with you Doug. I use the conversation more to get the steps, the ui flow right, than the copy right. For me the main point is about the “relationship” between the people and the app.

      0
  7. 9

    Storytelling as a way of aiding user flow is a fantastic technique. With early-day social networks (using http://airwalk-design.com as an example of one of mine), big or small, a common issue is that users sign up but never actually engage. I found this technique very useful in helping users take their first steps with a brand new service, making them feel like we’re all the way with them should they get stuck. The user flow starts at the sign up, then a “start the experience” type thing from the first welcome e-mail.

    If the user decides to come back later, for reasons like “I can’t be bothered” or “I’ll have more time later” – chances are they won’t be coming back. The trick is to make an engaging and easy to follow first chapter, making them want to read the whole story.

    -1
  8. 10

    This is a great article. I never thought deeply about the conversation a person might have with the system.

    Also, I agree with Doug. The narrative can sometimes be a bit much. I actually like using short, concise words that the user is familiar with.

    -1
  9. 11

    Hello,

    I read your article very good concept how to design Interaction? you written in your article These article very lot of useful for me.
    Great

    Thanks for Sharing

    -1
  10. 12

    Very useful, thank you.

    -1
  11. 13

    I studied screenwriting at University and learnt there the principles to design interaction (=have a story in mind, communicate it properly and connect it in a consistent manner without forgetting some ‘wow’ factors)

    0
  12. 14

    Really good article and a clear way to teach it. A+ for this ;)
    It gathers many approaches like Day In A Life, User Journeys, thinking like the most stupid/average/advanced user, using your own experience etc. etc.
    I will remember this many times I am sure.

    -1
  13. 15

    Luca,

    I played around with your described story telling idea and tried to do a simple login screen (unfortunately login and simple are mutually exclusive terms) I soon found myself embroiled in a host of branching situations and found that my dialog started to look like one of those choose your own adventure stories. How do you handle more complicated programming conversations?

    Sierk

    2
    • 16

      I make choices Sierk. Design is all about choices, isn’t it? It’s good that you could come up with many possibilities. That means you see the complexity. I know that a ‘login conversation’ can be complicated. Because what’s behind is indeed complicated. There are many possibilities. Your question is not easy to answer. When I have many branches I go to check project goals, requirements, use cases, maybe I start to sketch something, I try to see if some branch is nonsense, try to check if I can merge something. I make myself questions: Is this correct? Would I ask this question? Is it natural? Do I need to write this? etc.. I cancel, I re-write. In any case at the end of this process I always understand the problem better. And, as I wrote at the beginning, I make choices, no way you can avoid that.

      1
  14. 17

    Nice post.. but just base in Theoretical knowledge.

    0
  15. 18

    There are many ways to figure out what it is you need to do. But all boil down to thinking through the process, getting it right, making it intuitive, being creative where you should, being sure to avoid all the tons of things you’ve seen that you do not like, and ABOVE ALL (by a trillion pixels)—- maximizing the usefulness to the user. (Otherwise it’s obvious the intent is to sell something or just please yourself or both.)

    0
  16. 19

    Isn’t this just creating a story board before the wireframes ? …really not something new !

    1
    • 20

      I’m not sure about that Paras. I don’t use story boards. I see it as a communication tool. The conversation is a design tool. It’s different. But this is just me.

      1
  17. 21

    Good article, Luca! 90% of my work involves reading or writing text, so I find it difficult to work on flows using images — it’s just not the way my mind works. Starting with words is much easier for me, and I hadn’t thought to apply this to interaction design.

    0
  18. 22

    Nice article Luca :)

    0
  19. 23

    This is a really, really good article. Luca, this reads like it’s a framework that you apply to lots of problems. Is that the case? If so, has it changed over time?

    0
    • 24

      Thanks Zack. Yes, you can say that, it’s a way of attacking interaction design problems. You wrote ‘framework’. I am not sure if I would use this word. It depends on the meaning you give to the word ‘framework’.

      Anders Schmidt Hansen is doing a great work in the framework direction. He can explain better than me. You can check his work on github, he calls it “Conversational Design Language”.

      And finally, to answer your question: no, the way I applied this method didn’t change much over time. I just got better to imagine conversations.

      0
  20. 25

    Great article, really. Bravo!

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top