Professionalism is key in the Freelance world, and I think one of the key aspects of it is a transparent communication between customer and consultant. A clear and phased workflow can help with this, so I'd like to share my usual process of development.

It includes 4 main stages: Planning, Design, Construction and Launch. Of course, not all the projects (almost no one indeed) will involve every step, and sometimes your help is only necessary for one of them, like the launch or building phases.

I started using a simple Web Project Briefing document as a guideline to those "Discovery Meetings" where consultant and client gather together to talk about the goals of the project. This document turns out to be really important, and I remember finishing one of those meetings with the feeling that although it will be really hard to get the job, at least I have helped the customer business to focus on their goals and kind of improve their chance of survival.

Another large improvement was to make use of the task list templates that some project management services provide. Specifically, I use RedBooth's (formerly Teambox) task lists templates to jump-start on any project and help me estimate as well how long could it take me to finish it. Another handy document is a spreadsheet that I use to fill with my original estimations for every project and the time it actually took to ship it.

Planning/Discovery

This stage is about getting all the info about the needs of your client and identify the main areas where you can add more value or where you can't even help. Some clients could think you are wasting their time, but if you have been into Software development long enough (or read Code Complete), you know you are actually saving their time and money. Most information for this phase will be gathered on the Discovery meeting, or kickoff meeting. There is so much information involved within the document I usually use that I could write a whole post about it, but these are the main points:

• Requirements analysis
  • Background (Company, Goals, Mission, Budget)
  • Audience (Target, Use Cases)
  • Research competitor's sections and features
  • Competitors
  • Sitemap and Information Architecture
  • SEO goals and measurement of success
• Technical analysis
  • Technological stack decision
  • Decide deployment platform
  • Servers access

Desired outcome:

• Functional Specifications (if possible)
• Content: Pictures and Copy
• Logos/Brand Images

Design

I will usually call one of my designer friends for this area. I know great designers that ship fast and quality work which I can team up with and build outstanding products. The process goes like this:

• Wireframing and design elements planning
• Mock-ups based on requirements analysis
• Review and approval cycle with the client

Outcomes of this phase:

• Mockups (2 or 3 versions)
• Sliced Assets
• Social media assets
• Typography and Color Palette

The responsive web has brought some added complexity on this process, as it usually involves additional circles of reviews by client and designers. There are great articles and talks out there about the non-validity of this waterfall process with Responsive sites, but for small projects I don't really see other valid options.

Construction

Here starts the real work for me, it will follow this steps:

• Setup Development Environment
  • Build Process Setup
  • Test Server Setup
  • Deployment Scripts
• Slice and code valid XHTML/CSS
  • Get Assets
  • Analyze modules
  • Responsive Breakpoints
• Build development framework
  • App Core
  • Common extensions
• Code behavior for each page/section
  • Develop and test special features and interactivity
  • Build modules
• Fill with content
  • Test and verify links and functionality
  • Get Proof Reading
• SEO and Microdata Iteration
  • Metatags
  • Microdata
  • Accesibility
• Web analytics Setup
  • Security Review
  • Google Analytics
  • Google Webmaster Tools
• Cross-browsing tests (IE, Modern Browsers, Android, iPhone, iPad)
• Bug Fixing

A funny thing is how early on this phase I tend to set up the build and deployment process. There are little things more frustrating than not been able of shipping of time due to deployment problems, the solution: deploy first, build later.

Launch

This is one of the sweetest moments for sure! It is also the moment to prove that the performance optimizations introduced on the building phase are working.

• Deployment
• Post-Launch Checklists
• Polishing
• Performance measurement
• Manual Acceptance Testing

Conclusion

Keeping your process clear to your clients improves your communication, making it more effective (less misunderstandings) and transparent (no surprises). I think the process showed above can be useful as a base for your next project.

How about you? Do you think your process as a freelance is better? As a business owner, do you think it lacks something?

Photo credit: jcolman cc