You are currently browsing the monthly archive for July 2008.
This is a continuation from Programming is absolute. Design is proportional. (Part 1). I apologize if the start is rough, I’ve basically cut up a large piece of work into smaller, easier-to-consume parts for internet reading. Still, I’m not that accommodating as I’d like to just get this out there.
The hardest part with going from programming to designing is that no one tells you how to program, but everyone tells you what’s good design. Programming conflicts are generally internal conflicts while design conflicts are generally external conflicts. If you’re used to the one, then dealing the other is like a punch in the face.
In a programmer’s world, clients don’t interact with code; they interact with results. Clients also don’t think they can or want to critique the inner workings of the software; it either works as requested within certain performance requirements, or it doesn’t. Life is simple in that sense. You can write test scripts (automatic and human run) that confirm a function works as it should.
This is tough for a designer because you’re being told where to start, where to finish, and how long that should take to do. Basically, the problem is solved, and it just needs to get itself done. This is typically why so many people fail to see how truly and abundantly creative programming really is. They can’t see where creativity plays a role, and assume a senior developer isn’t much more than a code monkey (or they can’t tell the difference).
In a designer’s world, clients interact with your design (your code). They care about their relationship with the product. You have freedom of creativity (relatively speaking) to get their message out. They tell you what they’d like to say, and you show them the best way of doing that. The challenge, though, is that clients think that because they’ve read a magazine, or used Microsoft Office, they have the appropriate tools for determining what’s right and wrong, good and bad about an interface or interaction. Clients will generally have an intuitive sense for good and bad, so you must always be open to listening (at the very least to not piss them off), but they rarely understand why they think something is off, and they most certainly can’t tell you how to appropriately fix that problem within the world of relationships and interactions this is the current design.
For a programmer, this is an affront to your work. You’ve never been given an opinion like this, and as the expert, how dare they have an opinion on how you accomplished the goal. They had a message. You designed an interface for them that expresses their message. End of story, right? You got from point A to B, and it’s done. They shouldn’t question it, but they do. Repeatedly. And the more people on the client’s team, the more conflicting opinions on what’s right and wrong that you have to negotiate and deal with. This is unthinkable in the programmer’s world, but a daily situation for a designer, and this is where creativity helps and inspires a designer.
Working Together: Programmers and Designers Holding Hands
Historically, I don’t believe designers ever really want to be programmers, but programmers tend to want to be designers. In today’s work web-based world, designers are being pushed to be programmers (or at least have some basics down), and programmers still want to design. The lines between these two worlds is blurring, but I see segregation (of work, not physical space) as being key. Separate, but equal in my book.
If you didn’t have deliverables and deadlines, then maybe you can get away with combining the two worlds, but an efficient worker is a person who can focus on relate-able tasks. As previously explained, design work and programming don’t relate well. However, you can create an efficient flow between the two.
Designers should typically start the process. A user’s experience begins and ends with the interface. Deadwebs, pages that look like they’re functional, but just static HTML and CSS, maybe with some JS if special additions are needed, but few moving parts. The designer should not care about what can technically be done. He should go ahead with an optimal plan, and basically say to the developers, “here’s what I need to do, now tell me you know how to do it.”
Now, this is where designers benefit from understanding the technology and understanding coding from at least a beginners perspective. Different media have different optimal formats, and are capable of different layouts. A designer who’s capable of understanding some of what a programmer has to go through will smooth over the process because the programmers will look at a design, and respond with what’s possible, what’s hard, but still doable, and what’s beyond being doable.
The factors the make something doable or not will change depending on the project and company. If you’re working on an established product with an established code base, then you might be limited based on original and on going technical decisions. Still, a good system should be architectured for the designer, allowing them as much flexibility as they could dream of (which is why I don’t like many of today’s frameworks such as JSF, and my team wrote our own framework that caters more to the designers while still upholding strong middle-tier and backend techniques).
This is where having programmers understand design helps create such a code base. Being familiar not only with basic composition and layout concerns, but also with designer tools such as HTML and CSS, (not just know about them, but how they’re supposed to be used) is becoming more and more desirable. Still, knowing this stuff that doesn’t mean a programmer is a capable designer, which in my book is someone who can go above and beyond, optimize and make efficient.
Don’t misunderstand what I’ve written about segregation by what I’m saying about knowing some of what the other does. Being able to do something isn’t the same as being able to do it well. If you can’t get in the zone with the work you’re doing, then someone’s planned something poorly. Either your manager isn’t planning the distribution of tasks properly (which can be caused by poor scheduling putting pressure on getting things done versus getting thing done right), or you accepting more than you should, and trying to do more than you can.
For each type of job, you need someone who’s capable. In my book, mediocre isn’t capable. I consider a person to be not-good-enough, mediocre, good (capable), and exceptional. What it takes to be considered any of these depends on the skill required for a task, but the different between mediocre and good is someone who can do a job and someone who can do a job effectively. Simply being able to do something isn’t good enough. You need to be able to do it well, having room to spare.
I don’t look highly upon someone how can do the work given, but has to work 12 hours a day to do it. You’re over your head. You have no flexibility. There is no long-term viability at that level because if more success comes from the current work, then you’re out of capacity already. A good worker is someone who can do a given 8 hour task in 7 hours (so just because a junior developer can do something in 16 hours, doesn’t mean he should being doing it. It takes experience, though, knowing the difference between an 8 hour task and a 16 hour task, and those marks lines are always moving). Anything worse that and you’re mediocre in my book, and in many cases that means that average ability isn’t good enough. I want to excel in what I do, and you can’t excel if others don’t have the capacity or ability to excel.
As far as skill sets, I don’t look down on programmers who can’t compose a page to save their life, but I would look down on a programmer who uses deprecated HTML tags and uses inline style attributes instead of CSS classes. In today’s world, this isn’t even at the mediocre level, this is at the not-good-enough level. As far as designers go, photoshop skills is OK, but no HTML, CSS, or JS deadwebbing skills is not-good-enough. Photoshop is fantasy land, and in the real world, usable results matter, and you can’t give a programmer a photoshop image and expect them to do it, or for that to work in the media environment that you’re working in.
In the Zone
Having these knowledge overlaps allows both designers and programmers to work together effectively. Segregating the work allows each person, though, to focus on what they know best, and get in the zone doing that allowing for optimized and efficient deliverables. By having the designers start the process, you can get the project off on the right foot, but it needs to be in a consumable format that the programmers can immediate run with such as a deadweb, and not just a photoshopped image. From there, the tasks require a back and forth, “hot potato,” process that keeps the work moving, yet located with the appropriate individual as someone who is capable of doing the work optimally, and not just capable of doing the work given the time.
This is how you build exceptional products, and keep your users and clients more than happy.