In this weeks show we learn lessons from the botched iPhone launch here in the UK. We chat to Jeff Veen about the designer / developer relationship and Marcus talks about adding jingles to your website.
News and Events
The Mobile Internet has reached critical mass
This week saw the release of a new report by Nielsen Mobile entitled “The Worldwide State of the Mobile Web“.
The gist of the report suggests that the mobile web is considerably more popular than many of us would believe. 15.6 percent of mobile subscribers in the US and 12.9 percent in the UK, use the mobile web regularly. In the US this equates to 40 million users. A substantial number.
Interestingly the most common device used for accessing the mobile web is not a smartphone but rather the Motorola RAZR. This reenforces the answer I gave Wayne in last weeks show. I said we cannot design exclusively for devices such as the iPhone.
With people like the VP of Google stating that the future of the internet lies with mobile users, there can now be little doubt as to the direction things are moving. This is especially true now that we are seeing unlimited data plans.
Web Standards Curriculum
A regular complaint I hear from students is that they are concerned about the out of date techniques they are taught at school or college. With many institutions still teaching table based design it is a legitimate concern.
Fortunately they are not alone in this concern. Opera and Yahoo! have teamed up to produce a web standards curriculum. This curriculum teaches best practice in web design and is broken down into modules that can be taught either by themselves or part of existing lesson plans.
If you are a student or educator definitely check this out. Hopefully you can get it adopted at your institution. Even if you cannot, there is nothing to stop you working through the course yourself.
Working with designers
Although our next post reads slightly like a rant (I should know what a rant sounds like!) it nevertheless communicates some excellent advice.
It is a post aimed at clients and provides 12 tips for working with designers. Advice includes leaving preconceived notions at the door, be specific in your requirements and design for your customers and not yourself.
There is no doubt that many clients serious misunderstand the role of the designer. However if I was a client reading this, I might find the tone hard to swallow. Despite that I would encourage those of you who work with designers to read this article. My favourite quote is…
Just as writers are not just people who can type, designers are not just people who can use graphics programs.
Web form design patterns
Our final post this week is a survey Smashing Magazine have done on 100 popular sign up form. The idea of the survey is to give you a better understanding of what makes an effective sign up form.
Of course, just because other sites do things in a certain way, does not make that the best approach. You should never blindly follow the crowd. Nevertheless this is a fascinating read.
The post is split into two parts and contains information such as…
- How the link to the sign-up form is titled
- The placement of sign-up links
- Whether the sign-up form is a single or multiple pages
- How labels are aligned
- How many fields are mandatory
- What help and tooltips are provided
- How validation is managed
- How error messages are designed
- Is it necessary to confirm the email address
- Is it necessary to confirm the password
The list goes on.
If you are looking to justify design decisions you have made or need some help designing the perfect signup form, this is a great place to start.
Just a quick reminder that the news we feature on the show is only a fraction of what myself and Paul Stanton post on the website. To get a more comprehensive view on what is happening in the world of web design, make sure you subscribe to our news RSS feed.
Feature: Lessons to be learnt from O2
I am not sure whether you noticed but this last week saw the launch of the iPhone 3G. It would certainly have been hard to miss it.
I don’t want to add anymore to the endless discussion surrounding this launch. However, I would like to focus on a side issue. I want to look at how O2s website handled this momentous event and what we can learn from their mistakes.
Interview: Jeff Veen on working with developers
Paul: So I’m very excited to have Jeff Veen joining me today on the show. Good to talk to you Jeff!
Jeff: Oh, it’s absolutely my pleasure. Thanks for having me!
Paul: Well it’s really good to get you on the show. I’ve wanted you on for ages, but I haven’t had the guts to kind of approach you so I sent Ryan to talk to you instead. I feel vaguely like, you know, you get at school discos where you fancy a girl and you send your best friend over ’cause you don’t have the guts to do it yourself. Or is that just me?
Jeff: Well I’ll tell you, I’m happy to have this dance Paul. It’s great.
Paul: Right, well for those that don’t know you Jeff and don’t know your background can you just tell us a little bit about yourself and how you ended up in a situation where you ended up working for Google. You know, how did that come about happening? ‘Cause that’s what we’re going to talk about a little bit today is your experiences of being at Google.
Jeff: Well, I tell you I’d been working with developers, as kind of more on the design side for quite a long time. Do you remember hotwired.com from Wired Magazine?
Paul: Oh yes, definitely.
Jeff: Way back when, right? Like we launched that back in 1994 and that’s really when I got started on the web, was coming over to Wired, working on their online properties like Hotwired, Webmonkey, and HotBot search engine, you know stuff like that. So I was with them for quite a while, they went through an acquisition and brought us over to Lycos, that big search engine. And then from there I started a company called Adaptive Path. Adaptive Path is a user experience consulting group in San Francisco. It was seven of us, we were all friends from the industry. We really focused on research, design, information architecture, usability, stuff like that. And I did that for a number of years with them and then finally convinced my partners that doing a product would be something interesting for us to try. We had done consulting. We had done some events. So we were kind of looking for the next thing to try. So I put together a small team of developers and some other designers and we made a product called Measure Map. That was a web analytics tool aimed specifically at bloggers. And just as we were about to launch it, we had done a bunch of work on it, Google gave us a call and said, “We love what you’re doing. We want you to come over and bring that to Google.” So we went through an acquisition there and that’s really how I got to Google.
Paul: Ahh, I see. ‘Cause I remember very vividly Measure Map coming along and getting very excited about it and then it kind of disappeared.
Jeff: A little bit, yeah.
Paul: Yeah, ’cause you got swallowed into Google.
Jeff: Well Google was very clear that they had a lot of respect for the work that we had done around designing Measure Map and wanted us to apply that expertise to their big Google Analytics product which had recently, sort of. They had acquired a company called Urchin, which had kind of an enterprise analytics package and they had made it free, and that had brought it to a whole new audience that really, sort of, didn’t quite understand how analytics worked. So we brought some of the best practices of design into Google and redesigned Google Analytics to make it sort of, kind of maintain all the power that it had, but make it much more accessible to a broader audience. So that’s really what we spent our time doing at Google.
Paul: OK, so we saw Google Analytics and those changes that you made to Google Analytics appear a few months back, and you know, were very impressive. But I’m quite interested in what happened. How did that come about, and how did that process work? So you arrive at Google, you walk through the door of Google. Now, one presumes that there was an existing Analytics team already working. Is that right?
Jeff: Yeah, that’s right. There was probably about twenty developers or so that were working on the Analytics application. Almost entirely all, sort of back-end engineers. As you can imagine, something of that size and scope, it’s a pretty impressive technical feat. The amount of data that they’re tracking every day, really just continues to blow my mind how much scale they have over there. So there was really, really talented engineers that had been working with the product for quite some time. That product had been around for a number of years. I think they were in version six of the product. But, to their credit, the Director of Engineering, a guy named Paul Moret, really knew that he had to change that application for this new audience that he had, sort of had started to grow by being at Google. So he was really behind the idea of completely rethinking. “Like lets,” he said, “Let’s start from scratch. Right, we have a lot of users. We have a really powerful product that I want to completely rethink how this happens.” And so, yeah, we really just rolled up our sleeves and sat down with him and his team and really sort of became one team. Got in there and made a lot of change. One of the things I think that really helped us be successful there was that we had a pretty robust methodology for user research that really resonated with a lot of the engineers that we were working with. It was really sort of. It was like I said, pretty mature, had a lot of data behind it so we could really show a lot of the work and helped us really get over a lot of the perceived subjectivity of design. So, you know, you can imagine this team comes in. We are a bunch of relatively technical designers, but still designers. And we sit down with these very, very technical engineers and we kind of showed them a process of how we were going to talk to a lot of the existing audience, a lot of the new segments of the audience, take everything that they told us and kind of boil it down into a lot of actionable next steps. And a way of prioritizing what features and changes we wanted to make. And so rather than us kind of going off, doing a bunch of design work and presenting it to them, we really involved everybody, or as many people as we could, in the process of how to change that application at its very basic level. So I think the results of doing all of that with the technical team was that we built a lot of trust between us. So that we could take some of their fundamental assumptions and really question those, but include them in that process so that there was a lot of give and take.
Paul: I mean yeah, because your initial reaction when you look at a company like Google, that it is a very developer-centric company. So I was kind of half-expecting you to say that you encountered quite a lot of resistance to the kind of design changes that you were introducing, but from the sounds of it, because your methodology is quite scientific, for want of a better word, you know it’s very logical, etcetera that it sounds like it went down quite well.
Jeff: Yeah, it did. It feels like we’re using the scientific method: doing testing and research and analysis and things like that. Ultimately though, so much of design is really, really hard to measure. Especially when it comes to matters of taste and perception and things like that. I mean, we can measure click-throughs and we can measure conversion rates and things like that, but ultimately the changes had to come from just being good designers. So having this relatively, kind of quantitative analysis that we did just allowed us to sort of speak on the same terms with the engineers. Have them trust us, and then let us make the changes we felt in our gut we should be making. So a lot of times I’ll be working with somebody who is very technical and they want to say, “Well if you make that change, can you show us some data that’ll prove that that’s the right change to make?” And almost never can I do that. Right, like we can do little tests and we can do some A/B testing and multivariate testing and stuff like that. And that’s good for little incremental changes but when you’re fundamentally changing an application it’s almost impossible to measure the accuracy of the decisions that you’re making. And that can be hard for somebody who really is a very analytical thinker, very quantitative in the decisions that they make, to sometimes kind of let go and say “No. You’ve go
t to trust us. It’s just going to be better.”
Paul: So were there other techniques that you used beyond providing data to kind of bridge that gap between the way that maybe designers see the world and that of developers?
Paul: Yeah, I can really understand how that would make an enormous difference. So I’m presuming that you talk about your little team of people that went in there and started doing prototyping and stuff like that, but obviously you’re going to want to engage more with the developers that are there. I mean, the traditional danger has always been that as a developer and a designer you work independently. The designer does his thing. He hands it over the partition to the developer. The developer goes away and does his thing. Now I presume you wanted to avoid that. So how did you establish that working relationship? How did you end up working closely together?
Jeff: I have almost no interest in that sort of “waterfall method” where somebody goes off and does research, hands it off to designers, designers then do some of their magic, hand it off to developers. I’ve never been successful at doing that, primarily I think because I learn so much from the process of building things. So again, it was just, really one of the first things we did was invest a lot in getting the teams to trust one another. And that meant really just spending time with each other. So that meant almost every day just scheduling some time in the conference room for us all to kick around ideas, to look at some of the existing work that they were doing, some of their future plans and just spending a tremendous amount of time with them. We also just had our desks right next to the development team. We were embedded, we were just right there. So we felt like part of the team. We’d all go eat lunch together. I mean simple things like that just make the development process so much more, so much easier because there’s real people working with each other rather than faceless “other people” handing specs over. So putting a lot of time in: absolutely crucial to success in a process like that.
Paul: So obviously you got to work with a great group of people over at Google. Some of the most talented developers in the world I guess. So I’m really interested to know, what was it you learned from them? You spent all this time with them, what was the kind of thing that you took away as a front-end interface designer what did you learn from this amazing group of developers?
Jeff: Well, a couple of things really. I think the thing that struck us the most when we first got there was just the enormous scale of everything. Like Google, as you can imagine, Google has lots and lots of users, but they have a tremendous diversity of users too, literally from around the world. A statistic that we throw out all the time is that seventy percent of Google’s traffic comes from outside the United States. So the audience that we were used to designing for is really the small minority of people, and in fact the rest of the world is where all of the products are being used. So we had to think about that diversity of audience even in the design decisions that we were making every day in that everything that we were designing was going to be translated in up to forty different languages. So that was probably the first thing that really brought our attention. The second thing was the unbelievably high standards that Google had for their products. Like you said, I totally agree, they’re some of the best engineers in the world. They have coding standards. They have testing standards, QA standards that were absolutely remarkable. I just learned so much about how every little detail fits into place to make a product that’s as robust and as really scalable and useable by a global audience that Google has. It was really like I got a crash course in some of the best computer science education I could possibly ever ask for.
Paul: Very cool indeed. So for the designers that are listening to this now, the front-end people that maybe are working with developers day in and day out and secretly behind their backs are having a bit of moan about those developers, they’re finding them quite tricky to work with, what advice would you give them about interacting and working with developers?
Jeff: Well, like I said, you’ve got to spend time in the trenches with them. That I think is just the most obvious thing that I can recommend doing. For both sides. It was hard for me to trust a lot of developers, like “Oh, you’re only concerned about your servers, you don’t care about users at all.” Which of course is completely false, but that’s an inherent bias that I would have. So again, spending that time: incredibly important. I think one of the things that I try to educate the most while I was there was that the level of detail, the care, everything that goes into the coding standards that engineers have, we have that same standard for the interfaces that we build. So I think sometimes, and I hate to generalize across developers, because I’ve worked just the entire spectrum of developers. One of the themes that I hear from time to time is that design is something that kind of happens at the end. Like “We do all the hard engineering. We get all of these systems in place and write all of this code and then we need some designers to come on and put the interface on so that we can actually launch this thing.” That I think cheapens a lot of the work that we do, and it’s a little bit demeaning for the discipline of design, of user experience. So I think we have biases on both sides and that frankly understanding more about what goes into the process both from a front-end and a back-
end point of view is kind of what brings us all together.
Paul: So if you could communicate one thing to the developers, one lesson, the question the other way around I guess. I guess in some ways it’s the same answer, isn’t it? It’s kind of stick with one another.
Jeff: Yeah, a little bit. Also there’s some really simple techniques that I’ve used, for example: even before we started we’d schedule a usability test with the existing product and get the engineers into the room behind that one way mirror and we would just watch. And we would watch people flail around with the interface and struggle and get frustrated and push the keyboard away. I mean that’s just golden. People see that and they’re just like, “Oh man, we’ve got some work to do.” So making it as clear as possible, what our users are trying to do, how we can all collaborate together to help them: incredibly, incredibly important. That said, it wasn’t, you know when I did consulting at Adaptive Path I was inside lots of companies. I worked with some of the biggest companies in America and saw inside of them and, to be honest, Google is truly a user-centered company. I was just so impressed with that. Broadening that idea of user-centered technology development is something that we worked on. Making it more of a balance between front-end and back-end is more some of the things we worked on. But ultimately I think Google really understands that putting users first is the way to be successful. Just look at the search results page with it’s very simple but incredibly effective advertising techniques, and you know, Google never had a front page that was full of the sort of portal design stuff that Yahoo! and other companies have done. So really, it was very fertile ground for the kind of work we wanted to do when we got there.
Paul: Very interesting. I’ve just thought of one other question that I get asked a lot from people looking to get into web design: they say, “So what am I better off doing, you know, where’s the best place to work? Is it in the large company? Or is it doing something in a small company by yourself?” Now you’ve obviously done both of those and there is no definitive answer, but what would you see as the pros and cons of a large company in comparison to working somewhere smaller like Adaptive Path?
Jeff: You’re right, in my career I’ve got swung back and forth between big and small. There are definitely benefits and drawbacks to both of them. In the bigger companies I think just inherently things move slower. Now, I mean Google is renowned for it’s “bottom-up culture” and good ideas are always emerging from people taking their twenty percent time. None of that is a myth. That all really happens. But at the same time, like I said, when millions of users, or hundreds of millions for some of the products. You just have to take a lot more steps, and what that does is it increases the distance between the idea that a designer or developer has, and a user actually seeing that idea. And one of the things that I love about this sort of entrepreneurial startup environment is that you can think of something, you can try it out, you can get it in front of your users. You can do that in an afternoon. And you can’t do that with a product like Gmail or Adwords or something like that because there’s so much inherent infrastructure and risk, things like that. I think it’s incredibly worthwhile for people to have both experiences, and frankly see what they like best. One of the things I really have learned in my career is that there are people that like to start things, and that there are people that like to run things. And there is no inherent judgment between the two, but once you understand “Ooh, I love having a big system and having that system run perfectly, and putting all the things in place to keep that, you know.” And that’s fantastic. I’ve learned, in my career, that I’m kind of on the other side. I love starting with nothing and building up something, and at some point I need to hand it off to somebody who is much better at running and maintaining, right. So those are the kind of things you learn by doing a lot of very different projects and product development and stuff like that as your career kind of goes on, I think.
Paul: So you’ve left Google now? So what’s the next step? What are you up to at the moment? Let’s finish on a looking forward note. Where are you going? What are you doing?
Jeff: I was at Google for just over two years and left about six weeks ago, and to be honest I’m spending a lot of time right now cycling and trying to sleep late, and things like that. I tell you it’s a tremendous luxury and I’m not taking it for granted at all. The immediate next thing is that I’m organizing a little conference with my colleague Bryan Mason, who I have worked with at Adaptive Path. He and I are doing a conference in San Francisco in August about starting companies. Yeah, as I was leaving Google I was thinking, “Well, what should I do next? What would be interesting?” So I talked to a bunch of my friends who have been entrepreneurs, or who are now investors and I just asked them, “Tell me your story. How did you get to where you are?” And I found those stories so interesting that I thought, “Man, we’ve got to share this. This is great.” And I thought, “Well, I could do a podcast or something like that.” But then I thought, “I love getting people together and having sort of a community feel.” So we thought: we’ll get one day, San Francisco in August. We’ll get everybody together and we’ll just have these conversations. So I’m really looking forward to it. It’s called “The Start Conference” and you can find it at thestartconference.com. That’s what we’re doing now.
Paul: Excellent stuff. Thank you so much Jeffrey for coming onto the show and talking about that. The issue of designers and developers working together is something that’s really important and I think there’s a lot of work still to be done, and it’s good to see that there are people out there that have got it right and are going in the right direction.
Jeff: I appreciate that Paul.
Paul: Thanks for your time.
Jeff: Thank you.
Thanks to Todd Dietrich for transcribing this interview.
Adding a jingle to your site
Chris writes: A client of mine wants to incorporate 4 second jingles at various points on their website, triggered on page load, to reinforce their servicing brand. My first reaction is that this could get annoying but was curious as to your thoughts on the use of audio on the web.
I don’t think that there is any set ‘rule’ here but basically I would agree 100% that you shouldn’t do it because it will annoy the hell out of the site’s users.
There is an argument that audio branding can be included if th
e user only has to hear it once. However, I would dispute this as well for the following reasons:
- It may well still annoy (and therefore have a negative effect upon) the site’s users
- Users aren’t expecting it and it could embarrass them in an office environment
- Quite a lot of users will have the sound off. Therefore, if you decide that the audio is only an ‘add on’ for the brand then you may as well conclude that it’s not necessary at all.
I have talked about audio on website before and reached the conclusion that, even though technology and bandwidth makes it more doable, it’s the wrong medium for audio. I think I likened it to having a soundtrack while you’re reading a book – it’s just wrong!
Of course, there are no doubt exceptions to this rule – really well thought out and produced audio indicators on a web app for example – but, generally speaking, audio branding on a website will have a negative effect. If your client is insistent, try and persuade him to include a video download on the site where audio will certainly work.
Fixed or bespoke pricing
Jon writes: We are a small web design and development company (4 people) and have tended to concentrate on higher value bespoke work. We are probably about to merge with another slightly larger company in a neighbouring town. This other company have traditionally aimed at a somewhat lower value market.
My question is about pricing. The other company operate to a very structured price list (£x for a 5 page brochure site, £Y for a basic ecommerce site, £Z for an ecommerce site with knobs on etc). We have always priced each project individually using a mixture of time costing, guesswork, and a “how much can we get away with” approach.
Do you think that a merged company approaching a wider market and value range would be better to adopt one approach or the other, or continue to do both? Would the existence of one approach damage the ability to operate effectively at the other end of the scale?
I guess the big question here is – are you going to remain as two different entities with some shared resources, or are you going to merge more fully and share work between the team no matter where it is sourced from (i.e. will one of their designers work on a future project from one of your existing clients)? If it is the former (which I suspect it isn’t) then I would keep the two pricing models the same as they are. I wouldn’t try and hide the fact that the two companies have ‘merged’ though, just explain that there are two teams delivering different services.
However, if the two companies are merging more fully, then I think this is actually fairly fundamental stuff. It’s almost like you’re all starting again and need to write a business plan. I think you would be opening yourself up for much criticism if you tried to operate both pricing plans.
I suppose other questions to you would be:
- Which pricing plan is most effective (who is making the most profit)?
- What does each company’s order book look like? I.e. have you just signed a massive contract at your higher rates?
This is interesting stuff and I’d like to know how it works out. I suppose the biggest unknown for me (that may well answer all of my other questions) is that I don’t know the reason for the merger in the first place.