Podcasts Technology Syntax - Tasty Web Development Treats The Freelance Client Lifecycle - Part 2

The Freelance Client Lifecycle - Part 2

Published: Jan. 30, 2019, 2 p.m.

In this episode Scott and Wes continue their discussion about the freelance client lifecycle\u2014from design and development, to project hand-off, and everything in between.

Sanity.io\xa0- Sponsor

Sanity.io\xa0is a real-time headless CMS with a fully customizable Content Studio built in React. Get up and running by typing\xa0npm i -g @sanity/cli && sanity init\xa0in your command line. Get an awesome supercharged free developer plan on\xa0sanity.io/syntax.

Freshbooks - Sponsor

Get a 30 day free trial of Freshbooks at\xa0freshbooks.com/syntax\xa0and put\xa0SYNTAX\xa0in the \u201cHow did you hear about us?\u201d section.

Show Notes

1:47 - Design

  • Collect all assets from your client
    • Logo
    • Brand guidelines
    • List of likes and dislikes
  • Create initial look and feel
  • Don\u2019t show client too early\u2014they can be distracted by little unfinished things
  • Back up the \u201cwhys\u201d of what you did. Otherwise, it\u2019s just a pretty picture and and the client only thinks about it in terms of taste. Remember, you are the expert they hired, so it\u2019s not totally subjective\u2014you have the expertise and you need to flex that.
    • This button is teal because it\u2019s your call to action\u2014this is the button that makes you money so we want to highlight that
    • Grey text on white background is hard to read\u2014you\u2019ll be leaving people out if you do this.
    • When possible, draw circles or golden ratio lines around everything ;)
  • Be prepared for non-standard feedback
    • E.g. this feels cloudy, can it look more sunny? Please make it pop, etc.
  • Don\u2019t get offended by feedback on creative work
    • Clients didn\u2019t go to art school and don\u2019t know about good feedback.
    • Clients will ignore all finished aspects of a design and only focus on the one minor thing that\u2019s incorrect.
  • Revisions

17:58 - Development

  • Clear requirements make development much easier.
  • Sometimes this starts at the same time or in the process of design.
  • Only show dev progress if client is capable of understanding dev process.
    • Showing a developed site too early can cause clients to worry about visual aspects that aren\u2019t yet in line with the design.
    • Showing to early is also a recipe for a feedback list of things you already know.
  • Give regular progress updates, as previously established. Make it happen on a schedule so expectations are set and so you won\u2019t forget. Stick to your timeline!
  • Clients don\u2019t care about technical jargon.
    • Don\u2019t tell clients about Gatsby/React as much as telling them about the benefits, how fast the site is, etc.

23:48 - Feedback and revisions

  • Feedback is done in revisions or rounds.
  • For smaller projects, have your client email (one email) a list of feedback.
  • For larger projects, and more technical clients, use bug tracking software, such as Github issues, Trello, etc.
  • Write down everything, and then have a follow-up call to discuss the feedback.

30:08 - Deployment

  • Get your client to pay for domains and hosting.
  • Make sure their old website has everything off of it, or host the website somewhere else.
  • If you\u2019re moving servers, best to just point the A records at the new server.
  • If changing nameservers for DNS, make sure the client doesn\u2019t have email or any other apps on that server that will be nuked or broken when moving.
  • Many clients use their server to uploaded PDFs and other files that may still need to be accessible.
  • If you are changing URL structure, you\u2019ll need to be aware of any redirects.
  • Backup strategies
  • Restoration strategies

40:05 - Handoff

  • Create a video detailing how to do each thing
  • Don\u2019t give more options than they need in the back end.
  • Do in-person training when possible.
    • Only teach them the things that are important for their day to day usage.

44:28 - Bug fixes and support

  • Very common for clients with wrong idea of project guidelines to want to add on at the end of a project.
  • Not about adding new, non-established features.
  • Emergency bugs require an emergency response if they are your fault
    • Set expectations and be careful what you promise.

48:03 - What to do when things go to shit

  • There should be a trail of communication leading up to things going awry.
  • Project is behind.
  • Product is not met with acceptance.
  • Client isn\u2019t paying.
  • When to fire your client.
Links \xd7\xd7\xd7 SIIIIICK \xd7\xd7\xd7 PIIIICKS \xd7\xd7\xd7 Shameless Plugs Tweet us your tasty treats!