The Freelance Client Lifecycle - Part 2

Syntax - Tasty Web Development Treats - Un pódcast de Wes Bos & Scott Tolinski - Full Stack JavaScript Web Developers

Categorías:

Tecnología

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

Sanity.io - Sponsor

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

Freshbooks - Sponsor

Get a 30 day free trial of Freshbooks at freshbooks.com/syntax and put SYNTAX in the “How did you hear about us?” 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’t show client too early—they can be distracted by little unfinished things
  • Back up the “whys” of what you did. Otherwise, it’s 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’s not totally subjective—you have the expertise and you need to flex that.
    • This button is teal because it’s your call to action—this is the button that makes you money so we want to highlight that
    • Grey text on white background is hard to read—you’ll 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’t get offended by feedback on creative work
    • Clients didn’t go to art school and don’t know about good feedback.
    • Clients will ignore all finished aspects of a design and only focus on the one minor thing that’s 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’t 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’t forget. Stick to your timeline!
  • Clients don’t care about technical jargon.
    • Don’t 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’re moving servers, best to just point the A records at the new server.
  • If changing nameservers for DNS, make sure the client doesn’t 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’ll need to be aware of any redirects.
  • Backup strategies
  • Restoration strategies

40:05 - Handoff

  • Create a video detailing how to do each thing
  • Don’t 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’t paying.
  • When to fire your client.

Links

××× SIIIIICK ××× PIIIICKS ×××

Shameless Plugs

Tweet us your tasty treats!

Visit the podcast's native language site