Posted by Dan Eastwell
Wed, 21 May 2008 12:15:00 GMT
Simple usability testing as advocated by Jakob Nielsen with five users showed that user testing did not need to be an expensive procedure; products such as Morae allow 'usability labs' to be constructed from two laptops and a webcam.
This has made Usability Testing as practical and almost exclusively necessary part of the building of any interface (e.g. a simple website) or application (e.g. a website with any form of interaction)
Usability practitioners advocate testing throughout the design process, and not just as an afterthought once an application is built - this can be a simple procedure, with the most trying part being organising your five participants, but regular testing days can return rewards beyond optimising an interface for ease of use.
Get feedback
You can fairly quickly get feedback not only on how or whether your site works, but also on your users' general experience of similar sites, or real-world alternatives. How do your users normally find sign-up procedures? Are they worthwhile? Do they have trouble with so many passwords? Do they like newsletters? Are they familiar with RSS? And so on...
Incremental testing on rollouts
37 signals paved the way with progressive rollouts and testing constantly through this process allows you to fine tune your application. The danger of course is knee-jerk redesigns every time a user misses a button.
Get Evangelists
People will have volunteered for your user testing, especially if you've advertised through Craiglists or Gumtree, and you reimburse people for their time. Your test subjects will probably see this as something of a fun day out and should by the end of it be in a good mood. People love being asked their opinion, and enjoy being part of the process.
Regular testing will mean you have a constant stream of users who have not only seen your site, but have seen you and know you are keen to get things right. This will mean they're pretty likely to tell people about their fun day out and the nice people there. This can only be a good thing...
Contact with clients and creating superusers
In the same way a telephone call is better than an email, regular face-to-face meetings with your user base can lead to a positive reflection on your app/site.
Your users will be more forgiving of any future problems if they know that you're the kind of people who'll look into it, or probably are already.
Through showing people how your site works, possibly in much greater detail than they would find coming to it cold, you also get the equivalent of old school software 'training days', and a set of users who should end up knowing the workings of your site fairly well and, at best, are able to pass this knowledge on.
Regular testing, regular meetings
With all this in mind, it's probably worth conducting testing days even if you've got no significant changes to make to your site.
If you keep a database of past testees and those that you didn't have time for, you have the ability to keep in constant 'real-world' touch with your user-base.
User testing can be a very positive way of getting to know your end-users, and in a very focussed way - you have:
- A database of possible testers
- A database of people who know your site and can comment on future change
- A set of site evangelists
- Some possible future superusers
Your users:
- Have a more positive view of your site and it's working
- Become more likely to give you feedback normally
- View you not just a faceless frustrationas, but as 'human'.
Posted in Usability, Interface Development, Design, The Web, Interaction design, User Experience | Tags building, client, relationship, testing, usability, user | no comments | no trackbacks
Posted by Dan Eastwell
Tue, 13 May 2008 09:56:00 GMT
Here's a short presentation on User Centered Design with examples of user experience and information architecture I've worked on.
It's not definitive, but reflects the process I've used in the past - hopefully it might be of some use!
Posted in Usability, Interface Development, Design | Tags architecture, design, experience, information, interaction, ucd, usability, user, wireframes, wireframing | no comments | no trackbacks
Posted by Dan Eastwell
Sat, 10 May 2008 12:00:00 GMT
James: question for you
what is a wireframe?
Me: well, there, good question
a wireframe is essentially a prototype
it can take many forms
I will provide you with examples
sent at 2:55 pm on wednesday
A set of blueprints for a website made in excel will do for a wireframe
as will something jazzy like this prototype http://test2.danieleastwell.co.uk/scholastic/index.html
you will note the grey areas for unknown content etc and the fact it is mostly static.
however, you could do exactly the same thing with just layout css, rather than anything better
or you could do it all on paper
sent at 3:00 pm on wednesday
James: ah I see
so its a static html version of a dynamic site
Me: not necessarily
it could have no styling
or not be in html
James: so its quite a vague term then
Me: yeah, just like 'prototype'
it could be a set of visio or excel files
I like to prototype in html and css as I find it easy, but I find that I also need some design styleguides
the draw back to doing it that way is you get stuck in the 'how' and don't concentrate on the 'what it does'
I prefer paper.
it's a lot quicker and you don't mind making revisions
James: yeah I tend to plan stuff on paper
Me: you can also scan drawings in and plop them in html if you just need to change something on only one bit
sent at 3:06 pm
on wednesday
Me: here's an example of a paper prototype
http://www.youtube.com/watch?v=ppnRQD06ggY
actually, here's a much much better one.
http://www.youtube.com/watch?v=c4-A-9hGn0U
that's genius. you can tell exaclty what the application is going to do, without having to have it built
you could say they used simple video editing instead of html to wireframe it
I suppose also, though that that's a prototype - a wireframe is more formal and static and has details of what each part of the page contains and does
although some people call that a 'functional spec'
sent at 3:10 pm on wednesday
James: its some dude wandering around an office
ah I see
Me: are
you watching the second one?
the 'ciao'?
you really get a feel
for what the app will do.
James: yes
yeah pretty clever
Me: also,
very simple. saves a lot of time in app development to get your
protoypes right.
and in a very skewed
way that vid is a 'wireframe' as it tells you 'what it does'
(not 'how it works' or
'what it will look like')
sent at 3:14 pm
on wednesday
Me: I
might put this chat on my blog. seems like a fairly useful bit of an
introduction...
(to wireframing)
Posted in Usability, Interface Development, Design | Tags architecture, design, documentation, ia, information, interface, ux, wireframing | 2 comments | no trackbacks
Posted by Dan Eastwell
Fri, 07 Dec 2007 17:53:00 GMT
You've spend months on a project, place it on your portfolio with pride. A year or so later, you go back to the site and - horrors - it's completely changed!
I've had that feeling twice recently.
Firstly I was looking for an old image gallery I'd created for the javascript I'd used. When I got to the site all I could see was a 404.
One to change on my portfolio.
This evening I saw an advert on TV for a company I built HTML/CSS templates for, that I was fairly proud of.
Then I did a double-take.
If they've come up with new style product and a new style advert, their site is likely to be rebranded, too. Oh dear.
Leaping to my laptop I looked at their homepage - it's greatly different. Their main landing pages: different. Then I went deeper into the site, to some of their several thousand product and information pages. Very similar. Phew!
This pleases me on a couple of counts - firstly I don't have to take the page from my portfolio, and that the structure, template layouts, palettes for colours and the other CSS systems tricks I'd put into place were still there.
I can only hope the makeover was easy and therefore cheap for the new design team.
The most pleasing thing of all? My name and site still there in the boilerplate in the css files
CSS templates by Dan Eastwell www.thoughtballoon.co.uk
Is it that wrong to have a little pride in your work?
Posted in CSS, Interface Development, Design, The Web | Tags design, websites | 2 comments | no trackbacks
Posted by Dan Eastwell
Tue, 20 Nov 2007 17:14:00 GMT
or why I won't, until the money runs out...
Jeffrey Zeldman maintains his position as the spokesman for the progenitors of web design and web development in the latest issue of A List Apart by stating that even in this late stage of the web, that web design is poorly understood.
Read more...
Posted in Usability, Interface Development, Design, The Web | Tags advertising, design, microsites, system, web | no comments | no trackbacks
Posted by Dan Eastwell
Sat, 07 Apr 2007 20:08:00 GMT
A bit of shameless self promotion, here, but I've made the effort, so why not let people know?
There's a few new articles on my main site:
Boots Expert: Progressive enhancement: Javascript enhancement to pages, and CSS systems analysis, to tight accessibility requirements.
This project went live at the end of last week, and I'm fairly proud of how the project went and the outcomes. The site is very accessible and has been well reviewed and tested. I think the design is great (not my work!) and I'm happy with the soundness of the XHTML and the CSS, especially, which I think has been nicely modularised.
Energy Saving Trust: Ajax modules: Reskin work on existing coldfusion-driven modules, creating javascript to enhance the look of the output code. Ajax modules written to enhance HTML forms.
Design Council: Complex Modular Site: A complex modular site using transparencies, and intricate CSS structure.
I worked on this last year and now the site is live. This was a large project with many templates necessary to match the designs, it's lead me to think a lot about the status of interface architecture for the web (or CSS/XHTML, if you will…) as a discipline requiring the same level of forethought as any other software-based discipline, when dealing with projects with any level of scale or complexity.
Posted in Usability, Browsers, CSS, XHTML, Interface Development, Design, Javascript and the DOM | no comments | no trackbacks
Posted by Dan Eastwell
Sat, 07 Apr 2007 10:14:00 GMT
i'm writing this from my phone-an instrument with a numeric keypad and a joystick suited to a hamster. my connection takes me back to 1996. i can read my gmail, but can't send to flickr. twitter doesn't want to know either through opera mini or text. it's baby steps at the moment, and even with a phone only a year old, high technological barriers.
Read more...
Posted in Browsers, Interface Development, Design, The Web | Tags mini, mobile, opera, sms, text, web | 2 comments | no trackbacks
Posted by Dan Eastwell
Mon, 23 Oct 2006 16:56:00 GMT
Looking at Matthias Willerich's article on the web developer toolbar, reminded me of my use for CTRL-SHIFT-F in Chris Pederick's firefox extension.
I tend to do a quick CTRL-SHIFT-F in order to check the font size of a particular piece of text, to check it's right. I realize that firefox isn't the be all and end all, but it's a good touchpoint if you've got to work out inherited relative font sizes, before doing a more thorough check.
This got me thinking, though. How far do you go to get fonts right? I'm often given a Fireworks or Photoshop file by a designer and used to just read off the settings for each piece of text (e.g. 10px arial 130% line-height), and type them straight up into the CSS
This, obviously, leads to problems immediately, due to the inheritence issues, especially deep down in code, especially if you're inheriting from someone else's code. (This article by Richard Rutter explains how to scale fonts using ems) . Further issues abound when you're well aware that the vast majority of your audience aren't going to have the target font (e.g. when the type is set in helvetica).
My question is: do you go for pragmatism and set to what looks best, or do you go with the style guide/design to the letter, no matter how crap it looks?
In my opinion, you should aim to get the fonts looking the best in the most browsers, as close to the original design as is possible, given how much designs rely on typography.
I tend to take screen prints of my code running in a browser and then overlay the original design in photoshop, to see if the leading, tracking and font size match, and adjust the line-height, letter-spacing and font-size accordingly.
'Controversially', I'd even sanction the use of browser filters to get the fonts correct: if the design is set in helvetica, then get the arial tweaked to look as close as is possible, then apply a safari hack to serve 'mac users' helvetica (given that safari users are exclusively mac, even if mac users aren't exclusively safari users).
I imagine there are other, and probably better, methods: what have been your experiences?
Posted in CSS, Design, Typography | no comments | no trackbacks
