Every interactive project has two key goals: get the right information to the user, and look good doing it. This demands several things: being an expert on the content, presenting cleanly across many browsers and e-mail systems, putting key content out front, and helping the user find what they need.

Those last two items might seem like the same thing, but they really aren't. In every web site layout, there's a tension to resolve between marketing and user centered design. The end user just wants to find the information they came to get. The marketer, meanwhile, has their own ideas about what the user needs to see. It surprises me how few sites really succeed in meeting this goal, which is why it's usually one of the first things I want to hammer out with a client during discovery. If this problem isn't solved by the time the wireframes are done, the project will be behind from the start. On the other hand, if good design, smart information architecture, and deft communication rise to this challenge, it saves time and leads to a better product.

Before moving into a producer role, a lot of my career was spent designing and managing content. From this experience I've learned that a content management system is only as efficient as the people organizing it, that raw talent is only a small part of what makes a designer good, and that some of the most tangled discussions one can ever expect to have in an organization are those revolving around who owns a piece of interactive content.

Two of my favorite works on design are The Elements of Typographic Style by Robert Bringhurst and Jakob Nielsen's useit.com. Bringhurst's book has just about everything a designer would need to know about creating grids and arranging type following classical proportions. For those who want to break the rules, it's a great book for learning what the rules actually are. Nielsen's web site is too minimal for my tastes, but that's part of the point he's trying to make. Before a web project gets lost in glitz, it should make sure it's delivering on both what the user needs to find and what the site stakeholders need to communicate.

I've been making web sites since 1994. In that time, I've done front end coding, back end programming, design, copywriting, content management, and information architecture. Having worn just about every hat, I know what goes into each role, and I get pretty excited about connecting the dots between the people in them.

My present position as producer on a large, complex web presence demands coordinating between multiple teams of developers in and outside my company. The bulk of my work is with a vendor whose team of ASP.NET programmers developed and maintain our proprietary CMS. I also spend a lot of time working with our in-house team of AS/400 developers and another vendor who developed and maintains our customer service software. On any given web project, I need to know what the programmers are doing, where the dependencies are between the pieces they're working on, and how all of these moving parts interact with business rules.

On the e-mail front, I manage day to day operations with two bulk e-mail vendors -- one for product promotions and another for CRM. This demands working familiarity with all of the data sources driving e-mail recipient lists, as well as what can go wrong with them.

My current work environment is a high-stress, high-volume, "get these eleven things done yesterday" kind of environment. There are no fool-proof plans, and priorities change constantly. The twin beasts of shifting business rules and scope creep rear their heads regularly. But then, life at a real business never reads as neatly as an O'Reilly book. If it did, no one would need project managers.

Two books on project management have really helped me. The first was The Mythical Man Month, a book on software projects. The CEO of the first company I ever worked for, a dot.com startup, gave me a copy when I'd been working with him for about a month. Although the engineer who wrote it was talking about experiences he had in the sixties and seventies, it remains a great book about how to organize projects and keep them on schedule. The second is Web Project Management by Ashley Friedlein. About a third of this book I could have written myself, and the other two thirds, I wish I'd written. It goes a long way toward presenting a useful methodology for organizing web projects, but the best parts are the practical advice and observations Friedlein offers. This book came out in 2000, but just about anyone who does what I do could still learn something from it.

I’m not a marketer, but you don’t work with MBAs for years without learning a lot (unless you’re sleeping). Interactive isn’t an end in itself. It’s a component in a strategy to connect with the customer. When working with a client or employer, the first thing I want to know is where interactive fits in that strategy.

I've worked in companies with many different marketing strategies, from those who were strictly direct marketers to those who worked mainly on a business to business strategy, with many gradations in between. I'm a quick study as far as what marketers need in a variety of scenarios. I'm a student of branding and identity systems, but I'm just as interested in the nitty-gritty of what gets specific audiences clicking. Experience has taught me that what gets audiences moving doesn't always follow the neat schematics that the design world might hope for.

Marketing people usually have clear goals for a site, even if they're not quite sure how to get there. When planning and executing a project, I put a lot of emphasis on identifying places where the technology can be leveraged to best advantage in meeting marketing goals. This piece of the puzzle is often my favorite part of a project. I enjoy figuring out how to bring to bear technological capabilities marketers might not have thought of on their own.

I don't really read marketing books, as it's not my discipline, but I do keep an eye on the blogosphere. Having a del.icio.us account and checking it a few times a day can reward someone in my profession with a lot of useful tidbits, not all of which have to do with the latest CSS technique. The most interesting thing I've read lately, though, is an O'Reilly straight-to-PDF publication, Lead Generation on the Web, by Thomas Myer. It's a very well thought out discussion of a single important topic: how to use web forms to capture customer or prospect info. Myer is realistic about how much you can really glean, while proposing some interesting uses for this data once you have it.