New Website Development Process

So, I’ve been thinking a lot lately about the web design process we use where I work. That process is pretty linear and straight forward:

  • Wire frames are created
  • A Photoshop comp is created
  • The Photoshop comp is approved
  • The site is coded
  • The site is approved
  • Site goes live

It’s all straight forward and easy to follow, but lately I’ve been thinking it’s not the greatest approach because it has several weaknesses. The biggest is that there is a disconnect between UI design and the final product (it’s hard to see interaction in a Photoshop comp).

I’ve been thinking about a new web development process, which goes something like this:

  • Wire frames are created
  • Wire frames are approved
  • Wire frames loosely mocked up in HTML/CSS/Javascript
  • Mocked up site is taken into Photoshop (a page at a time) and a comp is created.
  • The comp is then interpreted and mocked up (much more loosely then the previous process)
  • Mocking up and comping repeated in a cycle until complete
  • Site appearance is approved
  • Any back-end stuff is implemented
  • Site is approved
  • Site goes live

Of course that’s a pretty general description, but I think the approach lets us do several things better:

  • We can prototype and tweak UI/UX while the site is being built (instead of “fixing” UI/UX problems at the end).
  • We can use web font services and see how they look better than we could trying to fake it (since 99% of those you can’t get on your computer, at least without great cost).
  • We can do general web design practices better (like implementing “Responsive Web Design” easier and seeing the “high cost” of certain graphical things and decided that we don’t really need them).

Any ideas or comments that might help our approach be better? What is your general approach?

Thanks.

I would agree. The whole “design it in Photoshop and then make it work in code” approach is fraught with problems, in my opinion. PS mockups lend themselves to coding and accessibility issues later down the line, especially in situations where designers consider PS to be where the work really takes place, and the code is just gruntwork performed by the equivalent of fry-vat workers. (Not saying that’s what goes on at your place.) Of course, you know that SP is largely populated by code-first, design-in-the-browser types (including myself!), so the responses you get are going to be slanted in that direction.

I actually really like the idea that you are presenting, because sometimes someone might do a design in Photoshop, which is a completely different tool than CSS/HTML. You have no restrictions in Photoshop that you do with the actual construct that makes up a site. So, doing the wireframes beforehand allows you to tweak the issues before anyone outside the team sees the Photoshop exports. That would make transferring a design from Photoshop to CSS a snap.

One roadblock is if you have someone who is doing the approval who can’t wrap their heads around a wireframe. Alot of corporate types are like that. They need to see a design before approving it. True story, a print designer on my team was asked to mock up a flyer in Latin text, so that THEN the actual content could be provided. He wanted to see the design before giving the content, nevermind that the content informs the design, not the other way around. The final design was completely different once the content was in.

That’s the kind of thing you have to deal with sometimes. Wireframes can look abstract and technical. I submitted wireframes for approval to my creative director. Even he (who is primarily from the print school) found it difficult to wrap his head around them. It looks like a design that has been under designed, and no matter how much you explain it, they may need to see the Photoshop design before they approve. It just depends on who you are working with.

The question is not about beginning with the PSD, it is the client mentality. If what the client want is a look MATCHED… even if you do the wire frame first you will find yourself with the same issues. When I start ( or middle) with a PSD I think how I am going to code something… I anticipate what can be done and what “effects” will just be a pain with no gain.

If your work place has stopped requiring the AD/GD to create a “look to match” and instead realizing that the aesthetic goal should be to provide a general look and feel , then that’s the real victory.

Yeah, one of the problems with designing in PSD is that you are designing in set size. So you may get this beautiful design, but once you expand the browser, it’s just a design within in a centered square, rather than giving at least some impression that the site lives in the entire browser. So that’s the same technique I use, I may design something, but always thinking how it will be done in development.

I think I have convinced “management” (I use that term loosely, since they’re much closer to normal colleagues) that as long as we get close to the look and feel, we’re good. We are already pretty far from the mark anyways (for example, our designer usually uses Myriad Pro, but we build the site with Arial).

Luckily these are also business sites for our own company, no clients involved.

My goal is that we’ll still maintain a pretty high level of control over the design, while being able to do it quicker (once we adapt to the new process) and end up with a better functioning product.

What is this Photoshop thing of which you speak?

There’s no way I would be happy working on a project where the Photoshop pretty picture came before the code. As you say, you often lose the instinctive interactivity and flexibility that you build in when creating a website rather than translating a design into HTML. I see those as two completely distinct processes.

The site should inform the design, not the other way round. Decide what you want the site to do, get a rough feel for the look of it (you’ll almost certainly have some images in your head … keep them there where they’re flexible and can adapt to the emerging creation), then build the bones of the site. Keep in mind how you want it to work, how you want it to react, how you want it to interact. You’ve got outline blocks, the viewer changes the window size, what happens? Do the blocks take up the slack proportionally, is one a fixed size with the other filling the remainder, do blocks need to shuffle round and stack vertically? Only once you’ve figured all that out should you enter the graphics stage – then you’re creating graphics that meet the requirements of the site, not trying to shoe-horn the site to fit in with the pre-made graphics.

I plan on tattooing that on my forehead. In a very small font, of course. :slight_smile:

I generally tend to create interactive wireframes first, where most of the functions actually work (with dummy data, no database connection etc.). Once those are approved - which usually takes quite a long time - we sit down with the designer, tell him/ her what the site does, how it works (using the wireframes as reference) and then let them work their magic.

Generally, if the designer has the wireframes as a guide, they’ll design according to those meaning the actual building of the site doesn’t get bogged down with continually having to get new designs made.

Longest time I’ve spent for a project making wireframes? About 1.5 months. That’s a lot of time, and if you tell a client that they’ll probably run away frothing at the mouth. However, this was for a very very complicated piece of planning software, and the client realized that. Once the wireframes and design were done, actual development was a breeze :slight_smile:

I look forward to seeing the photos :smiley:

I’m just a newbie to using code to develop sites… spent years with canned progies including DW… but getting a little better after acquiring various SitePoint books… up until now though I’ve always laid sites out on paper… using too much pencil lead and significantly more eraser!.. until reading this thread… makes all sorts of sense to me!

went on a search for html5 and wireframes and its lead me to some interesting sites including the FlairBuilder one… has anyone used this to help lay out their wireframes?.. as a newbie I think something like this will be invaluable to get me going… sans lead and eraser!

As someone that has tried a bunch of project management models in my business, I love your new approach, great stuff!

You are doing the right thing by moving away from your current “waterfall” web production model, into this new one. This will definitely work a lot better for you. If you search for “waterfall”, you’ll find a lot of information, cons and pros about it, and the vast majority is against it these days.

The only thing I’m personally missing is iterations—making it an “agile” approach. If you don’t know much about Agile yet, Google it and read up a bit. By incorporating a little bit of Agile into your new approach, I think it’ll be even better. Easier to estimate, handles changes better, improves communication.

Agile—remember it. The [URL=“http://agilemanifesto.org/”]manifesto says it all (and the [URL=“http://agilemanifesto.org/principles.html”]Twelve Principles says a whole lot too).

Feel free to PM for more information, book recommendations, questions, advise, whatever. :slight_smile:

Good luck with this new stuff, you’ll do great work based off of it!

I’ve heard of the Agile project management process. But the only thing I have been able to find is how it relates to software development, rather than the web design development. What would the Agile process look like on a web design/development team? I have always been told that any kind of design starts as a process of gathering information, then research, then developing a strategy, then beginning the information design process, which sounds like the linear, downward flowing waterfall approach, yet I cannot imagine starting a design without first having the research I need solidly in place, and a strategy informed by the research.

The Agile approach seems to say to do a little of all of them bit by bit and then falling back to do them again (iterations?). I don’t know if I am misunderstanding, but not sure still how the agile flow works specifically with the graphic design and web dev (ie not the software development) workflow.

Do you have any other insights?

I also was wondering whether or not the Agile approach is the reason I notice that software seems to be released with alot of bugs, and then you have to keep waiting for the circle back updates. Is that something that the Agile adherants are ok with? Because when I get a new Adobe point zero product, it’s frustrating how buggy it is at first.

I disagree with that. The things you mention are generally those that are addressed by the mock-ups them self. If they are not then it is the developers responsibility to make adjustments or sacrifices as necessary to achieve usability and other technical goals. I rather have a designer create a mock-up for me… at least that gives me a place to start. Granted, the mark-up is independent of the design, but still the visual sets a much needed pathway for everything else. It also depends on the type of site your working on though. When working on an administrative interface I write all the mark-up and programming first. However, when it comes to a CMS where the client will fill in information the design generally does come before everything else as there is already an integrated work flow within the system itself that is not worth changing. Though you say the site should inform the design really how many different patterns are there… only a hand full. When you start changing them around generally that incurs some type of decrease in useability. For every site, well every average site I would say there are several things that use the same patterns, for useability and limitations with technology. Again, though it comes down to complexity of what is being built. Not to mention the act itself of separating content between different pages, tabs, ect is in fact a design decision itself that has a significant affect on how easily a communication will be conceived by an end user.

Are you using a cms (home grown or open source). It sounds like it from that work flow. When not working with a cms all the programming becomes before the design to achieve a base line. Then once the application is stable design and useability concerns are addressed and the software is modified. At least that is generally how I work when dealing to custom software, not open source cms’s.

Mocking up and doing development iteratively is always the greatest way to work. It was the greatest way to work 10 yrs back and will continue to the best method to work in future. Mockups help set initial expectations and manage client expectations properly. Iterative develop is must for closely achieving the client needs.

The primary question is NOT whether iterative/agile development work,
Its - who is gonna pay for the extra iterations and process

Most Business clients will roll back at the first hint of extra cost, that too in the present economic crisis situation. If the businesses can afford it. Web developers can always bring out the best process and standards of doing the work.

I lost track of this thread. Thanks for all the feedback everyone.

We are actually expanding our regular development department as well (by expanding, I mean getting a second and third in-house person ;)). I’ve been planning on using an Agile process with our regular software development, and I’m sure some of the lighter stuff will slip into the web development process as well. =p

We are using a CMS (heavily modified Wordpress), which is part of our workflow. Our main site is essentially just reskinning the content each time. We do have other sites, but those are mostly internal so the front-ends are developed largely by myself with usability in mind (then prettied up a bit near the end of development).

samanime interesting approach.

For the project we’re working right now (it’s a community based site) we followed (till now-the project is still under heavy development) this process:

Prelimenary meeting with the client - 1st meeting
-goals and objectives
-Discussed what the site would offer to the visitor in terms of functionality
-Discussed about the desired look and feel, psycoloical responses the site would evoke - sites that like and dislike and why

In the meanwhile: Client was asked to gather and organise their content (mostly articles). The client hired copywriters.

2nd meeting with the client
-Modules required in base of functionality
-First thoughts and proposals about the functionality - modules proposed
-Wireframing (with pencil and paper) and information architecture
-1st photoshop mockup
-User testing and interaction with the client (no code yet) - the testing was made based on the mockups

Design approved

in the meanwhile while we were waiting for the client’s response and approval of the design:
-Research about the CMS that we were going to use based on the functionality required (custom or ready made? Open source or not? how easy would be to add custom functionality and templating/theming of our design? Would we need to learn new skills and how long would that take us? How easy it would be to find professional or community to help us out on that field?)
-Research conclutions. Drupal the most likely candidate.

From the first “iteration” or interaction we had these conclutions:
-Information architecture needed further refinenment
-More functionality had to be added (custom module that needed heavy planning, development, prototyping etc)
-New requirement that the site had to be accessible and easy to use even on mobile (the first mockup was designed with a 960px static layout, 12 column grid)

New iteration (3rd and 4rth meetings):
-Got the content that the client had so far
-New information architecure (approved)
-Wireframes that we made in the first iteration - showed the most likely candidates with the new requirements in mind (approved)
-New design to meet the new specifications and accomdate extra modules (photoshop mockups - approved)
-Coding the site (static)
-User testing of the static site with the participation -again- of the client, testing on multiple devices (smart phones - i-pad - desktop - resolutions and window sizes)

Static site approved - Facebook and Twitter pages designed (graphics, colors, custom tabs etc based on the initial concept) - Approved

1st milestone (36 days after the first meeting)

  • Static site gone live (mostly articles - e-books and resources) with the content that the client had provided thus far, about page, contact form etc (architecture used was that of the first iteration)
    -Facebook and twitter pages gone life

Thus far:
-we had a happy client that was motivated to participate and provide early content
-the client was participating in the design process and the development actively
-the client could use social media to promote the site and get insight,
-start builidng user base and anticipation about the the upcoming community
-SEO research could start and continue (based on the traffic statistics etc) while the site was being developed
-The client could continue producing content based on that insigh
-We looked good!

-In the meantime:
-Built a system on Drupal with the basic features discussed in the first meeting
-proposed extra functionality and incopporated in the system (we actually found a ready module that did what we wanted with only slight modifications on the output of th information and easy templating)
(in other words we built the 1st functional prototype)

New iteration:
-The client was introduced to the prototype and reviewed the functionility (front-end with the default theme of drupal - the client already knew where everything would be from the refined mockup we provided earlier in the process so we didn’t have a problem)
-The client was introduced to the administration section of the system
-User testing (considerations likehow easy was to add articles? How easy was for the content editors to interact with the system? Add categories and organise the content? etc) and training

Functionality approved - Drupal for the CMS approved

Thus far:
-the new content could be uploaded and managed through the CMS
-the client could interact with an actual system and get a feel of the functionality so we can start user testing
-content editors could start actually working with the system and provide insite about it

New iteration (where we’re at now)

  • Custom theme (based on the HTML/CSS provided earlier in the process)
    -Extra CSS and HTML based on the modules output - modifications and additions (code wise)
    -Proposal and analysis of the extra module required (the module actually will go though feasibility test before even starting prototyping - with the feedback of the community - so this will be an new project and contract )

we have: estimation of 2-3 weeks till completion of the new iteration - the the dynamic site will go life with the basic functionality implemented (forums, user profiles, blogs, articles etc)

What do you think of this approach?