Tag: software engineering

Posted on

Train yourself in frustration, confusion, and inefficiency

For professional reasons, I like to mess around with software. It’s a form of training, because some of the messing around leads to frustration, confusion, and inefficiency. And that’s good.

My hope is that my experiences will help me to better understand what I put various groups of software users through when they use the software I helped design and build.

An easy way to mess around is by changing default settings. For example, my iTunes isn’t set to English. This helps me understand the experience of users who learned one language at home as children and now use another language at work as adults. It’s not just beneficial to experience the initial pain of memorising where to click (as I become a rote user in a GUI I cannot read), but also the additional moments of frustration when I must do something new—an occasional task whose command vector I haven’t memorised.

Relating to the language challenges that some users face

Another easy way to mess around is to switch between iMac and Windows computers. It’s not just the little differences, such as whether the Minimise/Maximise/Close buttons are on the left or right sides of the title bar, or whether that big key on the keyboard is labelled Enter or Return.

Switching between operating systemsIt’s also the experience of inefficiency. It’s knowing you could work faster, if only the tool weren’t in your way. This also applies to successive versions of “the same” operating sytem. This is the frustration of the transfer user.

It’s noticing how completely arbitrary many design standards are—how arbitrarily different between operating systems—such as the End key that either does or doesn’t move the insertion point to the end of the line.

Another easy way to mess around is to run applications in a browser that’s not supported. I do it for tasks that matter, such as making my travel bookings.

All this occasional messing around is about training myself. The experiences I get from this broaden the range of details I ask developers to think about as they convert designs into code and into pleasing, productive user experiences.

In a separate IxDA discussion thread, a few people reacted to this blog post:

  • Try a Dvorak keyboard instead of a Qwerty keyboard (Johnathan Berger).
  • Watch children’s first use of a design (Brandon E.B. Ward).
  • Use only the keyboard, not the mouse (CK Vijay Bhaskar).
  • Sit in at the Customer Support desk for a day (Adrian Howard).
  • Search Twitter to find out how people feel about a product (Paul Bryan).

See also the comment(s) below, directly in this blog.
Posted on

Design and engineering culture

I’m sure Douglas Bowman’s blog last week was widely read. His post was a kind of public exit interview, titled Goodbye Google.

Goodbye GoogleAs Bowman left Google, he pointed out the pro-engineering bias in its approach to problem solving—including problems of design. Two of several examples he gives:

[…] a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. […]

Bowman would like to see more weight put on design principles. His blog includes a link to Wikipedia’s article on design elements and principles, which lists:

• unity • harmony • contrast
• balance • repetition, rhythm, pattern • variety, alternation
• emphasis, dominance, focal point • proportion, scale • functionality
• attraction • artistic unity • genuineness in media and form
• proximity • colour    

I don’t think design principles are beyond an engineer. I do think engineers need to be taught how—and when—to think about these details.

As we discovered during the development of Five Sketches™, this kind of detail is often outside the comfort zone of an engineer. However, I can affirm that even engineers who initially produce work with little design insight or creativity have managed to astonish me with amazing design results within a year. And that’s after only occasional participation in Five Sketches™ design sessions.

So, yes, engineers can learn to participate in design, with success and predictability, though I would caution that Five Sketches™ works for engineers because it was developed for and with them, to meet their needs.

At Google, to bring about such a cultural change, Bowman would have needed the unwavering support of at least one senior executive. Even then, as Bowman himself acknowledged in his goodbye message, a company as large as Google does not change direction easily.

If you liked this post, read about how a company’s use of social media influences its corporate culture.