Communicating design synthesis

When synthesising the reams of data that we collected on the user-experience redesign for Pool, we produced several formal design artefacts that we used in workshops to communicate our thoughts and findings to stakeholders within the ABC. This process—explicitly encouraged by Jeremy Yuille—appears to be a direct response to Jon Kolko ^[1] and his argument that the private nature of design synthesis is one cause of problems in design practice:

When synthesis is conducted as a private exercise, there is no visible connection between the input and the output; often, even the designers themselves are unable to articulate exactly why their design insights are valuable. ^[2]

The artefacts that we produced were expressive objects ^[3], designed help us understand our process, but also designed to help include the client in abductive sensemaking. While these objects couldn’t capture the full gestalt of our insights, they allowed a level of understanding beyond the usual presentation and subsequent discussion of a traditional design outcome.

Kolko spends much of his paper defining an explicit sensemaking action framework, complete with some oddly specific instructions (my emphasis):

The designer will begin to identify insights in the data that has been gathered by combining an observation (I saw this) with knowledge (I know this). They can then write the insights on yellow note cards. ^[4]

While the methods he describes (reframing, concept mapping, insight combination) are not new to contemporary interaction design, the formalisation of a pattern language for synthesis methods is welcome and well justified, if a little over-prescriptive.

Where my experience on Pool fits here is not in relation to this formalisation, although we did use variations of the methods discussed in Kolko’s paper. Instead, it is in response to Kolko’s implicit argument for more effective communication of the sensemaking process to stakeholders. Discussing the lack of formality in design synthesis, Kolko notes:

Clients don’t see the relationship between design research and design ideas, and therefore discount the value of design research and design synthesis entirely. ^[5]

I can confirm this anecdotally from my own experience in various design and development roles in the industry. I imagine that most designers would have experienced this in some form during their careers. This not as an argument for formalisation so much as an argument for more effective communication of process. You might call it a ‘second-level externalisation’ of the existing ‘externalisation of knowledge’ performed by the designer during abductive sensemaking ^[6]. It is an attempt to make the implicit explicit.

What might this process involve? In the case of Pool it involved producing artefacts during sensemaking that acted as formal representations of our process. These artefacts were then used as a tools to communicate the (usually implicit) sensemaking to those not privy to the (usually private) insights of the designer(s). As a response to Kolko, it seems so obvious when stated: “The client does not recognise the value of design research and design synthesis—we really should communicate what we are doing more effectively”.

Kolko’s response to the sensemaking problem is a valuable industry focussed one: to formalise the processes through an applied framework (one that help designers understand their own insights), and to suggest that design practitioners allocate time to this formal process. I suggest an addition: produce formal artefacts during and after synthesis that can be used to communicate your process to stakeholders.

While synthesis is still primarily performed as a reflective and private exercise, production of formal records and artefacts could help a designer consider how and why they’ve reached certain design insights, improving the chances of effective articulation of concepts. These artefacts, when used as part of a client engagement activity, could help stakeholders to participate in—and better understand the value of—the research and sensemaking process.

1. Kolko, J. (2010). Abductive thinking and sensemaking: The drivers of design synthesis. Design Issues, 26(1), 15-27. ↩
2. Ibid. p. 25 ↩
3. Dewey, John. 2005. Art as Experience. Trade pbk. ed. New York: Perigee Books. ↩
4. Kolko, J. (2010), p. 26 ↩
5. Ibid., p. 16 ↩
6. Ibid., p. 18 ↩

Interactions and questions

My frequent collaborator Jeremy Yuille is off at Interaction 11 in Boulder this week, where he’ll be running an activity focused on interaction design fundamentals. Over the last few months, Jeremy and I have been working on a new iPad app… which I’m not going to write about here (at least, just yet).

I do want to note down something about our process that struck me as interesting though – there was very little “visual” design involved at all.

We did almost nothing in the way of sketches and wireframes, and the only visual work I did in photoshop was a few png files for shapes that were a little harder to draw in code. There was very little documentation other than some notes taken down after meetings or recorded sketches (which, incidentally, I never referred to).

Instead, we worked almost entirely with interactions and prototypes: Jeremy would establish a scenario or use case, and we’d develop a prototype – through discussion, a “test” (usually no more than pointing at pieces of paper or a post-it on a wall) – then I’d code a quick demo to check the interaction and performance on the iPad.

Each step of the design process had two basic questions: 1) What is the desired outcome (for the user)? 2) What is an interaction that will achieve that outcome with a minimum of friction?

This approach seemed to free us from traditional design patterns and solutions (though we did use traditional patterns where appropriate to the outcome) – by sticking to the pattern of “interaction supports outcome” you stay focused on the user experience in a way that other design approaches don’t always afford.

In fact, when we didn’t ask these questions we tended to get stuck. When we asked ourselves “how will we implement groups?” (a question about a specific information structure) we spent a long time trying to solve complex implementation details. When we instead reconfigured the question: “what is the outcome we want when we use the word ‘group’?”, we discovered that “groups” weren’t actually what we needed at all – we needed a different interaction altogether.

It was very important that this was done collaboratively. We would do thinking and coding separately, but all the “design” happened through discussion – this way questions could be asked, interpreted, and designs modified on the fly. The design happened through constant rethinking and questioning.

The process was iterative – each demo that I coded was tested against the outcomes and modified – so our finished alpha is essentially just a sum of the interactions that we kept from each demo.

The interactions are the interface

So what does all this mean in terms of a design outcome? It means that the visual design of the app is nothing more than a set of interactions that facilitate specific actions. Any visual “flair” either arose from an informational requirement (user feedback – a highlighted state), or a hierarchical need (size, position, object delineation).

Now, the app that we’re working on is unusually suited to an “invisible design” – it is a visual thinking and presentation app designed to work with a variety of user generated content, and designed to keep out of the way of the content wherever possible (much, much more on this when it is ready for the public). But I do think this process could easily be applied to all sorts of product development, and it is one that I’ll be using regularly in the future.

Mind reading

When I am reading online and find a great article that I don’t have time or inclination to read immediately, I use Instapaper. It’s great – I just hit my “read later” bookmarklet, and then I can easily find the article, or (more often than not) download it in text format to the Instapaper iPhone or iPad app and read offline – on public transport, in a cafe, on the couch. Instapaper is a great idea, and has been very successful for its developer Marco Ament.

For a while now, I’ve also kept a folder on my bookmarks bar in Safari that I use to save videos (YouTube, Vimeo etc) that I want to watch, but not right away. The folder’s name is “Watch Later” – kind of my own lo-fi version of Instapaper for videos. When I find a video I want to watch later I drag the link into the folder. When I finally get around to watching the video (or decide that I don’t really want to watch it after all) I remove it from the list.

So anyway, today I was reading a blog, the blog post contained a YouTube video, and I was just about to copy the link to save to my folder when I noticed a new little button in the top right corner of the player. Watch later it said. My brain did a little jump – OMG Google just read my mind.

Now, I know that YouTube has been playing around with playlists for a while now. (Hitting the “Watch later” button actually adds the video to an automatic playlist which you can access when you are logged in to YouTube). Because of the same use of language (“Watch later”), and because I’d been having that exact thought at the time that I saw the button, I didn’t care about the mechanics of the action – there was no “what does this button do?” moment. I just wanted to watch the video later. I pressed the button.

This is one of those instances where language is extremely important in interaction design. The button could have said “add to my playlist”. It could have been some obscure icon. I would have ignored both. So much of my positive reaction and hence my willingness to try a new feature was tied to the fact that the software was speaking my language.

Practice based research

Things sure change fast around here. (No, not another Time Flies post, although time is a bit of a theme). I’m taking another unexpected turn – not directly away from iPhone development, but something new, in tandem: I just enrolled in a full time PhD at RMIT University.

I’ve been doing quite a bit of work in and around RMIT for the last few years, and when the potential PhD candidate for the Circus Oz Living Archive project fell through, I was there to catch it. This is something very new and very different for me – I’m used to being employed to perform a particular technical task or to solve a specified design problem, but as a PhD candidate I’ll have to define a research topic and act on it. I’ve never even worked in a single job or on a single project for three years, let alone defined my own boundaries and focussed intently on a single research question.

What I’ve found from talking to academics that I’ve been working with lately is that a lot of what I am currently trying to do in my design practice is, in fact, a process of design as a way of inquiring and producing knowledge – design as research. What I don’t have is the theoretical background and frameworks to back up and support and know about what it is that I am practicing. Yet.

So this blog will be changing again too, (the third shift in its short life) to document my PhD progress along with my iOS development work.

Three years is a long time… starting now…

About time

How do you think about time passing? Do you think about start dates an end dates? Periods? The passage of the sun across the sky?

I’m asking because I’ve just finished a new feature for Time Flies –  the most requested addition to the app – a history log for your event updates. Time Flies as it stands is a memory aid that uses a single metric – when you last did something. Adding a history log to an event adds 2 additional metrics that can be used in all sorts of ways – frequency (how many times have I done something?) and regularity (how often do I do something?) The challenge was to present these on a single coherent screen without compromising on the fundamental simplicity of the app (which, based on user feedback, has been a large key to its success).

I had a few constraints to consider – the history needed to be in a list format (for consistency with the main app screen, and for the functionality I wanted to leverage from within the UITableView framework), and I wanted to avoid using icons or images – part of the simplicity of the existing design is in it’s text based interface. I also wanted the feature to be unobtrusive – not all events require a history, so it shouldn’t be too prominent – for this reason I decided that the history log should be accessed via the “edit” screen, not on the main event listing.

I went through a lot of design iterations figuring this out. The main edit screen fell in to place very quickly – I’d designed it originally with a lot of space just in case I did decide to add a new metric – a button below the date did the trick. But what about the history log itself?

My first functional iteration was really just a tech demo – it shows the start and end dates and a time period so that I could be sure that the data was tracking properly and the database upgrade ran smoothly.  The long dates are conceptually too far removed from reality to be a useful reference (unless you are really good at calendars), and the time periods sitting above are meaningless out of context (15 days since what? Or to? From? Between?)

From here I moved through a lot of different configurations. I tried showing From: and To: labels (too messy), time from now (not relevant anymore, once an item is in the history the important metric is time between events), just the start date and the intervening period (almost right, but still confusing). After some discussion with K, I understood that confusion was arising because the periods (3 hours, 2 days etc…) still weren’t clearly being read as a time between one event and the next in the list.

The solution seems very simple now but took a lot of getting to – I removed the the lines between entries to connect them conceptually as a single stream; added of a small red arrow to indicate time direction and to link each period with the next event – now you can see when an even started (the date), and how long it was between updates (period description+arrow); the large space for the event description at the top places emphasis on the most recent update (a stated goal in the original design) and demarcates all below it as historical.

I’ve been using the new feature for the last few days and I see why so many people have emailed me requesting it – it really does enable another level of understanding of your own actions – it’s all about self awareness, mindfulness. I really thought I went for bike rides more often…

On top of that, the app will now store some very useful data points for future additions if I go down the track of implementing built-in data analysis, which could be a very interesting path to pursue.

(The updated Time Flies is now available on the App Store).

Specifically general

Partly as a consequence of all the feature requests that I’ve been getting for Time Flies, I’ve been thinking bout the tension that exists in the design of software between specificity and generality. Time Flies was designed with a very specific action in mind – to help you remember the last time you did a particular action – and most of the features requested are natural extensions of this: history logging, notifications and alarms, expiry dates for events, [online] calendar integration, statistics, data export, categories… all perfectly valid ideas for extending the functionality.

What I’ve realised from this feedback is that Time Flies is what I’d call specifically general. It does a single, specific thing (track an event and a time period), but the contents of that event are not specified – meaning that it can be used in an enormous range of use cases (many that I hadn’t considered until I started getting feedback emails). This is where the specificity can become an issue for some – by being so specific it excludes some actions which are natural extensions of some of these uses. Everyone does things they need to remember, and all events have a start time – hence the design of Time Flies. But some events have an end time too – expiry dates. Some events will start in the future – notifications. Some events repeat on an interval, or relate to goal tracking – history logging. Some events you want to remember for longer than the life of your device – export, calendar integration. You get the idea.

I think that people are generally very good at managing a wide range of specific tools for specific tasks – think of all the kitchen implements that you own, the different shoes that you have. I own a single piece of metal specifically for adjusting the seat on my bicycle.

Over the last ten years we have been trained to assume that a piece of software should do everything – work as a ladle, and a sieve, and sneakers and dancing shoes, and adjust your bike seat. Look at Photoshop or any number of Microsoft products for extreme examples of this. The idea that software should do everything often leads to designs that add complexity out of proportion with the task at hand. I’d like to call these kind of design generally specific – a single tool that does so many different things it is hard to use for just one of them.

I’ve been thinking about this a lot in the context of a new app (as yet unnamed) that I’m working on – a photo presentation tool for presenting travel photos, in person, to someone else – a simple concept, with a lot of interesting space to explore. Once again it’s an app for me – I take a lot of travel photos and like talking about them and showing them to others.

It would very be easy for this design to submit to feature creep – there is so much that could be added to the app as it stands now – a few immediately pop to mind: photo editing, photo export, flickr/picasa integration. But each time I think of a feature I ask myself – does this feature add complexity that is out of proportion with its benefits?

What I’m hoping is that I can keep making apps that are specifically general rather than generally specific. I think people can handle it.

Prototype time

A process I went through a lot in my years as a flash developer went approximately as follows:

1. The client/agency would supply a finished design of a flash site (with complex interactions specified)
2. I’d question the interaction ideas, but my questions would be dismissed and I’d have to build the entire site to a full working version
3. The client/agency would see the finished version, but be unhappy with the interactions (which they had designed)
4. 50+ rounds of changes that involved me rebuilding and refactoring huge chunks of code until the client was satisfied

What caused this problem in most cases was the lack of allowance early on in a project for prototype time.

I love prototyping – it’s great to be able to get a working model of an idea up and running and iron out (or dismiss totally) any issues that arise well before you get in to production.

So… right now I’m working on a few different iPad concepts that involve the same general principles:

• Adding items to a scrollable list from the a library of items
• rearranging said items
• dragging an item onto another area of the interface to update its properties

While I’ve espoused the advantages of paper prototypes in the past – I’m finding it difficult to model complex interactions like multi-touch and drag+drop using lo-fi models. With complex interactions speed, responsiveness, and device limitations are extremely important things to test.

To get around this issue I’m trying a new prototype workflow: as I come up with an interaction that doesn’t suit a paper prototype, I’m building a small, standalone prototype that I can use to test the idea accurately without investing too much time building fully-functional parts of the interface:

The additional advantage of working this way is that while I’m in the design phase of these projects I’m still keeping up my coding practice (I’ve still got a lot to learn with Objective-C) – each little prototype is a discreet programming challenge that I can commit to without worrying or getting overwhelmed. Each prototype I make is also helping me build up a library of interaction code that I can use in the future if I decide that the idea doesn’t suit this particular project.

Progress

So I had plans for an extensive post about how I’ve made three apps in three weeks (half way to my six week goal) and all of my learnings and thoughts so far; discussing design process, coding practice, the unique interaction approach needed for the iPhone and iPad, etc. But something must be working with my App a Week project, because I don’t feel like writing that post. I feel like designing and building new apps.

So instead of long ruminations, here is a neat little list of some of my thoughts so far:

• A week isn’t a realistic amount of time to build a polished app, but it is plenty of time to design, prototype and test a concept
• I’m learning as much about what I don’t want to be doing with my app development process as what I do want to do – these short deadlines are forcing me to take shortcuts that I definitely won’t be taking once the project is over
• I’ve learned an enormous amount
• I’ve got an even more enormous amount to learn
• None of my apps so far are the “best” ideas, but I am learning how to quickly iterate and generate ideas (and I’m getting faster at it)
• I’m having a lot of fun

That’s it for now. I’ve got an app to make, and only 4.5 days left to make it.

App a Week #3 : Danger Mail – don’t email in anger

A bit of a silly one this week – a thought experiment exploring some of the inherent risks in having instant communication devices with us all the time, even when we shouldn’t be using them. Danger Mail is for when you need to write an email that you know you should never send.

Here’s the idea – If you have to choose between two clients to send your email (the normal Mail app and Danger Mail), then perhaps you will consider why you are sending the email – are you really communicating something that is necessary? Or are you doing it for you own (perhaps risky) gratification? Run the two apps alongside each other and you may think a little more about what you are putting out in to the world.

Danger Mail is intentionally non-functional. You cannot send an email with Danger Mail. It is a space for you to vent, to whine, to rage without consequence. You can write whatever you like, and write it “to” whomever you like, with no risk.

That’s the real issue at the heart of the Danger Mail – instant communication isn’t just instant anymore, now it’s public and permanent (cf Twitter, Facebook, et al). I think there are some serious dangers in all of the off the cuff, seemingly fleeting communication opportunities at our fingertips. I’m not advocating for a return to snail-mail; just a chance to think a little more before your message is out in the world. The advantages of instant communication are clear, but when that communication gets added to your permanent online record, the risks are enormous – who hasn’t said something in their past that they regret?

Half way there

This is my third app in as many weeks – half way to my six week goal. None of the apps are release-ready (one week of design and development simply isn’t enough time), but all three have sparked new ideas and forced me to do a lot of learning and practice which was the real goal of App a Week. I’ll be writing more about the process so far in another post.

App a Week #3 – Don’t email in anger…

Good, simple advice. If you go ahead hit send on that email, there’s a very good chance you’ll regret it. You could lose a night’s sleep, a friend, a job. Please don’t send it. Please.

On the other hand, writing in anger can be a positive cathartic experience – ask any 15 year old with a journal. There is something about the process of writing what you really think that allows you to get those thoughts out and on to a page, out of your head so that you can take stock and approach the problem in a more considered way.

So here’s an idea – how about an email client specifically designed for writing emails that you know you shouldn’t send?

I mentioned the other week a thought I had about developing apps that have structural qualities that are designed to modify a user’s behaviour in a specific way. The idea behind this app is that the mere act of using it should help the user consider their email content just a little bit more than usual.

So that’s what I’ve been working on this week – an email app that gives you a chance to change your mind.

An aside: read the instructions first.

When I was quite young, maybe eight years old, I remember buying a new plastic model WWII tank. I was never a particularly diligent or careful model maker and this was the largest and most complex model I’d ever bought. In my hurry and excitement I skipped over the instructions and started cutting an gluing, and (much to my parent’s amusement I seem to recall) within a short amount of time I’d somehow managed to glue the hubcaps on before the wheels. Anyway, you’d think I’d have learned my lesson by now…

It turns out Apple’s MessageUI framework explicitly doesn’t allow any interference with the email process – you can present a mail composition view (designed by Apple), but you can’t modify the view in any way apart from pre-populating editable fields – no custom controls or colours. You may set a delegate to receive a message after the mail has been sent or cancelled, but not before.

I have now gone so far as to build a prototype of the whole app using a dummy messaging view – I’d just assumed that I’d add in the messageUI after I’d done the complicated part (I’m also using this app as an exercise in animating with the CoreAnimation framework so I’ve had a lot of learning to do). Unfortunately, the entire flow of my app as it stands depends on me being able to intercept the email before it is sent. Which I would have known was impossible if I’d just taken the time to look it up.

So I’m rethinking (late in the game again) – how can I keep the general idea intact and still make it a useful app? Updates to follow…