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)
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!
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 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-
- left and right padding/margin have no effect on inline elements
- inline elements can be made to appear like block level elements (and vice versa) using display:block (or display:inline)
- 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.)
- calculating the weight/importance of selectors
- better understanding of shorthand rules (I need more practise on this)
- much clearer understanding of positioning – especially floats
- specify a width after you float a box
- margin collapse with normal flow boxes
- IE’s subtractive interpretation of the box model
- linking all CSS files within 1 CSS file
- elegantly using different CSS files for different browsers, including problematic ones (NN4, IE5, IE6, etc.)
- better understanding of forms, with fieldsets and labels, including the styling
- different styles for different pages
- resolution dependant layouts. Real cool.
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.
P.S. the About page has been updated a little. Just a little.