Playing: 114: The Freelance Client Lifecycle - Part 2
Potluck - Deploying Applications × Typescript × Live Coding with Twitch × Fullstack Architecture × More!
Potluck - What is "State"? × Web Sockets × Remote Working × Firefox × Machines Taking Our Jobs × More!
Potluck - CSS × Angular × Dev job preparation × Svelte × File organization × Gear × More!
Potluck - Media Queries × NPM Vulnerabilities × Fullstack JS vs JAMstack × Web VR/AR × Switching Jobs × More!
Potluck - Interview Qs × Headless CMS × React Hooks × Resume Design × Redux vs Context × More!
How We Manage Our Lives — Notion, Todos, Notes, Focusing, Calendars, Goal tracking, and more!
Potluck - Changing careers × Repo organization × CSS Grid × Certifications × Freelancing × Spammers × More
Potluck - Where to start with JS × Freelancing × Cron jobs × Split testing × Frameworks in 2019 × More
Potluck - $100/hr × Redux Replacements × Full Stack Designers × JWT × VS Code Tips × More
Potluck - Editor Fonts × Portfolios × Meetup Tips × Switching to Windows × Freelancing Sources
Potluck EP × Remote Work × Headless WordPress × Good Client Questions × Alternate Careers × React API Credentials
Potluck EP × Is Redux Dead × Learning Quickly × Developing Solo × Specialist vs Generalist × Funnest Projects × Wes’ BBQ Course
Potluck EP × Vue.js × Headless WP × Typescript & Flow × Productivity × Server Side Rendering × Yeoman
Wes and Scott's Lives - Breakdancing, BBQ, Wives, Work/Life Balance, Problem Solving, YouTube Subscriptions
Snack Pack — CSS Frameworks, React HOC, Render Props, Coding Designers, Early Career Advice and a sound board!
Hosting & Servers — Heroku, Now, Galaxy, Digital Ocean, Linode, Docker, Netlify and more!
Jan 30th, 2019
The Freelance Client Lifecycle - Part 2👇 Download Show✏️ Edit Show Notes
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.
1:47 - Design
- Collect all assets from your client
- 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.
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.