Archive for the ‘Design’ Category

A Pragmatic Approach

Thursday, December 13th, 2012

Two weeks ago we held the first Geekdom Friday. It’s a once a month, open event where we talk about a technology related subject from which everyone – not just geeks – can learn and chat about.

My talk was about what I’ve learned from the book “The Pragmatic Programmer”, by Andrew Hunt and David Thomas. Although it is targeted at programmers, it contains lots of useful tips on problem solving that everyone can use.

On “Take Responsibility” the book covered why everyone that touches a project (regardless of at what point, or for how long) should make sure that they see it through, and not sit idly waiting for things to go wrong. Because they often do, and when it happens, one should “provide options, not make lame excuses”.

On “Fighting Entropy”, is about how to avoid chaos from taking over your project, covering the “Broken Window Theory”: all it takes is that one small part of the system gets messy or broken, to settle a sense of abandonment and more “windows” get broken without repair, just like in dark parts of big cities. It’s all about cleaning up the mess as soon as you notice it.

The book explains how quality should always be the main requirement of a project, while trying to settle for what’s called the “Good Enough” product: focus on it’s core before thinking about adding extra functionality.

In the talk I covered briefly the “Evils of Duplication” , where I mention the golden DRY rule (Don’t Repeat Yourself) which teaches us to never duplicate ‘pieces’ of knowledge, we talked about Prototypes and Tracer Bullets. While the first are disposable, often paper-based representations of the product (or parts of) used to test specific areas or ideas, the latter are build to keep, to test how the system holds together, to see if it ‘hits the target’ – you’ll have a trivial implementation that you can test to see how it behaves in practice. Once that’s verified, they act as the basic system ‘skeleton’ on which we can build on.

Often Prototypes and Tracer Bullets are mistaken for each other, although they serve a different (yet useful) purpose: think of “prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired.” (quote, p. 52)

In the end, having a pragmatic approach to problem solving is all about constantly reminding ourselves of the big picture. Think about who will use what you are building, take responsibility for it, learn from mistakes and be prepared for them.

More to come next month!

Photo of David Thomas was taken by James Duncan Davidson

Design without personas

Wednesday, August 19th, 2009

Our new website has gone live for Webnographer, the remote usability testing tool that we have developed. We spent some time working on the Information Architecture of the site with Danny Hope, of UX Brighton fame.

The challenge we faced, which is common for many sites, is that our audience has many levels of knowledge both about Usability, and Remote Usability.  Information Architecture is critical for any website, that is getting the conceptual structure and logical organization of the site right.

So, how did we go about it?

We put the user at the heart of our design. This is usually done in the world of usability and information architecture through reasearch and creating personas. These personas are fictitious characters created to represent the different user types that might use a site.

There are many heated discussions to be found on the subject on the IxDA mailing list, with many different arguments for and against personas.

Here is our take on it. We don’t use them. Instead, we use real people! The important thing is that you think about your user, a person. Not a target market, that is a non-tangible thing. Thinking about a real person helps build empaphy, helps focus your design process, and lets you design better products. Personas help encourage this. But they take time to create as they are fictional creations of a user type. Real people work just as well, and even better, because you don’t have to imagine whether they would like something, as you can just give them a call and ask them.

The process of using real people

When we started designing the website, the first step was to map out the target audience that we had identified to date. As you can see on the picture of the white board, we broke our user base down by the industry sector they worked in (see picture of white board). For example in our case: In-house UX specialists,  Agencies, and Usability Professionals, Developers, etc.  Then we picked people who were representative for the culture of a sector, put their names on the board. (To protect their identity I have smudged out their names.) We know these representative users, as we have met them and keep meeting them throughout the concurrent ethnographic research that we are carying out.

The hard part in the exercise was to identify what are peoples motivations and feelings.  This is always hard as people have varied backgrounds, knowledge and views. Even people in the same sector have different mental models. Using real people to motivate the design, meant that if we where unsure about their motivation, all it took was a phone call, or meet up with them to find out.

Once we had our hypothesis of peoples motivations, we then could start creating the structure of the site and different message for communication. As you can see on the photo on the left the design started taking place, and the design for our website evolved.

So, are we finished?

No. We work agile and want to keep improving our site. People and technology will keep changing, and so too will the Webnographer website. Also, we are aware that some of the language used on the site is still geeky, and needs to be “translated” into non-geek language. This is something we are working on at the moment. Also we are very keen on getting feedback from our users, so if there is anything you like, dislike, or fell is missing, please feel free to leave you comments here. We are listening!

We would like to thank Danny for all the enlightenment in structuring the ideas and the insight that he gave us. Just look at our old holding page above and compare that to our new website. Its a great improvement!

A designer’s perspective on a Groovy and Grails meetup

Wednesday, April 1st, 2009

Last Tuesday I went to the first Groovy and Grails meet up in Brighton. Graeme Rocher, the founder of Grails lives in Brighton, so it was very exciting for the Brighton geek crowd to have their first very own meet up down at the coast and outside London. The most exciting thing was that Graeme was going to re-create Twitter in 40 minutes of live programming.

FeraLabs helped to organize the event, so I went along, even though I am not a programmer at all. My background is in design and HCI.  The thought of a geek programmer meeting was slightly disheartening, as I was worried that I was going to be sitting there with blank eyes, not understanding a word.

But to my surprise, my preconceptions were found to be wrong. I really enjoyed the talk.

Graeme started his presentation with a short introduction about Groovy and Grails, including the Grails philosophy, which did sound a little bit like a usability recipe for programming:

  • build on the shoulders of giants
  • embrace convention over configuration
  • use sensible defaults
  • achieve simplicity without sacrificing flexibility

Graeme also highlighted a few geek facts about Grails:

  • Grails is 3-5 times faster then Ruby on Rails
  • in March 2008 Grails had 7000 downloads a month, in March 2009 it had increased immensely to 70.000 downloads a month
Black window of horror

Black window of horror

Then the programming action began. Graeme opened the black window of horror and created a new app. He explained the different folders that were created, and what the different items in them are. For a programmer this may have been a bit basic, but I got excited, as it was something that I recognized.

FeraLabs is building Webnographer in Grails. This means that I see these folders everyday. I work with them and around the code, working on html myself and trying not to break the Grails code.

Graeme Rocher

Graeme Rocher

Graeme whizzed through the different steps of creating Twitter. He achieved this mostly through plug-ins, so it looked really easy. There was of course some manual programming, and Graeme explained the different steps and what the lines of codes were meant to do. 40 minutes later he had recreated the functionality of Twitter. It was ugly, but it did work.

A personal note about Grails: I liked that it seems to be using mainly natural language for its commands. This certainly helped me following the presentation, and will also be useful in my future work in getting a vague notion of what the different lines of code do and refer to.

In conclusion, for me as a designer, it was great to find out what all the bits and pieces of code do. I work with/around it every day and I am definitely curios. This does not mean that I will convert to being a programmer. Yet, this little insight that I got at the talk can definitely be beneficial to my future work, as well as other designers. It can help the communication between programmers and designers, encourage mutual understanding, and result in a better working relationship between both.

So I my question to the programmers is, are you willing to try seeing things from the design and user’s perspective too? And what do other designers think about hanging out with programmers a bit more? Do you think that cross mingling at different events can encourage better working relationships between designers and programmers?

Please leave your comments below. I’m keen to find out what you think.

Information Visualization for Knowledge Discovery

Tuesday, March 10th, 2009
Treemap developed by Jean-Daniel FeketeTreemap developed by Jean-Daniel Fekete

Ben Schneiderman from the University of Maryland, gave a fascinating talk in Cambridge on 5th March 2009 about the topic of “Information Visualization for Knowledge Discovery.”

Ben has authored many books and papers on human computer interaction, and was the founder of the Human Computer Interaction Laboratory at the University of Maryland. His keen interest is the field of information visualisation.

During his talk, Ben pointed out that in contrast to scientific visualization information visualization is a relatively young field as information visualization conferences have only been going for about 15 years. He added that, the challenge with information visualization is that the information keeps changing over time.

Ben presented his conceptual break down of information visualization tasks: “Overview -> zoom and filter -> details on demand.” What he means is that one should provide an overview first, showing all the information, for example complex graphs, diagrams and maps. This allows the user to orientate themselves and get the big picture. Then allow the user to zoom into more detail and filter out any unwanted information. Finally, allow the user to select an item and get more detail about it when required.

The most enlightening point that Ben made during his talk was that: “Information visualization gives you answers to questions you didn’t even know.” He went on to argue that “there should be a move from opportunistic discovery to a more systematic discovery of knowledge.”

Ben illustrated his argument with a number of demonstrations and screenshots of projects that he and his students have developed over the years. Each guides knowledge discovery thought the visualization of different patterns in the data. Ben emphasised that for information visualization “the interest is not in a particular value, but an overall view and patterns in the data”. Yet, he also emphazised the importance “trying to see the violations in the data that are contrary to your expectations”.

Ben demonstrated his famous treemap that has now been modified by many commercial companies. It has been modified for example  to visually show the constantly changing landscape of the google news aggregator, and even the New York Times has used it to show changes in truck and car sales.

Other tools which Ben showed were the ShapeSearcher which finds spikes in the data, Scattergrams which provide the opportunity of hunting for stuff, the alignment tool which can filter by event and show what happened before and after this event, and another tool which identifes gaps in the data.

The most intriguing example of finding patterns in data was Ben’s demonstration of the SocialAction tool, which uncovers hidden structures in social networks over time. The visualization presented the correlation between US senators voting the same way. It showed a strong that democrats and republicans vote the same way. Only four republicans sometimes voted similar to the democrats. Yet the most surprising finding through this visualization was that the correlation for democrats voting the same way was far stronger then republican voting the same way.

"The social network of the U.S. Senators voting patterns in 2007, after Democrats took control. Republicans are colored red, Democrats blue and Independents maroon. Here, the partisanship of the parties appeared automatically (180 vote threshold)." (by Ben Schneiderman)

"The social network of the U.S. Senators voting patterns. Here, the threshold is raised to 290 votes. The Democrats' relationships are much more intact than the Republicans. Details-on-demand are provided for Senator Whitehouse, the senator with the highest degree at this threshold." (by Ben Schneiderman)

Ben concluded his talk with three key points for information visualization to guide knowledge discovery:
1.    Rank-by-Feature Framework, i.e. rank by what people want to know
2.    Decomposition of complex problems into multiple simpler problems
3.    Ranking guides discovery. It is important to provide systematic
       approaches for discovery.

Challenges of visual literacy

A theme that kept popping up in the talk and particular in the questions afterwards, was the challenge of visual literacy. Words can help to clarify matters of information visualization, but Ben explained that textual information is only good for simple queries (such as a rank list in Google search results). Visual tools on the other hand are better for complex queries.

For anyone who is interested in finding out more about the challenges of visual literacy, Ben recommended the work of Colin Ware, a perceptional psychologist, who looks at the challenges of understanding visual information.

Interesting reads about information visualisation:

Bederson, B. and Shneiderman, B. (2003) The Craft of Information Visualization: Readings and Reflections, Morgan Kaufmann Publ., San Francisco, CA. Amazon UK, Amazon US

Card, S., Mackinlay, J., and Shneiderman, B. (1999) Readings in Information Visualization: Using Vision to Think, Morgan Kaufmann Publ., San Francisco, CA. Amazon UK, Amazon US

Tufte, Edward (1983) The Visual Display of Quantitative Information, Graphics Press, Cheshire, CT. Amazon UK, Amazon US

Tufte, Edward (1990) Envisioning Information, Graphics Press, Cheshire, CT. Amazon UK, Amazon US

Tufte, Edward (1997) Visual Explanations: Images and Quantities, Evidence and Narrative, Graphics Press, Cheshire, CT. Amazon UK, Amazon US

Ware, Colin (2004) Information Visualization, Second Edition: Perception for Design (Interactive Technologies), Morgan Kaufmann Publ., San Francisco, CA. Amazon UK, Amazon US

Ware, Colin (2008) Visual Thinking for Design, Morgan Kaufman, Burlington, MA. Amazon UK, Amazon US

Designers Dilema: visual convention vs. breaking new ground

Wednesday, January 21st, 2009
Without innovation the internet would still look like this. (Gutenberg's printing press. Photograph by Matthias Kabel)

Without innovation the internet would still look like this. (Gutenberg's printing press. Photograph by Matthias Kabel)

The dilemma of visual convention vs. ground breaking new design seems to be a fearsome concern for usability specialists.  In a recent blog post on the Concept 7 blog, Stefan Wobben quotes a paper by Luis Santa-Maria and Mary C. Dyson form the University of Reading that investigated the impact of violating visual conventions on user’s performance and orientation. Santa-Maria and Dyson explain:

“Although initially violating visual conventions might hinder user performance and leave users disoriented this experiment indicates their experiment indicates that these problems can be short-lived and users can adapt reasonably fast to a new set of visual conventions.”

This is good to hear, yet its no news as such. If design had always only followed convention we would not have progressed from the written word to the printing press to computers and the internet.

“So the decision to whether conform or violate visual conventions when designing a website should ponder that although users might adapt quickly to novelty there is an initial performance hindrance and disorientation.”

They have a good point there in encouraging those violations. Too many studies focus on first time use, but not repeat users, how behaviour changes over time, and the experience and use of the system by expert users. A single lab study as a Q+A exercise just before the launch of your website is not going to do the trick in gaining this understanding. Usability is an ongoing process, not a one of label of approval. As Harry Brignal pointed out on his blog: “A UX designer’s job is never done.”

The one great thing about remote usability testing is that it is cost efficient and can therefore be carried out more often, than a lab study. Webnographer, as a remote usability testing tool, makes ongoing testing simple and affordable. It makes it easy to test the learning curve and behaviour and satisfaction of experienced users.

As Jared Spool explained back in 2003 small ongoing changes carry far less risk, then a major relaunch and re-design, which is very likely going to fail. As with the prinitng press, changes in improvements were small streched out over a lenght of time and we ented up with the internet, which makes the spreading of ideas and information easier than ever. For website design, the small changes allow you to measure the effect of that change on your users, and you will find out whether the change has made your site better or just different, and how it affects your users over time.