Function over form?

I was walking on a back lane of Amoy Street when I spotted this shophouse back.

Shophouse dotted with aircon compressors

I have no idea what’s going on in the building, but they sure require a lot of air-conditioning.

Here’s another view.

Another view of shophouse dotted with aircon compressors

When a building wall is practically covered with aircon compressors, something is seriously wrong somewhere.

iPrepNS website

A website that I’ve been working on for over half a year has finally been launched.

The website iPrepNS is for guys who are about to enter National Service in Singapore. It aims to prepare them for their 2 years of National Service.

The website covers 3 main phases -

• pre-enlistment, where there are a whole slew of activities that need to be done even before a boy enters National Service;
• the enlistment day itself, the big day when the boy enters National Service;
• and life as a recruit, the first few months in service.

Probably the most attractive part of the site is the pixel art banner, which unveils some of the memorable moments covered by the website.

Like when a recruit gets his crew cut.

It adds a touch of humor, which is quite unexpected from an official website by the Singapore’s Ministry of Defence.

Another of my favorites is the interactive on learning the basic foot drill commands.

Besides drawing lots of chuckles from people who’ve tried it, it serves a very real and common need mentioned by recruits we interviewed during our research phase.

Many recruits were unsure of the foot drill commands during their first couple of weeks, which added to their stress caused by all the adjustments they had to make. So this interactive was designed to help them learn the bare basics, without overwhelming them with the more advanced commands.

Similar is the interactive on identifying ranks. We decided on putting only 7 ranks that was most likely to be encountered by a recruit. Anything more would be overwhelming.

What I appreciate most is not the flashy stuff, but the move towards honesty and transparency in the content, especially in the section on recruit training.

Boys who haven’t gone into National Service would have heard stories on training from those who have gone before them. What they have heard may not always be accurate, since human memory is malleable, or simply because the training itself may have changed. It was thus important to include training information that is current and accurate.

We presented the information like how an informed older brother would – informing and advising, being honest about the difficulties to be expected, yet encouraging and being positive about it.

For example, in page on field camp, under “what is it like”:

The 6 days of field camp are tough, but you will definitely remember these days as they are packed with new and interesting experiences.

[...]

Mosquitoes: They’ll always be there, buzzing around when you’re training or trying to sleep, and giving you a bite or two in the process. You’ll be issued with insect repellent, so don’t forget to bring it along.

This honesty about the negative side of training is important for the credibility of the content.

You may have noticed that we even have a section on “safety concerns” on every training page. We found this section important after interviewing parents, especially mothers who were worried about their sons’ safety.

It’s been months of hard work, traveling to different camps and even Pulau Tekong numerous times, doing numerous interviews, taking countless photographs and video footage.

It was thus quite gratifying that the project won the first prize within the Ministry for Defence, and so was launched officially by the Minister of Defence Teo Chee Hean yesterday:

Here’s the official news release from the Ministry of Defence.

My colleague Maish also blogged about this project.

Update: The project went on to win the Gold award for the National IQC Convention 2008.

Can we afford to design in a vacuum?

I came across an article in a recent New Scientist issue (4 August 2007), where they interviewed 2 retired Apollo programme engineers from Grumman Corporation. (Grumman built the lunar module for the first manned moon landing 38 years ago.)

The engineers’ reply to the first question stood out to me:

Q: How closely did you work with the Apollo astronauts?

Gerald Sandler: Very closely. They would continually come into Grumman and they were on the inspection teams for the vehicles. Everyone who was working on the lunar module saw them personally and recognised that their lives depended on what we were doing. Having the astronauts involved and very visible played a key part in ensuring that people felt personally responsible. That was one of the reasons why the quality levels where so high.

Joe Mulé: Whenever a problem wasn’t getting attention I had a guy working in my group who used to say: “Are you going to tell the widows?” It was something we always kept in mind.

This reminds me of what I said in a recent post on intranet design and governance:

As part of the research, we had to conduct many interviews with different staff, to understand their work habits, their informational needs, and so on. As of now, we’ve interviewed close to 10% of all staff.

Personally, those interviews weren’t just to find out what problems needed to be solved or even to understand the users – what was more important was that those interviews gave me an opportunity to have personal contact with those who will be using the intranet that I’m redesigning, to actually care about them. I’m not redesigning the intranet for some faceless silhouetted entity called the user; I’m doing it to help make the lives of these nice people a better.

The longer I’m in the field of design, the more I see the importance of first-hand interaction with the clients and final users.

More so because I’ve also seen instances where the designers were “designing in a vacuum”.

I know of this web project done by a large web design company where the web designer never got to meet or have any contact with the client. Everything went through the project consultant.

The designer was simply asked to create the design based on a given layout, and so they did, to the best of their ability.

It was obvious from the design that the designer didn’t grok or have an understanding of what the client the final users needed.

So, that marked the beginning of a long and frustrating process of redesigning and rejecting and re-redesigning and re-rejecting.

Perhaps, that web design company wanted to save costs – it is costly to get the designer involved in attending meetings with the clients and the final users.

But it’s even more costly for them not to do it. Costly not just in terms of the effort in redesigning, but even more in terms of branding, where the client becomes displeased with the whole experience.

Rather than asking if we can afford to let the designer spend time meeting clients and users, we should be asking if we can afford not to do it.

Intranet Design and Governance

Over the last 3 months, one of the projects we’ve been working on at PebbleRoad is the revamp and redesign of a client organization’s intranet.

The organization has over 700 staff, most of them at the headquarters, but a significant number of them in their other locations spread all over Singapore.

The role of PebbleRoad was to conduct research, then redesign the structure and the layout (wireframes) for the new intranet based on the research. Another company would then use our design to do the actual implementation of the intranet.

We’re almost finished with our part. Although I can’t divulge too many details at this point, it’s been a fun and fulfilling ride so far.

As part of the research, we had to conduct many interviews with different staff, to understand their work habits, their informational needs, and so on. As of now, we’ve interviewed close to 10% of all staff.

Personally, those interviews weren’t just to find out what problems needed to be solved or even to understand the users – what was more important was that those interviews gave me an opportunity to have personal contact with those who will be using the intranet that I’m redesigning, to actually care about them. I’m not redesigning the intranet for some faceless silhouetted entity called the user; I’m doing it to help make the lives of these nice people a better.

Which makes the work alot more meaningful. It makes me want to do a better job.

But creating a wonderfully-designed intranet is only the start. What is equally important is how the intranet is cultivated, so that the benefits of the intranet can be maintained or increased, in symbiosis with the organization itself.

To help with that, we produced an intranet governance guide:

This guide describes a set of processes that need to be in place and a set of actions that need to be taken to sustain and grow the intranet. Without these guides and checks, we risk diluting the very efficiencies and productivity gains that the intranet is designed to provide.

My colleague and I had much discussion over this guide. I hope it’ll be useful for others who are maintaining intranets, or are planning to do so.

Which Comes First: Design or Research?

Since I’m into design (I’m a Design Consultant after all), I was pretty interested in PingMag’s interview with Ken Okuyama. While he’s mostly into product design (he’s behind the lovely design of the Enzo Ferrari), and I’m more into information and experience design, there’s always something I can learn from other design fields.

What stood out to me the most was how he typically starts his design process:

I put everything in my brain down on paper, stick all of it on the wall and judge objectively the best possible solution for the problem. Then I start the research after. Not before. Once you know, you cannot go back to “your ignorant yourself.” But the ignorant yourself is the best creative partner you have.

Where I work at PebbleRoad, we normally do it the other way round – keep an open mind and do the research first to find and understand the problem, before embarking on the design.

Humanized described our design philosophy very nicely in a recent post on interative:

Coming up with a solution is often the most straightforward part of the design process. That isn’t to say that creating the solution is easy, or doesn’t require a deep knowledge and honed skill set. It’s just to say that when you have a set of requirements and a well defined problem, you know where you stand and where you have to get to. It’s mostly straightforward. Much harder is the implicit problem of figuring out exactly what the problem is in the first place. If the problem is vague or ill-defined, the design solution will be too.

So far this has worked well for us, and it makes sense too, since we don’t really want to design something for the wrong problem.

But Okuyama has a valid point about “your ignorant yourself” being the “best creative partner”. Is that the key to the really groundbreaking and mind-blowing designs?

Something to think about, and something I’ll definitely try out in my next project. But that would never work if we forget his qualifying statement, which I deliberately left out from the quote above:

You also need the courage to adjust your original idea once it’s proven to fail.

Why BlogOut Was So Noisy

BlogOut was too noisy.

Sure, noise can be a good thing at the right time, when ideas are flowing, but when there’s a panel discussion going on in front of the room, and most of the (interested) audience can’t hear what’s going on, you have a problem (astro described the situation in his post, Blogout or SpaceOut?).

So, why was it so noisy?

Crowd control, or the lack of it.

When the MC started the event proper, she didn’t manage to get everyone’s attention. There were still pockets of people standing and chatting at the rear area.

(photo from Kevin Lim)

It’s easy to expect the crowd to quieten down and pay attention eventually (I would have expected that myself), but it didn’t happen. On hindsight, the MC should have gotten the attention of everyone before starting.

Which would have helped for around 10 minutes at most, before those standing in the background resumed their conversations. We know that because the MC did ask pretty firmly for everyone to “be respectful” during the panel discussion. The success rate was around 80%, for around 5 minutes.

Mainly because there was a bigger factor at play:

The lack of chairs, or too many people standing in the background.

When you’re standing in the background in an event like that, it’s easy to feel like you’re not part of the seated group, meaning that you’re somehow excluded from the social norms and rules of that group.

I know because I’ve done that too many times myself.

Being excluded from the seated group, and part of the outsider group, there’s little inhibition from making a comment or two to the person standing beside you. And because you’re standing, it’s so easy to be facing your comment partner rather than the front of the room.

The perfect setup for a “backchannel” conversation.

There are a couple of other minor factors that I suspect have contributed in minor ways to the rather noisy atmosphere, like the arrangement of seats, the shape of the seats, and maybe even the presence of the food, drink, and waiting staff, but since they are minor, I shall refrain myself.

I hope this post gives some insight into the design of an event space, and the human dynamics within it. And hopefully, there will be enough seats next time

Kudos to the organizers. I still think they did well.

Update:

I completely missed out another major point – the poor sound system, although it was fine where I was (near the front). Thanks to Du Senyao Peter who pointed it out in the comments:

Though I think a major problem is with the sound system, which could not amplify the talking one’s voice very well so people at the back could not feel the presence of the one who is talking, be it emcee or the panelists

User-Tested Designs

In design for users, user testing is often crucial, especially when the designer isn’t already very experienced in the area, or when comprehensive guidelines or heuristics aren’t available.

A couple of years ago, I followed some wheelchair-bound people around critique the accessibility of some new buildings that were designed with accessibility in mind.

The next picture is of the bathroom at a condominium clubhouse. The picture doesn’t show the handle bar on the right wall beside the toilet, but it’s there. Is this friendly for a wheelchair user?

The designer probably tried their best, and I thought their design was pretty decent. Then I saw the next one:

This bathroom is at a rehabilitative hospital, where many of the users are actually wheelchair users.

The obvious difference between this bathroom and the first one is that gray plastic seat folded up against the right wall, for a wheelchair user to sit on while having a shower. In the first bathroom, the wheelchair user would have to shower the wheelchair as well – not a good idea.

The first bathroom was designed with the help of (inadequate) guidelines, while the second one was user-tested. The difference would be glaring to a wheelchair user who wants to shower.

And once in a while, you encounter really bad designs.

Maybe the users have very long arms.

(Last picture via Chris Hielmann)

Update:

Here’s an interesting comment from Kim & Sophie that’s worth surfacing:

I’m a wheelchair user and that last photo reminds me of a bathroom in the airport in Halifax, Canada. It was great accessibility wise. That is until I tried to wash my hands. The soap dispenser was stuck to the mirror halfway between the counter top and ceiling! There was also another “accessible” (and I use that term VERY loosly) bathroom at the airport in Toronto, Canada where the toilet papoer roll was so low you had to practically lean ahead and hold your body up with yoru hand against the floor to rech it with your other hand!

Information Architecture, In Short

In my new role as a Design Consultant, I’m involved in the design of user experiences (UX) – what a user experiences when they are, say, visiting a website.

When people ask me what I do, one of the things I usually mention is Information Architecture (IA), which is a part of user experience (UX) design.

Blank look. During that brief moment, I can tell that most people are thinking if they should ask me to explain further or not.

Then I’d go ahead with an explanation similar to this:

When you have a large website, it’s common for the information to be badly organized, such that it’s hard to find the information you’re looking for, right?

I’d pause and wait for some glimmer of understanding to appear in their eyes, before continuing:

What the Information Architect does is to use various methods, such as user studies, surveys, et cetera, to find out what is the optimum way to organize the information on the website, so that the website becomes a lot more user-friendly.

That’s when they usually get it.

It’s been a week into this new job, and I’ve been learning a tremendous amount, and there’s still loads to learn.

Things are getting interesting.

Russ Weakley’s CSS Workshop

PebbleRoad (the company I work for) brought in the highly-acclaimed Russ Weakley to do a workshop on CSS today.

Russ is a great guy to work with – extremely easygoing, and no hint of ego at all, even though he’s one of the best CSS gurus alive (or dead) today. And a humorous guy as well, with his self-deprecating style of humor (he claims it’s normal Australian humor).

He carries the same style of humor into the workshop, telling us countless stories of his “idiotic” mistakes he made with CSS, which certainly makes the participants feel a lot better at themselves.

He’s also great at making humorous analogies to explain concepts (”inheriting big noses from your parents”), which helps make concepts a lot easier to understand (analogies) and memorable (humor).

All in all, I thought this was a wonderful workshop, and all the attendees I spoke to left the place very happy. I’ve a feeling that a lot of people who decided not to attend will regret that decision.

Let me geek out now:

Below is a list (mostly for my own reference) of the most interesting things I learnt-

1. left and right padding/margin have no effect on inline elements
2. inline elements can be made to appear like block level elements (and vice versa) using display:block (or display:inline)
3. pseudo classes, especially tr:hover for to highlight a row in a table when the mouse is over it. (How I want to go back to the last website I coded to add this in.)
4. calculating the weight/importance of selectors
5. better understanding of shorthand rules (I need more practise on this)
6. much clearer understanding of positioning – especially floats
7. specify a width after you float a box
8. margin collapse with normal flow boxes
9. IE’s subtractive interpretation of the box model
10. linking all CSS files within 1 CSS file
11. elegantly using different CSS files for different browsers, including problematic ones (NN4, IE5, IE6, etc.)
12. better understanding of forms, with fieldsets and labels, including the styling
13. different styles for different pages
14. resolution dependant layouts. Real cool.

μεταcole Milestone

Last friday was the last day of work for me as an Educational Technologist at the Teaching & Learning Centre of Ngee Ann Polytechnic, and today marks my first day at PebbleRoad as a Design Consultant.
As such, I’ll also be shifting the focus of my blog.

To reflect that, I’ve changed the tagline from “education and everything else” to “design thinking, education, and everything else”.

I’ll still be blogging about education, even though my new role doesn’t deal with it as much, since education is still an area I’m deeply interested in.

As for what “design thinking” is exactly, we’ll just have to wait and see how this blog develops.

Sit tight…

P.S. the About page has been updated a little. Just a little.