       | ||
|
:: back :: |
|
:: articles :: - www.webtechniques.com - Designers vs. Programmers, Calling a Truce By Molly E. Holzschlag The "personality gap" between programmers and designers is really a matter of perception. Unfortunately, the idea that artists only design and techies only program limits the productivity of today's Web teams. Our education often teaches us that we are either creative or scientific, and never the twain shall meet. Employers extend that model, separating artistic duties from technical tasks. But how employees identify themselves significantly impacts the production process. Pigeonholing them isn't an effective way to produce quality work. Changes in Web technologies - especially the shift toward XHTML and XML - are forcing designers to think more like programmers and vice versa. This has created a growing movement to redefine and refine working roles. A recent conversation on Simon St. Laurent's XHTML-L list inspired a stream of fascinating posts from list denizens. The discussion centered on personality types, how specific personalities approach problems in their design and development work. The thread got me thinking. The Problem with Stereotyping The transition from HTML to XML via XHTML has made Web markup more abstract. This presents a challenge for designers who don't know how to work with conceptual markup. In the tradition of the debate over open source versus proprietary platforms, passionate feelings about markup are emerging. XML is now strongly entrenched in both the present and future of Web design, and that has gotten designers' attention. XHTML forces them to think more like technologists if they expect to keep their jobs, and that's a good thing. However, work teams have historically functioned by distinguishing roles. Designers are responsible for graphics, while programmers and developers produce code and functionality. This separation appeals to managers for numerous reasons: personality difficulties, rapid application development belief systems, and the need to delegate tasks efficiently. This model works, but integrating the components at the end of the process is time consuming and unwieldy. There's little or no real communication between team members who work by strict task guidelines. Separation inhibits our individual and contributory strengths. How can I, as a designer or programmer, ever be given an opportunity to link programming concepts and design concepts effectively if I'm segregated from my team members? As a result of this separation, we lose potential innovation. More Similar than Different Steven Champeon, respected speaker, writer, and CTO of Hesketh.com/inc., points out that there's as much creativity in programming and technology as in design. "Programmers aren't creative? Designers aren't serious? Please. Programming is as artistic an activity as playing with colors and shapes," he says. Sure, you do have to be conscious of the rules of syntax, but any halfway decent designer who doesn't take the constraints of his or her medium into account isn't doing design—they're just playing with colors and shapes." Champeon favors a broader perspective, "Please don't perpetuate the silly split between visuals and hard core techies any more than is necessary." He has a point, and it's an enlightened one. It's rare to hear that design and programming are similar activities. After all, as I've mentioned, Western education divides people into one of two camps: liberal arts, or science and technology. We are, from the earliest points in our education, encouraged to follow our strengths rather than challenge our weaknesses. By the time we start working, we've been successfully pigeonholed as a creative type or a techie. If we actually look at what design and programming require, there's a lot of overlap. Both are acts of creativity and precision if you're doing them well. Both require a range of skills. Whether you're designing or writing a program, a group of peers oversees your production process. Pulling colorful order from design chaos is no different than making logical, bug-free programs from the same chaos. Designers must not only understand color, shape, space, and typography, but also how to use complex tools to achieve results. Similarly, programmers must understand the component parts of programming as well as a range of tools. A well-written program is as elegant as a well-designed visual composition. In essence, designers and programmers do the same things contextually, the content is the major difference. The Need for Hybrid Employees Not only is stereotyping employees a detriment to the work we output, it also undermines the needs and goals of team members. Many people working on Web teams are already finding that they like sampling different tasks from both the programming and design sides. "I used to work at a Web agency," says Nick Finck, editor and publisher of Digital-Web magazine. "I left because they didn't allow me to express my true interests: hybrid developer/designer." People with diverse talents, Finck contends, are the "only hope for finding someone who knows both good design as well as what is conventional with markup. We need more hybrids in the world." The hybrid concept that Finck mentions is critical. The way we work today is more streamlined than the way we worked a bit earlier in the Web's evolution. But, for now, hybrid personalities seem to be rare. When I meet someone who isn't intimidated by either programming or design, it's usually someone who got started in the online industry very early. This is because most businesses structure the workflow in a way that limits employees. Giving employees a rigid job structure may make it easier to find the right person to blame when something goes wrong, but it's not conducive to producing the best end product. Of course, there are those who disagree. James Eberhardt, Team Lead for technology and development at Infinet Communications, says, "You let designers design, and programmers program, then each of them will perform their task at a higher level than if they had to do both. The end product will be superior." But is that true? No. How many times do people knock heads, make unreasonable requests, waste each other's time with fruitless arguments that wouldn't have had to occur if they better understood the other person's position? Savvy project managers who're interested in rapid site development and deployment can use employees' individual strengths to advance that end. In fact, project managers spend most of their time translating program limitations to designers and vice-versa. This places the onus of effective team management and quality results on a single person. It's a simple model, but not an effective one. Let individuals work it out and give them a sense of responsibility—and ultimately pride—in the combined effort. If there's a split between designers and programmers in the workplace, that rift can delay completion of project goals. Even if you add a good project manager to the mix, the separation means that an awareness of problems, limitations, and general concerns have to be communicated through a second party. Let's take an imaginary case in point. The designer on our fictitious team is working in Photoshop, generating images for an approved composition. But the programmer has been told that certain portions of each page need to be dynamically updated. Looking at the design together, the programmer and the designer can easily solve problems that might arise before generating the graphics and code. But, if they just have their individual specs and follow them, the debugging occurs after the fact, and in some cases that means redesigning the whole approach. If the project had begun with everyone working together in a round-table fashion, the problem might have been avoided. What's more, when all working members of a Web team educate each other about limitations, it saves a great deal of time and money. In this scenario, the manager's role shifts from one of total responsibility to one of management and support. He or she can now focus on encouraging development of hybrid skill sets so that team members can communicate even more effectively, instead of chugging along separately and trying to cram everything together on deadline. If the manager works to integrate employee skills and support hybrid personalities in roles most suited to them, he or she can create a production process that really involves teamwork and uses each team member's talents to the utmost. But managers often crush hybrid potential without even knowing it. This usually happens because the manager in question is unaware of an individual team member's thoughts about the production process. Talk to your team members and find out what each individual perceives as his or her unique strengths and interests. Think about the personalities of your team and encourage them to communicate their ideas without limiting themselves to a particular job designation. A Better Way to Work The scarcity of hybrid personalities is due in part to education. Add to that a workplace tendency to keep the design and technology departments separate, and problems arise with communication, streamlining the work process, and of course, innovation. Alan Richmond, who was an original creator of the awesome Web Developer's Virtual Library and now publishes Encyclozine sums up this idea very eloquently: "A good site isn't built only by brilliant programmers, or by talented graphic artists, or by lucid content authors, or by insightful managers. It will be built by their synergy, each one respecting the contributions of the others, and feeding off it for the inspiration for their own creativity. Building the Web is a collaboration at all levels." copyright © 2002 ebiznet99.com |