173. UX | Boagworld - Web & Digital Advice

Web & Digital Advice

Digital and web advice from Headscape and the addled brain of Paul Boag... tell me more

Paul Boag Posted by: Paul Boag On Friday, 3rd July, 2009

173. UX

On this week’s show: Paul talks to Leah Buley from Adaptive Path about user experience design and Marcus provides some advice on warranties and other legal stuff.

Classic shows:
The estimated time to read this article is 35 minutes

Download this show.

Launch our podcast player


I just wanted to mention the Summer Camp that Carsonified are running on the 20th and 21st of July in Bath. Its a free ‘get together’ for students or web entrepreneurs looking to discuss web start-ups. Sounds like it will be an interesting gathering and with numbers limited to only 8 places there will be lots of time for addressing individual problems. Check it out.

Back to top


XHTML 2 is dead, long live HTML 5

The big news this week is the W3C’s decision to stop development of XHTML 2 so that more resources can be put into HTML 5. In a statement the W3C said…

Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML.

Although I am no expert, this strikes me as a good decision for two reasons. First, the two ‘flavours’ of HTML was causing confusion. The overlap between the two was significant and they lacked distinctive roles. Second, HTML 5 has gained significant momentum in terms of browser support and community engagement. XHTML 2 on the other hand seemed to be floundering with little movement from the working group. According to Bruce Lawson the decision to drop XHTML will make little difference to most developers. However, one can at least expect to see an acceleration is the adoption of HTML 5 and hopefully greater support by browser manufacturers.

Designers tools

I spotted a twitter by Paul Annett this week that is worth mentioning. It was a link to a collection of Photoshop files containing UI elements for each major browser. The files contain browser windows, dropbox boxes, radio buttons and other user interface elements. This is extremely useful to any web designer mocking up a web page, and saves having to screengrab and isolate each element manually. However this resource is just one of many available on the “Designers Toolbox“. Other resources include…

It also has a load of additional resources for print based designers. It is an impressive site and definitely worth checking out.

Inspirational about us pages

Smashing Magazine have released Best Practices for Effective Design of About Me Pages. The post first caught my attention because “About Us” pages are so often neglected. As the article says…

The “about me”-page is one of the most overlooked pages in development and one of the highest ranked pages on many websites.

I get the feeling most website owners don’t really know what to do with this page. They feel obliged to have it because everybody else does, but fail to really understand its role. Unfortunately I am not sure that this article provides any answers. It focuses on the “About” pages of web designers rather than more general websites, and also shows a lot of examples while providing little in terms of ‘best practice’. That said, it has some stunningly designed “About” pages and so is definitely worth a read. They really are inspiring and will make you long to redesign your own “About” page. Toby Powell's About Me Page

Password Masking

Why is it that as human beings we have a tendency to accept the status quo? Even if we think something is a bad idea we often fail to speak up because it has always been that way and ‘surely there must be a good reason’. One example of this for me is password masking. This is the practice whereby content entered into a password field is blanked out for security reasons. Although I can understand the logic of this it has always struck me as a significant usability and accessibility issue. However, despite that I have never actually challenged the practice. Fortunately Jakob Nielsen has in his post ‘Stop password masking‘. He writes…

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn’t even increase security, but it does cost you business due to login failures. Password masking has become common for no reasons other than (a) it’s easy to do, and (b) it was the default in the Web’s early days.

I couldn’t agree more. I believe the security concerns are massively over rated and the usability issues largely ignored. Unsurprisingly Jakob has come under some criticism for his cavalier attitude towards security. Christian Heilmann writes…

As a frequent traveller I am constantly seeing people logging into web sites in hotel lobbies (when they check in for their flight for example and enter their bonus miles account details), in Internet Cafes or when they use their laptop in a public space.

However Jakob addresses this when he writes… Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they’re using an Internet cafe. It’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there’s a tension between security and usability, sometimes security should win. Again I agree with Jakob. Too often password masking is used without thinking. When a user registers for a site that contains little personal information and no financial details, why should they have to enter the password twice simply because they cannot see if they typed it right the first time! Its absurd.

Back to top

Interview: Leah Buley on UX design

Paul: OK So I have Leah Buley today from Adaptive Path. Great to have you on the show Leah, thanks for agreeing to come on.

Leah: Thanks Paul I am excited to be here.

Paul: So I heard you this year at South by South West(SXSW) talking about UX teams of one, which I have to say, was the highlight of my SXSW. I am not just sucking up it really was the most enjoyable one

Leah: (laughs) You might just be sucking up but I will take it. I will take it all in.

Paul:Yeah just take it , just go with the flow. So the reason it was so erm inspiring I think from my point of view was that the company we run Headscape was for a long time a distributed company and we then came together and started having an office, but I don’t think we have really got our heads around the advantages of all being in a office together. So all of your talking about brainstorming and stuff like that was hugely, kind of blindly obvious but revolutionary at the same time. It was a light bulb moment for me. So thank you very much for that.

Leah: My pleasure. Paul. So I thought lets share some of the stuff that you covered at SXSW with the listeners of Boagworld because I know there is a lot of people out there that em maybe are open to a new approach to the way they are handling design and User interface, usability and all that kind of thing. So lets kick off by talking about and perhaps defining design as you see it, because you obviously don’t see design purely as the aesthetics of a site, and as you were talking you obviously had a much bigger role in mind for what you would consider a designer so tell us a little about that.

Leah: yeah, well actually the first caveat I should make is that I am not a trained designer,

Paul: OK

Leah: I have an information science background and have done years of work as a developer so you should take everything I say with a grain of salt. But I think what is interesting from my perspective is that a lot of people in our field are not actually trained designers but they are doing design work.

Paul: yes

Leah: So recognising that and understanding essentially there is a process to design and how anybody can do it is an important thing and for me the way that I would define design is basically anybody who is taking a known problem and consciously reframing it, often with the use of constraints. So in my mind design is much more a process as whereby something new emerges as opposed to outcome that somebody produces. The designer or the role of the designer, anyone who does the design is to shepherd that process basically.

Paul: hmmm Yes This is kind of a complete tangent really but it was something that came up in your talk and I was fascinated by it and wanted to know a little more about it. You talking in your presentation about Forrester CX model ? Which I had not come across that description of it. I had heard of kind of a similar approach used in sales as the sales approach, but could you explain what that model is and why you brought it up in your presentation.

Leah: Sure yes , it’s a report that Forrestor’s put out called the customer experience journey it is written by a guy named Bruce Temkin who actually has a excellent blog called experience matters where he writes a lot about user experience, from the kind of business person’s perspective so check it out if you haven’t already. The interesting thing is that Bruce has written a lot about experience based differentiation for companies, which is basically just the idea that you have a better user experience you therefore have a better product and evidently his writing about his experience based definition has been one of there most popular reports, which sort of suggests that executives recognise customer experience as really critical to their success and that many of them are many of them are offering a sub-par experience right now. So then in this customer experience journey Bruce essentially explains how an organisation can build a strong customer experience practise and the report has a lot of recommendations about a corporate culture and employee training and how to deal with trade offs, but in particular there’s a sort of a model that describes five steps for the evolution of customer experience in an organisation it’s great, it’s like it’s beautifully simple but it is also deceptively simple at the same time.

Paul: yeah

Leah: The five steps are, er the first step is interested basically so at that point the customers organisation is aware that user experience or customer experience is something they should be thinking about, but they have not really done anything about it yet. The second step they get invested, which basically means they hire somebody to do some work, this tends to be someone that is at a pretty low level. At the third step they become committed, which means they have someone who is an executive who has responsibility for the outcome of that user experience work. At the fourth step they become engaged at a very high level sort of a organisation’s initiative level user experience is a priority and then the fifth step the nirvana of customer experience is that they become, it becomes so embedded into the fabric of the organisation that it is kind of like the first principles to everything we do it does not have to be explicitly called out like a project team to make the website more user friendly or a project to make our products less funky to hold or whatever.

Paul: hmmm

Leah: So emm that’s the model so it fascinates me and kinda frustrates me a little about it is that it makes it seem so linear like you can just put one foot in front of the other and eventually over time you will reach step 5. I think there are different stages that are tricky for different reasons, the leap from having lower level user experience people to executive user experience people can be awkward for organisations for a lot of reasons and what I have seen just on my personal experience is that companies have, it is not like they start out with one user experience person and then it grows and grows and grows and then ends up they have a team what happens is they have kinda epics in the approach to user experience so sometimes it’s big and they will hire big staff and in lean times or some executive goes away the staff will shrink and then some other champion will come along and he will want to bring it back. I have been in situations where I am a user experience team of one or even when I am on a team of professionals and you learn that there was a user experience practise several years ago and then it went away and it is like discovering cave paintings or hill dwellings or something and you realise there have been other people that have come before you and you are like why did they go away what happened? So that leads to like a really core belief I have about user experience practise which is that it is not built by delivering killer projects and sort of building on top of killer projects one by one but it is built through relationships and patience and mutual respect over time and that it is about really erm sort of investing the time to actually get to know the people who need to work with you as a user experience professional investing the time to understand their concerns and their objectives and to take those things seriously and to work with them as a designer to facilitate them achieving their goals as well as you achieving your goals. I know that is touchy feely but I think it is in my personal experience that that works well, has worked well for me.

Paul: I think it is very true as well I mean I think there will be a lot of people listening to this interview that maybe er you know feel like they are stuck on one of those stages and can’t progress things and can’t move forward. Whether they are responsible for their website within the organisation, whether they are a internal web designer or something else. And it is very easy to become kind of bitter and angry and become the no person within the organisation that is constantly you know fighting against the system but actually building the relationships is the best way to move things forward and you know I do a lot of work in large higher education and public sector organisations that have huge amounts of bureaucracy and it is ultimately the relationship and carrying people along with you that enables you to do things and move things forward.

Leah: Yeah. I absolutely agree and I think it is particularly interesting talking to you as someone who has worked in big bureaucracies because they are the hardest places to do it I think, it is just the bureaucracy itself can add an extra layer of frustration that is on top of the initial frustration that I think we often feel as user experience people just trying to communicate why this new area is important. So it is very easy to get embittered, yeah if I think of my own personal experience I have seen that too and the trick is to make yourself feel a little less alone and the challenge for that is if you are user experience team of one, and you do not have a big group you don’t have colleagues who have the same experience as you, you kind of have to find a way to find a way to make friends with the non user experience people that you work with and turn them into colleagues and turn them into allies and that you do through soft skills much more than design skills on some level. I think the dirty secret of design is that it is fifty percent soft skills and then the rest is design and if you can learn to listen well to people and ask more questions than you answer and I don’t know be a fun lunch date I think those are the sort of things that will serve you very well in this line of business.

Paul: Yeah, totally agree it is really interesting to hear you say that because yes, really good really good. Let’s move on before I start ranting about that particular subject. Ermhmm lets talk about Adaptive Path and the process to design that you guys take. Obviously you guys produce some superb work and I am really interested in the little glimpse you gave us in your presentation at South by of that process and how you go about doing things so maybe you could try and summarise that for the listener.

Leah: Yes of course. Well in a nutshell it is a mess it is just a total mess and I am serious about that it is a messy process and that’s part of the magic er but actually, when a little secret of Adaptive Path is and it’s design process is we do not have a set design process unlike some other companies in this field who you know often have like the discovery and then the research and whatever phases. We don’t really have a set process we what we kind of do is custom design each project to match the problem that the customers have but even so I think must projects tend to involve at least three things in some kind of configuration to one another and those three things would be 1. Trying to understand the business environment in which the project has to succeed 2. Trying to understand the user’s context in which the product is actually going to be used in the end and the third part and the thing I talked a lot about at SXSW the design exploration and when I say exploration I use that word very deliberately because we try to treat it er as a process that has to widen before it can get narrow, we try to sort of approach design as actually as a erm exploring a new field essentially but in terms of those three prongs understanding the business problem tends to be really just a lot of honestly trying to ask the hard questions of our customers in a way that will help them to be open to the answers. One of the kind of philosophies of us t Adaptive Path is that we encourage our clients to reframe or rethink everything and so that is a really great foundation then coming back to them and saying in terms of the design approach we are going to take we are going to really explore wide, really broadly and present to you some ideas that maybe push further than you would be thinking of pushing right now but we do that so we can potentially adjust those ideas for the things that are the right size for the constraints and the objectives you have right now. So the design exploration, that particular process we tend to . It is pretty basic we tend to start out and force ourselves to actually spend some dedicated time coming up with lots of different ideas and obviously that is informed by user research which is the second item that I mentioned. We try and start by going into the field to observe users and in context and get as much information as we possibly can about not just what they want to with the product but also the circumstances of their lives at the point at which they are going to use the products because one of the things we find that people are always more distracted and busy and multitasking when asking them than they think they are. Understanding the nature of that helps us to say OK now we are going to sit down and explore the designs for this product what are the constraints that we know our user has and our business has and then the constraints become just a useful device in sort of the process of design exploration hmm in that you can say well if we know that the person who is going to be using this product will also have four other applications open on their desk at the same time or fourteen other applications or forty how do we design something that is optimised as for minimal attention or for is optimised for quick hit interaction so then that little nugget becomes a thing to design with. So lets design a screen that is the ideal starting point for somebody that has ten seconds to do anything but the trick is that you can’t just let yourself stop with those known constraints, you can’t just say we have designed the screen for ten second interaction so we are done with it. If we are truly delivering on our promise that we are helping our clients rethink everything we need to explore beyond that we need to explore more widely beyond that so then we use a lot of other devices that kind of help us to brainstorm in really different ways. This is kind of a funny example but I will bring it up because it illustrates nicely how different kinds of tools help you brainstorm in different ways. We did a project not long ago where we wanted to rethink mobile devices and how we work with them in the world and so in order to force ourselves to rethink that we actually did an exercise where we went out into the world with different kinds of physical objects that were not shaped like mobile phones. They were shaped like pencils and magnifying glasses and wire whisks.

Paul: OK Leah and pretended like those things were mobile phones and imagined what we would possibly want to do with something like that and it is just great because these simple devices would help you to re.. to just forget your assumptions, we have some many assumptions about what a thing has to be and the trick is as a good designer is to force yourself to erm break those assumptions at least for a little bit of times so you can allow your creative process to suggest new ideas to you. Paul. It is really interesting it is fascinating to hear that you are doing that kind of stuff but I am sitting here thinking there are going to be people listening to this show that their design process may consist of you know understanding the business objectives, understanding the users needs and putting a bit of time into that and then they launch Photoshop or fireworks and they are sitting there and they do the design.

Leah: Yes

Paul: and your coming along and talking about going out with whisks and you are talking about coming up with loads of ideas and they are just thinking that is so divorced from the way they are currently working that is this kind of quite hard to imagine that transition.

Leah: Well I don’t think it has to be and that’s what’s interesting and that’s what I tried to talk about a little at SXSW which is that you may not be on an adventure to re-envision the mobile experience but that there are some pretty basic techniques that we can employ even when we are sitting at our desks, even when we are in front of our computers to help us think more broadly. So some of things I have talked about they are really basic they are almost like hacks you can think of them as design hacks if you wanted to 1. Is essentially stealing ideas stealing inspiration from the visuals, sort of visual sources that you encounter everyday so one idea that I really believe very strongly in is keeping an inspiration library

Paul: Yes Leah So if you are using the web and you see something that is an interesting design to you take a screenshot of it and put in some place where you stores those things and then when it is time to start designing flip through that thing flip through your inspiration library and see if there is anything that kind of inspires you in a way that you wouldn’t expect. If that is not on the level of taking a wire whisk out into the world to redefine a phone but if your designing a kind of news portal and you happen to see a guided wizard that, you know screenshot, that has some real interesting kind of treatment of help information and then you realise oh call out boxes could really work in a real interesting way in my news portal that’s sort of the level of forcing yourself to think in a different way or more broad way I also think that just playing with word association is actually so kind of beneficial and talking about what do we want this thing to feel like, or what if it felt like this plus that and then actually just doing a quick sketch of what that would actually mean or look like. The interesting thing is that I have worked with classically trained designers who would probably most certainly call me a design hack but who would say there is one kind of optimal way to design a webpage or design a sort of software that essentially takes the top priority into consideration then the second kind of priority and then the third priority and then lay out the page accordingly so people notice the top thing first and then the second and third thing. But I think the way that metaphor kind of works on us as human beings is actually much more interesting and it can create it can make the experience of using a product or a website feel like something really pungent that is not just actually about information processing it is about a user experience. Ermhmm at the IA summit Cindy Chastain a Information Architect based out of New York city did a presentation on using themes in design and the way she described these themes was basically that you sort of create a little story or create several little stories for what we design could be about and that depending on the story you take the way that you actually design that thing will be really really different. The example she gave is that she did a website for a woman who wrote all of these soap operas in the United States that a soap opera that has been popular for decades and decades she was the primary writer on it and the website is for fans of this soap opera to go and see all of these you see all of these pre-recorded old recordings of the soap opera but in figuring out ermm what experience they wanted to provide for this product they created three different themes and one theme was like the story of a writer and which was basically about the woman who worked the soap opera and the other theme was a love affair with a soap opera which is basically about the fan experience and the third was like forty decades of television or four decades of television which was basically about the TV creation process. Depending on which theme or story you were to go with would create a very different design. In fact they did pick one design that ended up being very specific and tangible and allowed them to design for a really meaningful metaphorical experience for the people who used it but you have to imagine as a end user going into a website that tells you about the story of a writer is going to be very different from a website that tells you, that immerses you in the feeling of being a soap opera fan and I think when I and so I love that example because it shows really nicely how just choosing metaphors and choosing inspiration and choosing examples can encourage a whole world of brainstorming in various possible directions.

Paul: I recently warmed very much to this principle of generating a large number of ideas and the idea of stepping away from the computer, and you have talked about having sheets which forced you to do like six wireframes, like different mock-ups on a single page and you talked about overcoming that thing of running out of steam, like you know I have done two or three designs now what do I do, type of thing. So all of that was really interesting and the idea of including other people in that process so you are not working in isolation and I went back and we did this. We sat down and got er a developer in the room and I got a project manager, I got lots of different people in and we did this and we had a really productive day and got loads done and then it occurred to me that I got five people sitting in a room for a day and that is five man days worth of work.

Leah: Ahhhh

Paul: And you suddenly go crap that is out of our budget that’s a lot. You know it suddenly meant I started going into the practical mentality is a cost effective way of doing things and should we be working like this. I am interested in you thoughts on that.

Leah: Yeah Well it is interesting I hear this concern a lot from people and I am fascinated to hear that you did it and that you did it for a day which I want to hear more details about that later on but I think that the thing is it does not have to take a day and I think that the concern that it will be a vast investment of time for everybody isn’t isn’t .. it is a real concern but I think it is something that can be managed. I have actually had some pretty productive workshops that are an hour long or two hours long and that’s if you round five people for you know an hour or two it is obviously still five or ten hours it is not a week of man hours necessarily. So I think you actually need to be very careful about scheduling sessions that are fixed in time and have clear goals and end points, and just to constrain it a little bit. I actually personally believe that constraining time is another benefit in the brainstorming process. Particularly when you get people that are not necessarily used to being usually involved in designing it can be very scary to jump right in developing ideas and hard actually so I think what happens in a group like that, is people like to think about the ideas for a while and then maybe one thing and get warmed up have a cookie or muffin or something and they feel like they are more casual and they will start sketching, you do not need that time that is just road clearing what you can do is you can give them structured activities that will get them to put there ideas on paper immediately and that will have the same sort of net effect. When we do workshops with folks we do these sort of template based workshops and we give them literally five minutes or seven minutes to sort of sketch out all of their ideas and maybe we will do a couple of rounds of that but the beautiful part is when you have five minutes you don’t even have enough time to think what it is you want to do you just start drawing..

Paul: Yeah

Leah: and it sort of it circumvents the throat clearing that happens in the sort of longer meetings erm and templates I think are really helpful actually in those workshops particularly because people are funny you know we really like to accomplish tasks, if you put something in front of us kinda well defined and has a clear end point I think our impulse is to just do it and kind of get it over with. So if you give someone a template it helps them to sort of say like draw an idea for say what you think should happen in the system explain what the important aspects of that idea are and tell me another product in the world that it is kind of like erm and then you tell them they have five minutes to do it you will be amazed how quickly people can crank out a lot of ideas and then you do a couple of rounds of that and it’s erm in a structure like that that you can really get a lot out in a hour or two hours.

Paul: I mean yeah you have hit the nail on the head there we made, you know the first time we did this we made a lot of mistakes and there was a lot of kind of oh I don’t know whether I am kind of comfortable with this, there was a lot of preamble kind of thing and also we just got tired out. You know there is only so long that you can do something like that. Now admittedly along side that we were doing things like, it was kind of a kick off meeting as well and we were kind of introducing the project to some of the people in the room and that kind of thing but to be honest putting it all together in one big meeting was too much we would have been better of splitting that over a period of time, there were reasons why we had to do it that way because one of the guys isn’t local and he was down but it did kind of get me thinking about this you know the amount of time but like you say if you have structured activities and you set time limits on it then actually that is beneficial yeah

Leah: But also I think actually it is probably important to acknowledge the point that you make that there is time commitment in working this way and it is not like, it is not like you can squeeze it in and still do everything in the way that have already been doing it, it’s there is an actual time commitment to doing it this way. We often at Adaptive Path can do week long design sprints where we essentially we do a lot of the brainstorming activities that we have been talking about in this conversation in the first part of the week and will actually produce wireframes by the end of the week and it is really aggressive and it’s incredibly productive and brings us a lot of work but you cannot do anything else during that week there is just no way. So you sometimes you have to make time move quickly.

Paul: Another thing is ultimately you get the time you are investing back in things like having a developer sit in the room is going to avoid problems later down the line where you know …

Leah: yeah

Paul: where he suddenly turns round and says hang on a minute you have come up with this is the design and we can’t implement that or there is something suggested at these early stages but because the project manager is not there it gets lost in the system and all the rest of it. So I think you know it just feels like a lot up front is the best way of describing it.

Leah: Yeah and I think it is important, you know if you are a team of one in an organisation or where you do not have a lot of support as the user experience and where they may not have a lot of erm comfort, your colleagues may not have a lot of experience or comfort or familiarity with design it is important to go just sort of take baby steps with them with this stuff. I think that you rather than coming in and you are there for a little while and you realise this isn’t quiet working lets change everything and have a two day off site and get the executives to support all this. That might be a little ambitious but erm what might be a little more feasible is to talk to the team and say I feel like there are some ideas we all have that er that maybe it would just be good to get out so that we can actually consider them directly and talk about what’s appropriate or not for the product, could be schedule a hour and half workshop I will structure it don’t worry you do not need to do anything just come with yourself and a pencil in your hand and I will give you cookies and it will be fun and that’s kind of like a starting point to get people ending up engaged in the activity and what I find is when you give people a little bit of a taste of it and they see it can be so productive they become much more enthusiastic about participating and making time for it later on. So particularly if anyone who is listening to this conversation is a team of one or is even like a freelancer with a organisation that they do not have an established relationship with I would say start out with baby steps and structure a workshop in a way that will actually help the participants to see the effects of it pretty quickly

Paul: So we have talked a lot about kind of generating a lot of ideas and you know certainly when we gave this a go we ended up with loads of ideas, erm So I think we need to end this interview by kind of going well now what? You have got this big pile of ideas how do you kind of refine them down into what you are going to actually use.

Leah: Yes, that is always the hardest part of the process actually and not at the same time I think what will happen is there will be a couple of ideas that will be really exciting and everyone will sort of know it. I do not know if that correlates with your experience but the trick is even though some ideas seem like wooh that is pretty cool or wow that would be kind of awesome if we built that it is a question of is that appropriate for the business needs that are driving the product, appropriate for the users needs and for that it ends up a lot of kind of compromise but in order to know where you make sense to compromise or where it doesn’t make sense to compromise it can be really critical to have a well articulated statement of what experience you are trying to produce.

Paul: yes

Leah: We use design principles at Adaptive Path which I know a lot of folks in the field use but for us we try to potentially create five to seven short succinct statements of what the experience of the product should be and doing that helps us to look at all those ideas and say, like this is the coolest most web 2.0 interface I ever saw but it does not support our design principle so it is probably out of the door. The key to the design principles are that they are not, it is not a statement of what the functionality of there system is, it is not like sort of brand attributes it really needs to be something that implicitly invokes what the experience is going to be like so like TiVo has some great design principles early on in the development of their product they created some statements of what they wanted their product to be and you can even when you use TiVo now you can really see a reflection of that. Their design principles were “it’s entertainment stupid”, “it’s TV stupid”, “it’s video dammit”, everything is smooth and gentle, no modality or deep hierarchy, respect the viewers privacy. These are all things they are not quite features and functionality although some of them allude to it, they are not quite brand statements although there is certainly a lot of brand personality expressed in them. They sort of describe what the experience of using TiVo should feel like and it kind so works well in that respect.

Paul: hmmm, excellent that’s been so useful I could carry in talking for hours about this particular subject, but that is certainly a brilliant introduction and I would encourage people to check out the slides that you produced for that presentation which are up on slide share if you search for UX team of one you will find them no doubt. Thank you very much for coming on the show Leah and hopefully we will get you on again in the future to talk about other related issues and we can start this whole conversation all over again.

Leah: That sounds great, thank you very much Paul, I really enjoyed it.

Paul: Good to talk to you, Bye

Leah: Take care, Bye now.

Listeners feedback: Warranties

Got this question through from Andy Wickes:

I’m really interested in how you draw up a warranty regarding a website, and what you cover and for how long.

We are constantly plagued with clients expecting us to continue to support their site months after completion even though they refuse to pay a support fee.

There seems to be an expectation that a site should never develop a problem, never break when new browsers are released, and never cause issues even though we all know that sometimes issues arise from hosts that we end up attending to on their behalf.

I agree with your that the most vital thing is a firm agreement between agency and client at the outset as to exactly what each party expects from the other, but I am keen to learn what you expect to find in a ‘standard’ warrarnty agreement, what is covered, what length of time is suitable as part of the build fee.

Slightly ‘how long is a piece of string’ I grant you, but something I know my team and friend find a constantly challenging topic!

We include the following warranty as part of all our contracts:

The Contractor warrants that all the Deliverables shall collectively provide the functionality specified in the Statement of Work. For a period of twelve (12) months from the date of acceptance by the Client of the final Deliverable the Contractor shall promptly remedy at the Contractor’s own cost any non-compliance of the Deliverables with the specification set out in the Statement of Work or such non performance of the Site.

So, in English, that means that we will fix any genuine bugs for free on a site that we have developed within twelve months of the go-live date. There are two key issues that can crop up relating to warranties.


Taking my last sentence as an example – what does ‘genuine bugs’ mean? If it’s a CMS job, then some kind of functionality defect such as a form not submitting properly would definitely fit that description. But, as Andy mentions, what about rendering bugs in new browsers? The legalese states that we will fix bugs “within the specification of the Statement of Work”. New browsers aren’t included in that.

That old adage ‘common sense’ tends to come to the forefront in situations like this. If the ‘fix’ will take a tiny amount of time and, at that point, you are negotiating another much larger project with the same client then giving a little slack probably wouldn’t hurt your relationship. However, you always have to make sure that the client knows that you are offering something that is outside of the warranty otherwise you could end up creating an expectation that it will happen every time.

Another recent example where we decided it was in our interest to fix a number of sites free of charge – that were all outside their warranty – was when early versions of our CMS became vulnerable to a security risk.

Though we could have insisted that the work we carried out was chargeable, we decided that having a bunch of broken sites was potentially more damaging to our reputation than worrying about chasing clients for the small cost of fixing the sites.


The second issue relates to what a client expects of a warranty with an agency. There is a view, I believe, that a lot of clients see a warranty as a support agreement.

We have often had calls or emails that relate to CMS usage, for example, “I can’t remember how to input a news story on to the site, can you remind me”.  Again, in this type of situation, common sense should rule but if a client is continually asking support related queries or is outside of the warranty period then explain that you can either provide an estimate for the work they are requesting or that they may wish to consider setting up a support agreement where they can call-off your time more easily.

This can be occasionally met with a frosty reception especially if you are no longer working with that particular client but, you are not being unreasonable in any way. You are simply charging for your time like everyone else in business. To use an analogy, no-one likes paying to have their car serviced but equally, we don’t expect the garage to do it for free.


As with most things contract related, make sure that you discuss what your warranty means with your new client before you start work. Concentrate on the fact that it is not a support agreement and discuss the potential need for a support agreement.

Also mention that websites, like most things, do break sometimes and often this is long after a warranty period has run out.

Back to top

Become a web expert with our newsletter

Receive invaluable advice every three weeks and get two free video presentations for subscribing. You can unsubscribe in one click.

Blog Updates

You can follow all my posts by subscribing to my RSS feed or signing up to my email newsletter above.

Podcast Updates

Subscribe to the podcast via itunes or RSS. You can also subscribe to my quick tips via itunes and RSS too.

Social Updates

I am completely addicted to Twitter so try following me there. I also have a Facebook page which contains considerably less waffle.


Boagworld is a community, not just the voice of one blogger. You've read the post, now its time to get involved.