Category Archives: design

Designer founders

Posted by on 21 March 2012 12:54 4 comments

Don Dodge tweeted today:

Most important hire in a startup? Designer. Better if one founder is a designer.

The Design Fund has an excellent infographic about successful startups whose founders have been designers. This is the reason having a designer as a cofounder is so important:

Now, more than ever, we face complex problems that designer founders with professional craft have the opportunity to solve by facilitating design behaviors with the rest of their team, thus inspiring everyone to have creative confidence and apply design thinking collaboratively. The whole company should practice empathy, not just designers. No longer can design just be an outsourced add on, limited to occasionally putting “lipstick on a pig.” Tech moves so fast that it’s a continuous process of iteration for designers to prioritize solving the right strategic problems, contexts and use cases for their company to prosper.

It’s about culture.

I’m an engineer; design is not my forte. But I understand the critical importance of the user experience to the success of a product. I’m in the middle of reading two design books right now, and I hope to make the study of good design a long-term pursuit, even if I never become an outright designer.

The trouble is, software engineers are still the ones who build systems. We need more technical people with design sense, just as we need design people with technical breadth.

The BYU Computer Science department has a user interface course, but it’s a dismal excuse for teaching design. I’m pleased that the Information Technology major has a User Experience & Human Computer Interaction emphasis. They are on the right track.

The CS department trains people to be great coders, but it’s not giving them the skills they need to be successful as entrepreneurs (where design sense is critical) or in companies where the culture of design is central. Self-study is always an option (one of which I’ll avail myself), but I want to see software engineering curricula teach design as an integral part of the engineering discipline.

Alarm clock design

Posted by on 10 October 2009 23:21 2 comments

The last few days I’ve found myself waking up later than I plan, despite all my good intentions. And despite setting my alarm.

Aside from the fact that I really just ought to drag myself out of bed when I know I want to get up, I’m beginning to think my alarm clock (which is actually my cell phone) isn’t really fulfilling its purpose. We’ll put the blame on that device for the sake of argument.

What is an alarm clock for, anyway? It’s supposed to wake me up at some predetermined time (presumably a time I have selected). But in reality, all my alarm does at the moment is just beep at me. I invariably am too tired to get up when it goes off the first time, so I hit snooze, the button directly under the screen on the left. My phone faithfully plays it’s annoying little melody exactly five minutes later. And usually I hit snooze again.

In theory, I’ll eventually get tired of hitting snooze and just get out of bed. But I also don’t want to annoy my roommate with the incessant repetition of that lovely little tune. So I hit the “stop” button, which is directly under the right side of the screen. And I go back to sleep.

Somehow I seem to unconsciously know exactly when I will have to get up in order to have just enough time to shower, eat breakfast, and run to class. So a large percentage of the time I really do wake up “on time.” But the fact remains that the alarm clock is failing in its purpose.

First design flaw: The button to turn off the alarm is rather close to the button that just snoozes it. More than once I have accidentally hit the “stop” button, fully expecting the arousing tune to play again in five minutes. It doesn’t, and I disgruntedly scramble out of bed half an hour later and glare at the contraption. The point: Even if I’m sleepy, I shouldn’t be in danger of shutting down the alarm clock when all I really want to do is have it wait five minutes.

Second design flaw: Now this is the one that I don’t know how to fix. The purpose of the alarm clock is to get me out of bed when I had planned. All my phone does is beep at me and presume that I’ll take care of the rest. I have seen a few creative ideas (an R2D2 noisemaker, a helicopter, and an air-compressing bed-shaking wonder), but I don’t know that those are what I’m looking for.

I’ll keep thinking….

Monocline grouping

Posted by on 10 September 2009 21:19 3 comments

The discussion on my previous post has necessitated a better explanation of the term monocline grouping.

A monocline grouping is a representation of data in a single layer (i.e., without a nested hierarchy). Let’s take my bookshelf for example. I have on the left religious books (including a few music books), followed to the right by Dutch and German books, and continuing on with literature and poetry books. And there in between are a few books that don’t really fit into one of those generalizations. And sometimes I’ve rearranged them out of their groups so they look nice on the shelf.

This is a very natural and understandable way to organize them. I can esaily access any book at any time, even if I’ve forgotten (or don’t care) which category I’ve placed it in. All the books are arranged in a single layer.

The problem with computer hierarchies is that they allow the user to nest objects of a certain type within objects of that same type: you can have an infinity of folders within folders which you must traverse before you come to a file.

Programmers understand this paradigm just fine; they have no trouble with it. But normal human beings are used to having things in monocline groupings. Even my file box is only one level deep: I open the box and there are all my folders. I don’t have another file box within that file box. (Now I do have manilla folders inside hanging folders, but the point is that I can see them all at once.)

Monocline grouping, as far as I can tell, is a term created by Alan Cooper, and it’s not very widely used by people not acquainted with his ideas. However, the concept is universal in its application.

As I mentioned in my comment (and as is mentioned on this blog post, a quote from Cooper’s book About Face 2.0), monocline groupings are not the end-all solution for everything. They can be very useful when applied with prudence.

Eliminating the hierarchy: GNOME Do and Google

Posted by on 7 September 2009 22:51 4 comments

This week I became acquainted with two applications: GNOME Do and Google Chrome.

GNOME Do is a program similar in concept to the Mac Spotlight. Although not quite as simple as Spotlight, it still allows you to find files, launch programs, and even search Gmail contacts.

GNOME Do and Spotlight both illustrate a concept Alan Cooper addresses in The Inmates Are Running the Asylum. (See my recent post on this book.) Cooper suggests how incredibly confusing hierarchial filesystems can be to users (see, e.g., pp. 9-11). Humans don’t think of file storage in a hierarchial way. When you’re writing something on a pad of paper, you might tear the sheet off and leave it on your desk. Or you might put it in your file drawer. That physical drawer has an advantage over a computer’s filesystem–it is much easier to see and comprehend the whole thing at once. You open the drawer and see all the folders inside it all together.

Now imagine your computer’s filesystem. You just wrote something on your virtual pad of paper. You “tear off” the page and want to put it somewhere. You click Save As…, and it opens to your usual My Documents folder. You put the file there and forget about it.

That isn’t so hard to deal with until you have to dig into the hierarchy of your hard drive. Imagine that you want to locate a file you worked on six months ago. It was a poster for the company barbeque you had in the spring, and you need it again. But where in the world did you put it? How are you going to find it now?

You could start clicking through all the folders on the hard drive until you find it. Or you could use a tool that eliminates the need to comprehend the hierarchial file structure in the first place, such as GNOME Do or Spotlight. Or the Windows search, if that’s the best you’ve got….

Those programs will let you search the file name or (more understandable for a human user) the full text of the file. Once it finds possibilities, you’ll still probably have to wade through a disorganized list to find the actual file. But at least you didn’t have to click through a hundred folders to get to it.

Google does a good job of implementing non-hierarchial file systems in their web apps, such as Gmail and Docs. You simply have lists of things, which you can further organize them with labels (and even use the labels as a sort of file-folder system if you really want to). And full-text searching is a standard, simple necessity.

Google Chrome also does an excellent job eliminating the hierarchy from the web browser: it has very few menus; your address bar, history, and web searching are all in the same box; you open a new tab and see a list of your most frequently-visited sites. No searching through menus of bookmarks or a confusing history pane. Just type in a keyword and it finds it for you.

After all, the computer knows where everything is anyway. Why not make it find things for you?

Inmates

Posted by on 4 September 2009 20:45 No comments

I’m in the process of reading Alan Cooper’s delightful book The Inmates Are Running the Asylum. Cooper discusses the reason computer software is often so difficult to use. His main thesis: when programmers design software, they do it in a way that fits how the computer operates, not necessarily how a human being operates. It makes sense to them, but not to the average end user. This makes clear the need for so-called interaction design, as opposed to interface design. In order to be truly effective, this must be done by dedicated interaction designers, not by the programmers. The reason for this lies in the simple difference of how programmers think about problems and how normal people think about things. (Being a programmer myself, I can tell you that programmers really do have a different way of seeing the world. That view often doesn’t mesh with how normal people see the world.)

Cooper’s book dates from 1999. Things have changed in the realm of software interaction design since then. But he notes trends of the day that are still obvious in current software development. In chapter 5, for example, he discusses the concept of customer loyalty. He argues that Microsoft’s Bill Gates had tremendous business prowess and, as such, was able to get his company’s products to sell, imperfect or unpleasant to use as they may have been. People bought his things because they provided solutions for the problems they faced. They were driven by “economic necessity,” as Cooper puts it (p. 75). But as soon as something better comes along, the customers’ disloyalty will become apparent. They will be willing to switch to those better products without suffering withdrawl from their emotional attachment to Microsoft. Apple, on the other hand, has always had an eye for design. Their products were and still are attractive, and Apple has an incredibly loyal consumer base. Just think: how many people do you know who sport an article of clothing, bumper sticker, mug, or other object advertising Apple to the world? And how many people have you seen with similar products from Microsoft?

I believe that companies like Apple and Google have done much to drive innovation in the field of interaction design. Just think of the iPhone. How many smart phones have been developed in the last two years that look or act like the iPhone? A staggering number. But who thought of having such an intuitive, tactile touch screen before Apple did? And what mainstream email program is there that groups communications into threads besides Gmail? (If there really is one, please correct me.)

It’s issues like these that Cooper addresses in his book. I would highly recommend it to anyone desiring to improve the usability of their software. His current consulting company also has a blog discussing these topics.

Usability, the iPhone, and Fitt’s law

Posted by on 5 July 2007 16:25 Comments Off

I just read a great iPhone usability review on the Humanized Weblog. Interface design interests me, and Humanized has a ton of really cool ideas for creating humane, usable, intuitive interfaces.

Also on the post was a discussion on Fitt’s law and the way Apple designed multi-level lists on the system. I found a link on the Wikipedia article to a Microsoft blog discussing the implications of Fitt’s law in interface design for Windows and Microsoft Office.

Very interesting reads.