disambiguity

Economist/Drupal – Sprint 2 Demo (CRUD-in-place)

Drupal/Economist Project – Sprint 2 Demo from Leisa on Vimeo.

Today is Demo Day at The Economist, where all the various SCRUM teams will show and tell what they’ve achieved in their latest iteration. I thought I might see if I can get into the habit of pre-recording my demo so I can share it with you here and ask for feedback & advice! So, here we go!

In the past two iterations (this project runs on 1 week iterations) we’ve done a combination of research, design and testing the publishing tools that the editorials staff will use to administer what is known as the ‘Channel Index Pages’ – these are pages that you’d land on if you clicked something in the navigation that said, say, Business & Finance, or Science & Technology, and their job is to pull the most interesting current content to the top so that readers can access it more easily.

These pages are made up of a range of elements, most importantly for this demo are News Packages (consisting of a lead story and related stories/media files) and what is known as the Bloggy Chunk (an editable text area that section editors can freely input their own content, it is still very much a work in progress and is variously used as an aggregator for recent interesting stories that The Economist isn’t covering in depth or to highlight interesting reader comments, it may in the future show content from an RSS feed).

Although working within the SCRUM methodology, I am trying to take a systemwide approach to the design as far as possible, so there has been a whole range of questions that I’ve had to consider that aren’t strictly in the ’stories’ for our sprint (logging on, activating editing, for example), and similarly, I’ve tried to devise interaction approaches that will be reusable across the other parts of the system that we have yet to design rather than just customising the design approach to this individual problem set.

The design approach shown in this demo is still quite lo-fidelity and ‘broad brushstroke’, it will become much more precise over time, at the moment my priority is to try to work through and communicate the ideas as quickly as possible – giving me more time to explore a range of approaches, and to iterate approaches which has been very valuable.

So, if you have a moment and are so inclined, I’d really love to get your thoughts on the approach we’re taking so far. We’re also about to embark on starting some development work on this – to make sure we can build it in Drupal without too much difficulty – so if anyone has any guidance on how best to approach this, modules we should take a look at, anything else you think we might need to know, I’d love if you could share it here!

Look forward to hearing from you and thanks in advance!

(apologies to anyone who saw the first version of this blogpost with the screwy audio synching)

More from Disambiguity

• Economist/Drupal – Design Principles for CRUD-In-Place
• Economist/Drupal – Complex Editing In Place
• Economist/Drupal Publishing Tools – Sprint One Update!
• Drupal.org – Initial thoughts on the Information Architecture
• Why is D7UX.org on WordPress (not Drupal?)

On documentation (or lack thereof)

I was talking to someone recently about doing some work with them. They said ‘can you send me some examples of documentation you’ve done lately’ – they wanted this to check that I could do what I said I could. Fair enough. Except, aside from the fact that all the documentation I’ve done lately is commercially confidential, so I’d have to hack it around a little to be able to show it to someone else… it made me realise how long it’s been since I’ve actually done the kind of ‘finished’ documentation I used to spend a lot of my time doing.

I just don’t work that way anymore, it seems. Sure, I still do wireframes every now and then, but never a ‘complete set’ and often with no where near the detail I used to include. Why? I think there are three reasons. Firstly, I tend to work on more of a strategic level than a detail ‘exactly where does that button go’ level these days. Secondly, I tend to work on projects where there is no time for that level of detail. And finally – and most interesting I think – I tend to work closer to the production team these days – more often are graphic designers designing and/or developers developing the very same stuff I’m wireframing at the same time. Investing too much in the documentation is a waste of everyones time – much better to do just enough to get them going and then work collaboratively with the team to do the fine tuning.

Personally, I think I should have been working more like this since forever.

Does any of this sound familiar?

More from Disambiguity

• thoughts on the less intentional profile
• Client-Centred Research
• Guerrilla Research – Recruitment
• advertising?
• heart stoppingly bad user experience

‘I can’t work this!’ – iPhone’s cameo in Sex In The City Movie

Yes, I’ve seen the Sex In the City Movie, I’ll admit it. Either the rest of the UX community hasn’t seen it yet or we’re all just ignoring the fabulous user experience moment that Carrie has with the iPhone. For those who haven’t seen it, she is handed the iPhone (not hers) at a time when she urgently needs to make a phone call. She looks at it briefly, pronounces ‘I can’t work this’ and asks for a proper phone.

Unsurprisingly, Gizmodo reported it this way: ‘Confirmed: Carrie Bradshaw is too stupid to work a iPhone‘. Very helpful.

Personally, this was my favourite part of the whole movie (which says more about the movie than it does this particular moment). I loved the fierceness of her reaction to the unfamiliar interface.

It reminded me again that those of us who are ‘into’ interface design are really a fairly small group and how important it is for us to remember that the vast majority of people who encounter our interfaces do so on the way to achieving a task – sometimes one that is urgent and very important to them.

The people who encounter our interfaces in that kind of moment are not going to find them interesting, but an obstacle. And that they won’t take the time to ‘explore’ and ‘enjoy’ and ‘learn’ our amazing interface design.

It would be easy to say that SJP’s encounter with the iPhone showed that it lacked ‘usability’, but in fact it is probably more instructive as to the importance of evaluating usability over a longer term than just a one hour session in a usability lab. As I’ve said in the past, if something like the iPod, and no doubt the iPhone had been ‘usability tested’ using the traditional methods, they no doubt would have ‘failed’ and the world would be poorer for it.

All these things I had to think about because the movie was so disappointing… (speaking of bad UX).

More from Disambiguity

• Checking in from SXSW
• Did I mention I’m freelancing? (or, coping strategies from the dining room desk)
• getting real.. with clients? (can agile methodologies work in agencyland?
• Vodafone UK redesign – clean and simple on the surface, but it ain’t necessarily so.
• Opening the floodgates! How to participate in the Drupal.org redesign project

The Halo Effect – Why Apple gets away with rubbish interaction design

As have many others in the past year or so, I recently swapped from PC to a new MacBook.

It certainly has been an experience, and it’s nice to actually have something to take out of my bag at conferences that looks so cute, that doesn’t make that embarrassing Window’s startup sound, that has a half decent battery life and that doesn’t take half a century to boot up. (My old laptop was generally out of battery by the time it finally booted, making it all but useless in conference environments anyway).

It has to be said though, that when it comes to interaction design, there are quite a few examples where the Mac falls short of my old PC.

This is not a post about the things that Apple does badly though (although, seriously – can we get past the one button mouse already? and I do think that dialog box is pretty shocking, and those little triangles that so often hide much of the information I’m looking for in Mac applications…. please!). This is a post about what Apple does well, and how this helps them get away with doing some things not so well.

As a general rule, Apple does a brilliant job with design. Highlights include the iPod, their in-store experience, the ‘out of the box’ experience, and the product design for most of their computers.

Enter, the Halo Effect. The Halo Effect is a Cognitive Bias (something our brains do that kind of tricks us or is a bit lazy, but also makes us more efficient than, say, computers). This particular cognitive bias means that the impressions we already have of someone or something colour how we perceive their current and future actions. Or, in Wikipedia speak ‘the perception of a particular trait is influenced by the perception of the former traits in a sequence of interpretations.’

So, all of Apple’s good design work of the past influence our perception of other design work we encounter. It also influences our reaction to things like, say, their customer service once you’ve bought their product. In some instances, some of these traits are not so desirable, but because of the great positive association we have between Apple and design, we are almost blinded to the fact that they’re not really delivering to the standard we’ve come to expect.

This accounts for the effect that new Mac users would be familiar with whenever they dare complain about something that Apple has designed – the almost-killer-attack of long term Mac users who seem to be almost blind to the idea that there may be something imperfect about a Mac!

OK, so that’s an exaggeration. But I bet you know what I mean

The Halo Effect and attractiveness are also closely linked, meaning that we are more likely to imbue attractive things with positive traits than we are less attractive things. Thereby, simply by virtue of the fact that my MacBook looks a whole lot more attractive than my now retired ThinkPad, I’m more likely to attribute it with traits like good interaction design… even when there may be much evidence to the contrary.

We can learn a lot from Apple and the Halo Effect though. If our company or our product becomes associated with good design over time, and if we design attractive products, then our customers will not be waiting to savage us when, in the future, we slip up a little accidentally. Quite the opposite – investing in good design now is almost like investing in a margin for error in the future. And couldn’t we all do with one of those now and then.

Meanwhile, next time you are attacked by rampant long-term Mac users, play nicely.

They may get a little over enthusiastic at times, but that’s just their cognitive bias talking

More from Disambiguity

• Will anthropomorphism decline with the rise of social software?
• design is a good idea (on ugliness, with some thoughts on the DesignGuys Craiglist ‘realignment’)
• mobile: user interface design – the great frontier
• Are you giving accessibility the consideration it deserves in the user experience?
• Sphere (Review): Hidden treasures, 2.0 Orange & the perils of style for design agencies

Dialog Boxes: Making simple things simple…

How much thought do you give to writing the text on dialog boxes when you’re designing?

It’s fairly common for these to be written by the developers as they’re being coded, from what I’ve seen. They certainly deserve a whole lot more attention than they generally receive.

Here’s a prime example.

Notice the text that has been bolded. It’s asking me a question ‘do you want to allow the new version to access the same keychain items (such as passwords) as the previous version?’.

Is it just me, or are the obvious answers to this question either Yes, or No. Yet this dialog box presents me with the options ‘Don’t Change’ or ‘Change All’. To which my immediate response is… Change What?! I have no idea what you’re talking about.

Let’s ignore the fact that, hypothetically, I have pretty much no idea of what a keychain item might be, the next line of text reassuringly tells me that whatever option I end up guessing at is permanent and affects all keychain items used by Adium.

OK. So here’s what I know… whatever choice I make here is pretty important and not able to be undone… and yet I know little about what the question is and pretty much nothing about what the options represent.

Not a pretty situation considering I was just installing an update to my IM application.

Potentially enough for me to bail and go install another application instead? Maybe.

It’s in the details people.

[Note: Yes, I've heard that Adium is the best IM client for Mac. I'm sticking with it for the time being.]

[Another quick note: how much do I *hate* the way that Mac software uses that little triangle on it's side to represent 'if you click here, a whole stack of functionality that you *really* need but have no idea where it is, will be revealed. Who thought *that* was a good idea? It has caused me grief over the past couple of weeks... even *after* I learned its meaning. End of moaning.]

More from Disambiguity

• blogging milestones (2 months)
• boxes and arrows (10 ways that packing up a house is like doing information architecture)
• Podcasts are boring (Hot tips to hold attention)
• iPhone – now *this* is a revolutionary interface
• On documentation (or lack thereof)

Design Consequences: A fun workshop technique for brainstorming & consensus building

For my recent BarCamp session I shared a design technique that a colleague and I developed quite recently that we’ve found to be quite successful in both generating great design ideas and developing consensus about the design approach for projects within a multi-disciplinary team.

We call this technique Design Consequences, due to the similarity it has with the similarly named childrens games. We tend to use it in the earlier stages of the design process, although it can be used for more detailed interface design problems.

So, how does it work? It’s pretty simple really.

What you need:

1. a clearly articulated design problem and design goal(s) - for the BarCamp exercise our design problem was to design an electronic version of the BarCamp session wall where people could add their own session and choose which sessions they were going to attend. 
2. some design ideas or components – when I do this in a client context, we do this by spending time beforehand looking at our specific challenges and seeing how other people have approached them, and trying to understand design techniques or principles that work (as well as those that don’t). This gives people access to a much greater repoirtore of ideas to draw in the Design Consequences exercise.
3. a multi-disciplinary team - try to get the entire team if you can. The exercise works best with no more than 8 people involved, but it can be done with more if required. Get management to the table, bring all kinds of designers, bring the product managers and marketers, bring your developers. Bring everyone you can, as long as they’re familiar with the project and the design problem.
4. lots of paper and markers and post its – make them as colourful and fun as possible. Make it look like a crafting session. A sense of play and enjoyment is key to this exercise.
5. some examples of the type of output you’re expecting – anything that starts with the word ‘design’ can be very intimidating and scary. Lots of people ahve been told throughout their lives that they can’t draw, or that they aren’t creative. I have some *very* scratchy samples that have been created by people who design for a living. I show these before we get started so that people realise quickly that pretty drawings are not part of the equation.
6. A bundle of energy – you need to be just a little bit hyper to run this exercise

What you do:

1. Round One – everyone has seven minutes to design, individually, the the first page that users would see when confronting the ‘design problem’. So, a typical example would be a website homepage, but it could be any part of an application or website or even, say, an email. The faciliator(s) should participate, but keep an eye on the clock and give some warnings with a few minutes to go, and again at about 30 seconds.
2. Round Two – here’s the consequences twist. Everyone picks up the page they’ve designed, then passes it on to the person on their right (or left, it doesn’t really matter). Everyone then has to review the page they’ve received (ask for clarification from the original designer if it’s a little sketchy in places), then decide – if you were the user, what would *you* interact with, and what would happen next. You have seven minutes to draw ‘what happens next’. (Don’t tell people about Round Two before Round One, it’s much more fun when it’s a bit of a surprise).
3. Show and Tell – we then go around in a circle and each person describes the page they received, what aspect they chose to interact with and why, and then describes what they designed next. Discussion is encouraged.

What do you get? Lots of great data, and lots of great conversation fodder.

It’s a good idea to capture as much of this as possible as you go around the group. Of course, the best way to do this is to write up ideas onto post it notes as you go and stick them on the wall. There should be an ‘in’ section of the wall and an ‘out’ section of the wall. (’In’ means that the idea has legs for this particular design problem). Affinity sorting on the run also helps to draw out the key themes or ideas that have emerged from the exercise. You should be leading the group discussion, helping the group to gain consesus and make decisions as to the design approach to be taken in solving the design problem, and trying to document these decisions as you go.

This process can be quite time consuming and intense, but more often than not there will be a few key ideas that the group is particularly enthusiastic about and that really propels the decision making.

By the end of the session you should be in a position where everyone is in agreement about *what* will be included in the wireframes that comprise the next phase of the design process.

Why would you use this approach?

• It makes a great change from the talk-fest of meetings
• It generates lots of ideas – and often some really great ones 
• It stops people getting to attached to their design ideas and makes evaluation and critiquing more effective
• It helps get all the team feedback and ideas into the pot (in particular, it’s great to get management and technical input at this stage)
• It drives buy-in, involvement and consensus
• It pulls in cross-discipline scills (for example, developers are often really great at quickly identifying great ID approaches for Rich Internet Applications)
• You’d be amazed what you learn earlier rather than later by involving the entire team at this early stage
• Getting lots of brains involved in the design process can uncover some really creative gems
• It makes the design process faster
• It’s fun!

So, there you have it. Some quick notes on a technique that’s been quite useful for me lately. I’d be interested to hear what you think of it and if you try it, to see if you too find it useful.

More from Disambiguity

• dConstruct – Collaboration, Creativity & Consensus In User Experience Design Workshop
• D7UX Update: Initial Concepts, Design Principles and a question for you
• design is no place for democracy (things we learned from the drupal.org project)
• ActNow Launches (2.0 for good not evil)
• Economist/Drupal – Design Principles for CRUD-In-Place

Chatting with Bill Moggridge – Part Three – What makes a good design team?

This is the third and final part of my chat with Bill Moggridge in which we talk about the ingredients of successful design teams – who is in them, how do they work together, where do they work, those kinds of questions.

This was a chat I recorded when I was talking with Bill about his new book, Designing Interactions.

You can catchup on the first two parts of the chat here: Part One / Part Two

Enjoy!

(Duration: 10:28)

Chatting with Bill Moggridge – Part Two – What Interaction Designers can learn from games

Here’s the second part of my chat with Bill Moggridge.

You might remember that I was lucky enough to have the chance to talk with him about his new book, Designing Interactions and that he was happy for me to record the chat and share it with you. Here’s Part One in case you missed it! (update: you can get part three here too!)

As you can see from my microphone stand pictured above, I am a very professional correspondent and go to any length to ensure good sound quality.

(Clearly this is a blatant lie… I’m working on it!)

Anyway – in this second part of the chat we spend some time talking about designing games and what interactions can learn from games design. Interesting stuff.

(Duration: 5.49)

More from Disambiguity

• Chatting with Bill Moggridge – Part One
• links for 25 August 2008 – What games can learn from social software
• Fun & Games (and a new superhero!) for World Usability Day!
• great error msgs (part 2 : wordpress)
• links for 25 January 2006 – Agile Interaction Design

Chatting with Bill Moggridge – Part One

In December last year I was lucky enough to catch up with Bill Moggridge to chat about his new book, Designing Interactions.

My mission was to write a piece for Usability News (mission accomplished).

I recorded our chat and Bill was happy for me to share it with you all, so – apologies for the not so great sound quality – I hope you enjoy it!

In part one Bill talks about the process he went through to design/write the book (yes, there was a prototype involved!) as well as some thoughts on what factors are common where good interaction design is created.

(Duration: 10.02)

update: also check out Part Two (5.49) and Part Three (10.28)

More from Disambiguity

• Chatting with Bill Moggridge – Part Two – What Interaction Designers can learn from games
• great error msgs (part 2 : wordpress)
• Platial – mashup with meaning
• links for 05 December 2006 – recent reviews of Bill Moggridge’s ‘Designing Interactions’
• What are you doing about diversity?

Some kinda visionary (on gestural interfaces)

“Just as water, gas, and electricity are brought into our houses from far off to satisfy our needs in response to a minimal effort, so we shall be supplied with visual or auditory images, which will appear and disappear at a simple movement of the hand, hardly more than a sign.”

Paul Valery, 1931.

cool.

(thanks James)

More from Disambiguity

• links for 22 March 2007 – Design Patterns on Flickr
• links for 22 April 2007 – Notes on the washing machine
• links for 03 June 2006
• links for 18 October 2006
• links for 12 November 2006