(If you’re reading this from a feed reader, you’ll want to jump to my site so you can see the images.)

Today I want to talk about something a bit academic. More of a thinking game than anything else. I chose to start with Graphic Design because, well, it seems a bit more established as a field than Interaction Design and I think there’s a lot we could learn from them.

In two-dimensional graphic design, a core set of elements have been defined to specify the designer’s most basic toolset. These three elements can be combined to create a rich array of visual objects that give the designer near limitless options. Let me explain visually:

Consider the Point

A Point simply denotes a position in space. Many points in space can show contrast, and from an appropriate height will tend to show texture. This is the most basic of the basic graphic design elements. But oh so much can come of this simple dot.

Many Points Make a Line

If a Point is made the first time a piece of chalk is touched to a chalkboard, then a Line is created as that chalk is dragged across the surface. That Line is an infinite chain of Points, or the connection between two starting and ending points.

Lines create Shape

Moving the chalk perpendicularly to the original line creates an intersection. Multiple intersections eventually create shape. That is, when multiple Lines are strung together, they take Shape. Shape is where we begin to embrace the power of visual imagery. People will create meaning out of multiple shapes strung together, and the meaning that is elicited is the core goal of Graphic Design.

Where are my elements?

Of course, this is by no means all a Graphic Designer must know to be successful. This is just the start. In Part 2 of this series I’ll consider Dan Saffer’s Elements of Interaction Design. Prepare yourself for that.

The last few days I’ve been reading Richard Florida’s Who’s Your City? In this book he talks about how populations centers have changed since the rise of the creative class. For the most part, Florida refutes Thomas Friedman’s theories in The World is Flat. Florida believes that where you live still matters, despite today’s advanced communication technologies. I definitely agree with this thesis. One can only do so much over a phone or internet connection. I have had my most rewarding moments in the workplace when I am able to sit and think about something with a coworker on a shared whiteboard.

Florida’s site has a Place Finder survey that attempts to rate which cities you should consider moving to. Here are my results:

1. San Francisco, CA
2. Chicago, IL - My current residence
3. Tel Aviv, Israel
4. New York, NY
5. Los Angeles, CA

I’m not so sure I agree on all counts, but it is quite an interesting result. One that I wasn’t expecting.

Of course, the survey is all self-report, so it’s definitely bound for some level of error. But still…it’s interesting to think about: in this ever so mobile era, where will any of us live a year from now?

If you’d like to take the survey, you can do it right now! Check it out:

Banana = Vision

Love it or hate it, Bruce Nussbaum makes some great points in Are Designers the Enemy of Design? I think I buy most of it.

Is Design a specialist activity? If it’s done well, generally yes. Is that likely to change? For the most part, I don’t think so. Will ‘the everyman’ have the opportunity to design more and more in his lifetime than ever before? Absolutely, so we better start learning how to share Design Strategies.

Also, can Apple move past two major strikes (closed source everything and unsustainable products) and really survive the long haul? I just don’t know anymore.

Anyway, have a read for yourself…

Update: Sorry about the dead links…I think they should be fixed now.

November is NaNoWriMo! (Translation: National Novel Writing Month) Will you be participating? What shall you write about?

Will I participate? How hard could 1000 words a day really be?

Hey ThoughtWorkers,

So at TWU we learned about a ton of different ways to test software: Unit Tests, Functional Testing, GUI Testing, etc. Here’s my question:

What’s the point of a tested tool that the user (or perhaps customer, if you prefer) finds difficult to actually use? What about Usability Testing? How about testing to see if your deliverables meet the problems found during analysis? Where do these kinds of testing come in?

Sincerely,

Josh

When I came to ThoughtWorks University a little less than a month ago, I set as my main goal the task of discovering what kinds of User Centered Design practices were occuring at ThoughtWorks, and how I could help progress those tasks. After two blazingly fast weeks of class, I’ve learned a lot, hopefully taught a little, and have come to this point surprisingly impressed at the user-centric ideas that shine through in the lessons here at TW, and possibly in Agile Development in general.

Many of the analysis techniques in use here align closely with a number of standard HCI practices. For example, last week we were taught a lesson about how to best gain knowledge about the organization, business process, and/or needs of the client. The lesson reminded me so much of Contextual Design, an analysis and design methodology that has been around the HCI field since the early-1990s, which makes it quite ancient in the field. I was completely staggered to learn that the lesson was not based on CD, and even more surprised to learn that the trainer had not heard of it at all.

Further lessons have discussed External Cognition (pdf link), process modeling, and interview techniques that would make most HCI-designers proud. We’ve also learned about how to incorporate Personas and Scenarios into our analysis work. Not to mention the fact that user stories, which guide the development of specific software functionality, are based directly on user needs (as mentioned earlier).

The fact that these practices are built directly into the system is uplifting for an Interaction Designer like myself. Now, I take it as part of my responsibility to point out when these known techniques are used, teach people their formal names, and discover how we can further leverage their strengths, while being aware of their weaknesses. Of course, it’s also important to add new tools to the TW toolkit, which I plan on doing.

So far, though, I am impressed by the User Centricity of the processes here at ThoughtWorks. Score one for the users.

As noted in my first agile worry, I am often scared that features of a given piece of software will be built based on reasons other than user needs. Yesterday I learned that story cards are, indeed, quite user centered.

The format we learned for creating a card is as follows:

As a [ person ]
I’d like to [ action ]
so that [ reason for action ]

This card is used as a discussion piece with clients, and is eventually used by developers to create particular functionality.

What excites me most about these story cards is the fact that right at the start, a person is identified for whom the functionality is important. This means that one cannot simply create a story for a feature that is “cool,” nor one that is simply unneeded. Also, the cards are to be specific, so the user cannot simply be some general party involved, such as “customer,” “client,” “computer user,” etc. User needs are heeded in a feature-by-feature manner, so the people who will eventually use the software simply cannot be ignored.

Now, there are still a number of ways in which a particular piece of software can veer from user-centredness. A bad interface to a set of features, for example, will make all other attempts at user centered design moot. Also, simply because the features of a piece of software have user needs in mind, the package of features may be counter to this spirit. Among other things I hope to learn at TWU is how to apply standard User Experience Design principles to Agile Methods so that the process and product are excellent for the builders and users of software, respectively. Hopefully what I will learn in the coming weeks (not to mention months and years) will help contribute to the growing knowledge in these combined fields.

For the moment, I am excited about agile…keep it comin’.

…a little bit at a time.

So yesterday at TWU we had a session called Analysis in Context, which was (for me at least) exactly what I have been looking for in terms of lessons that I can wholeheartedly agree with. During the session, the “dirty secret of software development” was revealed to us. I’ll release the dirty secret for the whole wide interweb to hear:

Software Development might not be about software at all.

Can you believe it? I certainly can. Now, this is in no way meant to put down all those people who spend many of their waking hours writing code. I just mean to underscore the fact that software users don’t want or need to use software just for the sake of getting code to work…they just want to do their thing. People want help working on the things that they enjoy working on, which may or may not have anything to do with a computer.

Writing good software requires good research. One really has to figure out the nature of the problem at hand. It’s not about what the client or user wants, it’s about what they do.

So we’ve started delving a little deeper into Agile Development today at TWU. Today we discussed the balance of quality and timebound delivery, as well as iterative software development and adaptive planning. Below I’d like to discuss an issue that is near and dear to my heart, an issue that really worries me about Agile methods, or really any kind of development that advocates the writing of code at an early stage.

In an Agile project, it is likely that a development team begins to write computer code nearly immediately when starting a project, or at least that’s my perception. By immediately, I mean to say that code is created within the first week of the project, if not the first or second day. Meanwhile, a team of Analysts goes and studies the work processes to help the customer figure out exactly what kind of software will be needed. I’m going to assume that at an early stage of a project, the development team makes some assumptions about what will be needed, and commits some ideas to code before they are sure that it will be needed.

This, for me, is where the problem begins. Whenever computer code is created for its own sake, or without proper research, there is potential for the developer to become married to their code. Here’s a scenario:

The team comes to a work site and meets with the client, who has asked that an internal system be created that helps employees communicate with each other, despite the fact that they are distributed around the world. One of the developers immediately thinks of a *great* feature: real-time chat. In the next few hours, he creates a web-based chat tool that can easily be plugged in to a system. He is really excited. This is something he has wanted to try to do for a long time, and finally has had the opportunity to do.

Meanwhile, one of the analysts has been chatting with some of the employees and realizes that all of the collocated employees in each office have no problem keeping in contact with each other simply through face to face communication. The problem, however, is that employees who work in different locations also work in different time zones, and are rarely ever working at the same time. Logically, this means that real-time chat is not a feature that will improve the communication system.

Now we have a real problem. Our developer has fallen in love with an idea, has created it, and will likely be reluctant to let it go. The analyst has evidence that the feature is not needed, and requests that the tool be removed. Now what? Is it an interpersonal problem? Will the developer take this personally? What about his precious time that was spent creating the tool?

Since the feature was created before the development and analysis teams really understood the nature of the design question at hand, it ran the risk of being unneeded. In this case, the tool turned out to be unneeded. The developer may take this event as a war story about “that time the analyst stole the glory and made him remove the best feature.”

But what about the users? The users don’t need it…so why code it? This is just one of the things that bugs me about Agile…code is created so early. Maybe I’m exaggerating the story a bit, but still, nobody likes to throw out work, right?

Maybe some of you agile experts out there can shine some light on the subject and help your soon-to-be peer clear some things up…

Summary: When studying user experience, the brain and its activities need not be considered in terms of separate function.

For the past few days, I’ve been taking in the following image, linked to me from the blog of a future coworker of mine, which was originally linked from here.

In science today, many people spend their careers dissecting, disseminating, breaking apart, and then explaining phenomena, anatomies, and actions. This is all well and good. The people who do this work should be honored, because they carry out an important task in quantifying the many qualities of the world. This leads to understanding of complex processes, which leads to many important things like medicines, technologies, and the philosophical underpinnings that explain to us as humans how the world works.

It is all to often, though, that those in non-scientific field appropriate quantitative data into realms of the world in which it should not necessarily be subjected. Sure, researchers in the neurosciences separated the brain into gross approximations many, many years ago. The most basic separation is the left-brain, right-brain split, which in popular media today symbolizes two different types of people in our society. Lesser known are the brain’s quadrants, roughly depicted in the above image alternatively as (clockwise, from left) Occipital, Parietal, Frontal, and Temporal. (There’s also the cerebellum, which is that big, bulbous thing that hangs at the bottom, but it’s often ignored in brain area discussions…not sure why.)

Denoting these basic brain areas was (and is) important for neuroscientists. It helps to create a basic map of the brain, so that we can generalize theories, then dig deeper to understand them. What worries me, however, is when these brain areas are engendered with specific emotions, or otherwise obfuscating labels. In fact, ‘curious’ thought patterns are not located in the Occipital lobe, but this graphic seems to say that they are. The same is true of the other thought patterns and brain areas noted in the graphic.

To take this issue a little further, I do not believe that it is fair to boil down the user experience to these four basic notions of emotion. The user’s experience is a holistic one, that cannot be broken down and “tweaked.” It is not possible to “add a dash of analytics,” or “take away a little curiosity.” When a designer changes one aspect of an experience, he or she automatically and implicitly changes many others.

Still, the notions expressed in the fine text of this graphic are important to understand and consider. So how is this issue reconciled? I do see some validity in assigning a brain area and specific color for each of the pieces of the “Creative Mind” as explained in the image above. Doing this helps the viewer remember each topic, because it is assigned to an area on a visual map.

It is important that we simply not take these lines too seriously, and realize that our understanding of the brain and human experience are blurry things. There are no distinct lines, and notions of experience bleed together constantly. We must be careful with our graphic illustrations, because we may be crafting explanations that are true in one sense, but false in so many others.