You are here:
  1. Home
  2. Blog
  3. Work
  4. What's your process?

What’s your process?

 |  Work

One of the things I am really keen on doing this year is to improve my workflow / development process. I have a very “make it up as I go along” approach to building a website (as demonstrated by my live dev ;)) which I think is fine for personal projects sometimes, but when you’re developing for clients the lack of planning and due process can cause massive headaches. What did the client want on page X, can anyone find the todo list I wrote for page Y, etc. I also find that because I only dabble with version control, there are problems with versions and multiple contributors overwriting things etc.

I have it in my head that I need to do something like this:

  • Plan out requirements with client
  • Set out clear sitemap including what is required from multi-step pages (like basket->checkout->success/fail) … wireframes?
  • Set up project version control
  • Actually commit (pun!) to using version control
  • Make website
  • Have a proper testing/staging process
  • Do proper tests
  • Go live!
  • Post-project review

But what I really need is peer feedback – because otherwise I’m going to to end up making this up as I go along too – there’s no point jumping from a lack of process to a made up process that doesn’t work. So what’s your “process”?

Jem Turner jem@jemjabella.co.uk +44(0)7521056376

7 comments so far

  1. Louise said:

    You know I don’t do much development work – but I’m more than familiar with the processes that come before and after:)
    At requirements stage, I think it helps to have a documented requirement – so this could be made up of some wireframes (to bash out the design/layout) some use cases (for maybe your most complex processes – you may find with time that some of these can be reused) and some simple statements of what is actually needed. I find it helpful to keep this process non-technical because it then frees you up to decide on the best solution.
    Agree these with the client and put them under version control.
    You might also find it a good idea to decide on a release schedule – are you going to release the whole thing in one go? Or are you going to get some bits done before others?
    As for testing, in an ideal world you’d have some test plans :) Automate if you can – makes it much easier when you need to re-run. Get the client involved and ask them to do some testing before you go live.
    And version control as you go – each time you put something into test, version it. If you find bugs, log them and assign them to that version. That way, if you find something has gone wrong – or broken something else, you can go and unpick it.
    With all this – I think so long as you know and understand the principles and why you’re doing them, you can then to some extent pick and choose what you think is appropriate to each project :)

  2. Darren Beale said:

    -Rough estimate based on rough requirements.

    -[client didn’t run away?]

    -Billable requirements gathering workshop / proof of concept / code review (if existing site), / specification phase

    1) Website – just build it

    2) Web app: project divided into chunks with accurate-ish cost estimate per chunk (agile-light)

    -Dev locally in a Vagrant controlled VM per project, sometimes multiple VMs

    -At the end of development (or sprint) deploy to test server for client signoff

    -Snagging

    -Production deployment

    -Bugfixing

    -Retainer/maintenance tweaks or continue with v1.1 dev if multi-phase project

    —-

    Version control is a no-brainer, first thing to set up at start of project.

    each work unit done in own branch and merged into dev-master, the bleeding edge release shared with the rest of the team if working with others. If unit tests all pass this is merged into test branch for, erm, testing and after client functional testing (with most likely some bug fixing first) this is merged into master for live deployments.

    As the other comment states it depends on the project. If it’s low budget you might cut some corners. I’d be strict on version control and having test server for signoff, though

  3. Vera said:

    I find that it’s always very useful to have a written spec document. Preferably not the first draft, coming from the client, but one in a more readable form, where both of you chip in… well assuming of course your client is not and IT person.

    After that, split work into smaller chunks (say 1 man day work hours), and add estimated and priorities for them.

    Implement chunk, test chunk, give chunk over to tester to play with.

    Go on to other chunk and repeat above.

    Alternately, get first chunk back and fix issues.

    And finally, deploy to production, where things are also tested. Gotta love those production-only bugs. :P

    • Vera said:

      P.S. oh yes, and version control can be a life saver. I’ve worked with SVN and Git, but prefer Git. Especially since code-review via SVN is so weird (i.e. done after commit and merge).

  4. Avik @ A2Z Solutions said:

    Wireframing the process is the most important thing. But there are other steps that I follow. Proper client interaction is the most important of all the steps. If I don’t understand even the simplest things, I ask it repeatedly until and unless I understand the requirement. I think there’s no harm in asking rather than delivering something that the client didn’t ask for. Once the work is done, I do a Beta testing and show the mock up to the client. In most cases they get approved on the first go. However, some clients need subtle changes. In those cases, I do that and again show them. Once they approve them, I make the project live. This process not only helps me in optimizing time but also work in a structured process.

  5. Georgie said:

    I only started using version control recently, which was pretty idiotic of me. I did use it at work, but not for personal projects.

    I used to work quite closely with clients at the company I used to work for, and I hated it. A lot. We had a strict paper wireframe to digital slash interactive wireframe to maybe a PSD to maybe developing the thing live. I hated it, because clients always wanted to change something. Always.

    In my masters degree we started an “Agile” approach (think there are other names for it now), because one of the other mature-age students had a lot of experience with it and was very keen on it. Initially I hated it, because I was like “where are the bleedin’ wireframes?” but the whole idea of just getting something done and out there, receiving feedback, and working on it again even if it was “half-done” actually helped things get done a lot quicker. I could see the benefit when it came to the public and to the users in general.

    I started using that method when I did commissions, and it helped – I would just pull something up that I thought was decent, told the client which bits to ignore and that weren’t done, and to provide commentary. It was in such contrast to a project I did years ago where a bright and happy-looking modern website ended up looking like a plain-coloured thing with just a header image. :|

    Where I work now, I am just building the one big website and constantly working on it, so thankfully I don’t have to deal with clients. Hahahaha.

  6. Avik @ A2Z Solutions said:

    I think one of the most important steps is the review process by the client. That is the first time you show the work to the client in beta version. In this first step there might need certain tweaks to match the perfect needs of the client. Though these tweaks generally don’t go beyond one or even two mock ups, some clients are finicky and may ask for more versions of work, which can be annoying at times. Therefore, at the very onset of the work flow, make a deal with the client that the tweaks will be done twice at most in the mock up and not more than that.

Follow on Instagram