What workflow do you use with asp.net web forms development and your design department

Question

I work at a place that has a clear separation between designers and developers. We're a fairly new start-up and we're trying to figure out what would be the best workflow for our team. We're a small company with a total of about 11 employees, three of which are designers (they deal with the HTML, CSS, some jQuery), and three developers primarily working with ASP.NET Web Forms. I am one of the developers and don't have a knack for design, but I am comfortable enough with CSS and jquery/Javascript to understand the mechanics and whatnot.

So, currently we wait for the designers to provide us with HTML structure clobbered together with server-side includes, js, jquery, css, etc.

Typically we try to work around their stuff and begrudgingly try to keep their structure roughly the same with the consequence of forcing us to have a lot of hacks in place to work with it. Yes, this means using their Server-Side Includes mixed in with our .aspx pages, amongst other things that seem to go against the general asp.net web forms flow.

There have been times when I have changed the includes into a user control and had their common HTML out in master pages, etc. All of which was consequently followed by a lot of barking from the design team. Their main complaint being that master pages and user controls make their maintenance of the site more difficult.

I can see their point of view, and I wouldn't like it either if people messed with my workflow either, which I guess I am doing so with them.

I have tried several times to approach them about moving site structure that complements the asp.net web forms environment we programmers are working with, but every time the subject of working with master pages comes up, the design team throws a near tantrum.

Our current approach is simply forcing us to put together a lot of hacks and work-arounds so that it gels with their design and frankly it's getting frustrating and just adding more unnecessary technical dept to our projects.

My question is simply this: what workflow works best for you and your design team?

Do your designers know how to use master pages, etc.

Is it unreasonable to have designers understand the mechanics of how master pages and user controls work, and in general how ASP.NET puts a page together? (I don't feel this is an unreasonable expectation of them...)

So, what do you guys think?

Answer 1

Where I work our designers make their layouts (usually in Photoshop) and hand us a picture of what some of the pages on a site are supposed to look like. It is then our job to translate that picture into a website.

Advantages (at least from my perspective):

• We get to keep a separation of concerns (designers make it look pretty, I make it work technically)
• The designers don't have to know html / css so much
• I don't inherit any "special" html / css / javascript from someone else. If I want "special" code, I can make it myself (I'm not saying that designers aren't necessarily incapable of writing good html, etc. , just that generally they do not approach the problem with the same perspective and goals as a programmer.)

Disadvantages / More work for developers

• Sometimes this leads to the developers having to come up with interesting (some good, some not) solutions to do what the designers have invented.
• Sometimes we just have to tell the designers that their idea just isn't going to happen. This puts the burden on us to explain why it doesn't work and to suggest alternatives.
• We have to treat the designers like clients sometimes and work with them to make sure that their vision of the website and what we make are the same or close enough (ie. UI functionality like color changes on mouse hover).

I like this approach because I don't have to come up with good / pretty designs. I get to take a nice design and translate it to something that isn't going to be a technical disaster for the developers to maintain.

TL/DR: Developers do the technical stuff, designers make pretty pictures

Answer 2

Is it unreasonable to have designers understand the mechanics of how master pages and user controls work, and in general how ASP.NET puts a page together?

Yes, it is, beyond general conceptualization.

Your application should have sufficient separation of concerns so that the designers don't have to think about the way your website works (the underlying mechanics) in order to produce a classy, effective design. They do need to know what you want (via a story board or similar communicative device), and it's very good if they know CSS and HTML, but the actual website machinery is the responsibility of the developer.

The corrolary is that you should leave design work to designers. Graphic design and layout is pretty much a completely different skill set than programming. As a programmer, you do have to know something about human factors (i.e. what constitutes an effective user interface), but in general the use of color, style and such things should be left to the designer.

---

Note: Your integration work would go much easier if you were using ASP.NET MVC instead of ASP.NET; less shoe-horning would be required, and you could use your designer's templates as-is, with much less hacking. ASP.NET MVC is better suited for doing this sort of thing, because you don't have to fit your templates into ASP.NET's world view.

Answer 3

Whoa. You're changing how you build your house to make it easier on the interior decorators? You need to get your designers out of your development workflow and into their own workflow.

Design is not Development

Leave the designers to do what they do best, which is design. If you have a designer telling you how your application should be structured internally then there is a serious problem. Master pages and user controls are near necessities when building an ASP.NET web site, and you should never have somebody who's wielding the HTML and CSS paintbrush telling you How All That's Gonna Work. They have their own incredibly difficult world to deal with.

Push the designers away, and let them have their own ball game. They want to work in Visual Studio? Fine, hook them up to a separate repository and you pull down the pages you need when you need them.

They have filler data now, because you won't let them touch the real application? Leave it in there until you have real data to replace it with. It isn't hurting anything, and they were probably handing you filler data anyway.

They're using Server-Side-Includes? That's not uncommon - a lot of web designers do this - just look through their HTML and replace it with a user control when you're implementing the that part of the application. Once. You're done. The site works the way it needs to, and the designers still have their own repository using SSI so that they can get their own work done.