Understanding your medium

“The UI is not just an interface between the browser and a human, it’s an interface between a human and a database. You can’t have an interface unless you can connect to both things. If you don’t know how your interface connects to a database, what are you interfacing to?

Ryan Singer – in an interview at Future of Web Apps London 2010

I’m a web developer. I’m not a designer. I can line things up and I don’t think I have terrible taste, but my brain is wired in such a way that I get my kicks from code and databases rather than colour and typography. While I have endless patience to learn a new programming language, an hour in Adobe Illustrator is enough to have me ready to hurl my Mac out of the nearest window.

That said, I’m a web developer, producing things for humans to use and interact with. As such the whole product – be that a simple site, an application or some web based software has to matter to me, if I’m to do my job right. So I’ve made it my business to make sure I have some understanding of basic design principles, to be able to understand where designers I am working with are coming from and also be able to make sensible decisions when I am left without any creative for an element of a build. I couldn’t do my job properly without at least attempting to understand the role of design.

However, it very rarely seems to work both ways. I’ve built a business around being a reliable web development resource for designers and design agencies. They design, we code – we’ve developed everything from simple content managed websites to large-scale web applications and everything inbetween. When I started the company – almost ten years ago – the idea of designers making a picture of a web site, chucking it at us to build and us sending it back complete, worked. Most sites were simple, the technology available was basic. Back then I was already banging the web standards drum, even so the simplicity of what we had to work with, and the expectations people had of websites made the job much simpler. A clean delineation between my job as a developer and their job as a designer worked just fine.

I don’t think this works just fine on the modern web. We’ve visited this subject before, and I strongly believe that you cannot design for the web unless you understand your medium. Without the ability to write HTML and CSS; without an understanding of how server-side code interacts with a database; without some concept in your head of how it all fits together – how can you design an interface for a web application, or even best use the available tools and technologies on a relatively simple site?

In my experience you can’t. On a really basic level, I am often handed designs that have no navigation through sets of data. Search results with no paging for example. A designer who knows that we are retrieving data from a database would understand that we might end up with more data than we could show on one page. With that understanding they could then design the best experience for the user to move through, filter and sort the data. You only know what is possible by understanding a bit about how content might be retrieved from a database.

There are so many issues here. There is certainly still an issue in agencies where the web design isn’t seen as any different to print materials that are being developed for a job. A picture of a website is created then someone has to build it to look like that picture. There is no attempt to consider the capabilities of the web or how the site will function on different devices.

There is also a big issue in that many agencies are pitching with essentially complete web designs. I believe this to be bad practice but it continues and I think is the root of lots of mediocre design out there. These pitch designs are created without full knowledge of the requirements and usually without any input from those with actual web design and development expertise, they’ll be created by whoever does the rest of the work for the pitch. I frequently see these pitched designs go right through to production, because the client liked them, so they “must be right”.

Many agencies and designers don’t see the benefit of learning how to code – if the code couldn’t be used in production. It might seem to be wasted money if you send a designer on a CSS course yet he takes 5 times as long to do something as the outsourced team you normally use. However, even a basic knowledge of CSS will mean that designer can start to think about the capabilities of CSS while designing, be able to design for a medium he understands. He’ll be able to talk to the developers in an informed way about the effect he wants to achieve and be able to understand better the constraints of browser technology. He may even start designing in the browser and handing over to developers developed mock-ups in HTML and CSS. Maybe not code that would be robust cross browser and suitable for production use, but a mockup that works in Safari or Firefox is far easier to play around with and understand and then use as the design for the final code than a flat Photoshop document with a few notes on it.

Design schedules can be to blame. If designers and developers are scheduled one after the other – the designers finish and the developers start – where is the time for collaboration? With remote teams, or even where designer and developer time is scheduled in the same company, we need to work in a completely different way. We need to allow time for iteration, for understanding how the human will interact with the UI and therefore the underlying database. Developers need to be part of the design process, right from the start and designers need to engage with and understand the development process.

This isn’t so much a rant about non-coding designers as it is about an agency model that doesn’t allow people to do great work. It’s a model we’ve been part of, because it did work once. I’m a great advocate of specializing, and of bringing together specialists to do a great job, rather than using people who an do a bit of everything. However we need to promote a new way of working together, and we need to look at how we can still do a cost effective job, still give clients solid estimates and timescales for work, while also enabling this way of working that allows good people to get together and create great work.

I would love to hear the experiences of other people – whether designer, developer or web project manager. In particular those who work in an agency situation for end clients as I think the situation here is very different than when working for a company developing products or essentially on your own websites. We need to provide clients with a cost, and timescales and I think the worry about that limited budget is a big driver for the broken models of working that we so often contend with.

I’m also going to be speaking at Future of Web Design London this year on the subject of “10 Development Concepts a Designer Should Know”. I’ll be speaking in as non-nerdy a way as possible about databases, e-commerce and related subjects in terms of how an understanding of what happens behind the scenes can help when designing how users will interact with applications. This is one part of the puzzle I believe, as the more that each member of the team understands the full workings of a site or application, the easier collaboration will be. If there is no desire to learn from one another, working together is pretty much doomed.


Steph Troeth January 26, 2011 Reply

I’m speaking as someone who has been a Director of a 30-strong production team which included project managers, IA/UX, graphic designers, and front+back end developers at an agency. Caveat: I haven’t worked for many agencies but have just noticed that the models are similar; and what I’m saying may be local to Montreal. A big part of my job was to vet estimates that go out of the door to make sure they are realistic; and it was also part of my work to make sure the right people with the right skills/inclinations got on the right projects. I was also involved in projects in very early stages to help vet the technology solutions (or assign someone to do the same), and make sure people talk to who they need to talk to at concept stage.

It took about 2 years to change the company so that collaboration happened and tech took its place at the strategy table rather just the bit that you shove in at the end to make it work. That’s probably another conversation to be had.

There are many things wrong with agencies. Some of it is timescale and estimates, as you mentioned, a lot of it is cultural and directly related to how agencies run and make money. The following are my own observations:

1) Agencies often charge by a day rate or an hourly rate. This often means that almost everything needs to be billable. It also means every time you have a team meeting it costs money per team member. The nature by which agencies charge means it’s not economical (on paper) to have too many people involved in the project because it’s hard to make that money back. If you do, you end up charging a big overhead that makes you less competitive with other agencies.

2) Agencies under pitch in order to win. Unfortunately, we are a market that competes first for price rather than for quality. I used to get into fights with account managers who under pitch because they want to win the client. The pitch is meant to seduce. Production is not, strictly speaking, sexy. The result is that the budget is way too low for the requirements that the clients want.

3) Budget estimations at concept are never revisited prior to production. This is one of the seriously dumb mistakes that everyone makes. The pitch concept/design to seduce cannot be the thing that gets produced (there’s not enough information to go to prod), but no one ever has the guts to revise the cost and timeframe between concept and production, even after say, detailed wireframes have been produced — if it was 😉

Before anyone jumps forward, I want to say that the “agile method” is not an answer. Agile is great for developing products, especially with dedicated teams. But if you’re running short-term projects with the same people across projects, you need something hybrid that’s going to map directly to how the company earn their daily bread.

Rachel January 26, 2011 Reply

Steph – thanks for your reply. Your last paragraph is almost word for word what I said to Drew earlier on the subject. Agile can work really well for dedicated teams – but can’t map directly to an agency situation.

How we get from this model of flinging things over the fence at each other to something that brings elements of that Agile process to an agency environment I’m not so sure.

Tyler January 26, 2011 Reply

It might not always hold true but with the way the web is now, I don’t know how you can really design a website successfully without at least the basic knowledge to code the html and css yourself. An architect who doesn’t understand basic building principals isn’t going to get very far. The same hold true for a designer who cannot code. Static sites are going the way of the dinosaur and if the designer doesn’t understand how content can grow and expand they will not be very successful creating the UI.

Steph Troeth January 27, 2011 Reply

I worked towards changing the culture of how people worked by appealing to their sense of achievement and using pride of our work as a motivator— the idea of a unified vision on web quality (not just standards and best practices).

A lot of it has to do with teaching people how to talk to one another. Mostly, it’s getting the team to understand they are in control of the project’s destiny (not just the project manager), and also encouraging team members to learn how to judge what best decisions to make and why.

I gave a workshop that touches on this in Paris Web back in 2007:

We had decent success while I was still at the agency, but there was still a long way to go. For example, every time there was a mass firing it takes months to patch the damage, so the method isn’t foolproof unless the greater strategy of the agency or company is solid.

I also talked about how Agile does not guarantee quality despite its collaborative philosophy in 2009: http://www.slideshare.net/stephtroeth/being-agile-being-good

By the time I was doing the agile talk though, I was mostly working in much smaller teams and I’d left the agency … if that says anything 😉

Jay Greasley January 27, 2011 Reply

I agree in the main with Rachel here, the web has evolved from a digital representation of a poster through basic dynamic sites and on to CMS powered sites and now more sites are web applications rather than sites.
I know of at least one local agency where the designers still use Illustrator to compose a comp for the web developers.
How does this convey the behaviour of the front end, let alone factor in any back end requirements. Answer, it can’t.
I started off developing in very corporate environments, using the waterfall methodolgy to detail all the required functionality etc. This is only viale in a large company and I’m not convinced it ever worked that well.
I think the agile methodolgy, when executed well, is a much beter way of working in this day and age. That doesn’t mean it is easy. Especially in an agency setting, but that has as much to do with the legacy of print and the past in general as anything else.
I know of a couple of ‘boutique’ agencies who are trying, successfully I believe, to change this. gofreerange and edendevelopment spring to mind.
It will take time, there will be commercial pressures that get in the way but hopefully, good clients will understand the benefit of working this way, not just looking fro a watertight contract to get out of paying if you go a day over ‘schedule’
Nice post and it has me thinking about design patterns and how designers and developers really need to work from a common understanding to produce a great product.

Justin Hubbard January 28, 2011 Reply

Great post Ryan, I couldn’t agree with you more. Personally I started out as a designer am now am a designer and intermediate developer. I can’t seem to find anyone with the desire you have to understand a project or take the time to understand design concepts… most developers I deal with couldn’t care less.

Maybe your next topic could be about spec work, I wrote about that: http://www.justinpaulonline.com/spec-work-stack-work-whats-the-difference/

Great article however

Priyank Sharma January 28, 2011 Reply

Very interesting point you have there. Especially the part where you mention about developers being part of the entire design process and vice versa.

Leave a Reply