Posts tagged “software design”

Monotasking

Sometimes a seemingly minor interaction has a big impact.

At Black China Cafe in Santa Cruz, a small rock keeps napkins in place at the coffee station. With a cup of coffee in one hand, getting a napkin means picking up the rock, putting it down somewhere, picking up a napkin, and then putting the rock back in place.

I had just been thinking as I walked to the cafe about how hard it’s become for me to do something simple like walk across a parking lot without simultaneously jumping on my phone and checking my email, Twitter feed, etc.

I like being able to get lots of things done while I’m mobile, but at times I do this even when I don’t need to, and it starts to feel like a compulsion to multitask. Coming out of that context, the focused attention and step-at-a-time-ness of this little rock/napkin moment at the cafe shifted my whole pace of being.

Interaction design has always talked about temporal elements like pacing and pause. In their book, Interaction Design: Beyond Human-Computer Interaction, authors Helen Sharp, Yvonne Rogers, and Jenny Preece present a case study in which software testing showed adding pauses to a particular interaction would benefit users, and discuss some of the engineers’ reaction to this finding:

To make these changes would require adding additional menus and building in pauses in the software. This conflicts with the way engineers write their code: they are extremely reluctant to purposely add additional levels to a menu structure and resist purposely slowing down a system with pauses.

Right now, human/device interactions commonly involve waiting impatiently for our things to do what we’ve asked them to, and faster processing is often a goal. But as technological capability increases and our devices become faster than we are, I wonder if it may become increasingly necessary to also think about purposely slowing down elements of an interaction to create a different user experience – a’la the napkin rock – that is more aligned with “human-speed.”

You Say You Want a Revolution . . .

Alan Cooper spoke earlier this week at a meeting of the San Francisco Interaction Design Association chapter. Cooper talked about programming as a craft, and Interaction Designers as potential facilitators of that craft within the business world.

Cooper is advocating what he calls an “insurgency of quality,” which he describes as being about how software design and production processes can and should be evolving-specifically, increasing the time spent refining products before they’re released as “finished.”

It’s an old carpenters’ adage to “measure twice, cut once.” The current software production model Cooper is speaking out against might be described as: measure once, cut once, ship once, repeat all steps for version 2.

Based on the insurgency Cooper is advocating, in which Interaction Designers and Programmers would take more time to get it right before a product goes to market, the development model would become: measure twice, cut twice (e.g. validate and iterate), ship once. The idea being that what gets shipped would be of higher quality then what generally gets produced in the current way, which prioritizes time-to-market.

We work with a lot of clients who are operating within very tight timelines. I’d be curious to know what kinds of successes and failures Cooper and his firm’s consultants have been having with their clients in trying to implement this new development model on actual projects. Are the Cooper folks finding that client organizations are ready, willing and able to add more development time to the front end? If not, what kinds of strategies are working and not working in trying to encourage that kind of change?

A lot of theoretical revolutions break down or dissolve when they meet real world complexities and constraints. It would be great to have some stories detailing how the ideas Cooper is advocating are getting played out in real project engagements.

Series

About Steve