Wes Bos & Scott Tolinski - Full Stack JavaScript Web Developers

Zpravodajství

Technologické zprávy

Technika

The Freelance Client Lifecycle - Part 2

Syntax - Tasty Web Development Treats

Full Stack Developers Wes Bos and Scott Tolinski dive deep into web development topics, explaining how they work and talking about their own experiences. They cover from JavaScript frameworks like React, to the latest advancements in CSS to simplifying web tooling.

<p>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.</p> <h2><a id="Sanityio__Sponsor_9" name= "Sanityio__Sponsor_9"></a><a href= "http://sanity.io/">Sanity.io</a> - Sponsor</h2> <p><a href="http://sanity.io/">Sanity.io</a> is a real-time headless CMS with a fully customizable Content Studio built in React. Get up and running by typing <code>npm i -g @sanity/cli && sanity init</code> in your command line. Get an awesome supercharged free developer plan on <a href= "https://sanity.io/syntax?utm_source=syntax-fm&utm_campaign=syntax1">sanity.io/syntax</a>.</p> <h2><a id="Freshbooks__Sponsor_13" name= "Freshbooks__Sponsor_13"></a>Freshbooks - Sponsor</h2> <p>Get a 30 day free trial of Freshbooks at <a href= "https://freshbooks.com/syntax">freshbooks.com/syntax</a> and put <strong>SYNTAX</strong> in the “How did you hear about us?” section.</p> <h2><a id="Show_Notes_17" name="Show_Notes_17"></a>Show Notes</h2> <p>1:47 - Design</p> <ul> <li>Collect all assets from your client <ul> <li>Logo</li> <li>Brand guidelines</li> <li>List of likes and dislikes</li> </ul> </li> <li>Create initial look and feel</li> <li>Don’t show client too early—they can be distracted by little unfinished things</li> <li>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. <ul> <li>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</li> <li>Grey text on white background is hard to read—you’ll be leaving people out if you do this.</li> <li>When possible, draw circles or golden ratio lines around everything ;)</li> </ul> </li> <li>Be prepared for non-standard feedback <ul> <li>E.g. this feels cloudy, can it look more sunny? Please make it pop, etc.</li> </ul> </li> <li>Don’t get offended by feedback on creative work <ul> <li>Clients didn’t go to art school and don’t know about good feedback.</li> <li>Clients will ignore all finished aspects of a design and only focus on the one minor thing that’s incorrect.</li> </ul> </li> <li>Revisions</li> </ul> <p>17:58 - Development</p> <ul> <li>Clear requirements make development much easier.</li> <li>Sometimes this starts at the same time or in the process of design.</li> <li>Only show dev progress if client is capable of understanding dev process. <ul> <li>Showing a developed site too early can cause clients to worry about visual aspects that aren’t yet in line with the design.</li> <li>Showing to early is also a recipe for a feedback list of things you already know.</li> </ul> </li> <li>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!</li> <li>Clients don’t care about technical jargon. <ul> <li>Don’t tell clients about Gatsby/React as much as telling them about the benefits, how fast the site is, etc.</li> </ul> </li> </ul> <p>23:48 - Feedback and revisions</p> <ul> <li>Feedback is done in revisions or rounds.</li> <li>For smaller projects, have your client email (one email) a list of feedback.</li> <li>For larger projects, and more technical clients, use bug tracking software, such as Github issues, Trello, etc.</li> <li>Write down everything, and then have a follow-up call to discuss the feedback.</li> </ul> <p>30:08 - Deployment</p> <ul> <li>Get your client to pay for domains and hosting.</li> <li>Make sure their old website has everything off of it, or host the website somewhere else.</li> <li>If you’re moving servers, best to just point the A records at the new server.</li> <li>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.</li> <li>Many clients use their server to uploaded PDFs and other files that may still need to be accessible.</li> <li>If you are changing URL structure, you’ll need to be aware of any redirects.</li> <li>Backup strategies</li> <li>Restoration strategies</li> </ul> <p>40:05 - Handoff</p> <ul> <li>Create a video detailing how to do each thing</li> <li>Don’t give more options than they need in the back end.</li> <li>Do in-person training when possible. <ul> <li>Only teach them the things that are important for their day to day usage.</li> </ul> </li> </ul> <p>44:28 - Bug fixes and support</p> <ul> <li>Very common for clients with wrong idea of project guidelines to want to add on at the end of a project.</li> <li>Not about adding new, non-established features.</li> <li>Emergency bugs require an emergency response if they are your fault <ul> <li>Set expectations and be careful what you promise.</li> </ul> </li> </ul> <p>48:03 - What to do when things go to shit</p> <ul> <li>There should be a trail of communication leading up to things going awry.</li> <li>Project is behind.</li> <li>Product is not met with acceptance.</li> <li>Client isn’t paying.</li> <li>When to fire your client.</li> </ul> <h2><a id="Links_89" name="Links_89"></a>Links</h2> <ul> <li><a href= "https://syntax.fm/show/112/the-freelance-client-lifecycle-part-1">Syntax 112: The Freelance Client Lifecycle - Part 1</a></li> <li><a href= "https://syntax.fm/show/088/pre-launch-checklist">Syntax 088: Pre-launch Checklist</a></li> </ul> <h2><a id="_SIIIIICK__PIIIICKS__93" name= "_SIIIIICK__PIIIICKS__93"></a>××× SIIIIICK ××× PIIIICKS ×××</h2> <ul> <li>Scott: <a href="https://amzn.to/2M94YIq">Synology 4 bay NAS DiskStation DS918+</a></li> <li>Wes: <a href= "https://www.backblaze.com/">Backblaze</a></li> </ul> <h2><a id="Shameless_Plugs_98" name= "Shameless_Plugs_98"></a>Shameless Plugs</h2> <ul> <li><a href="https://leveluptutorials.com/pro">Scott’s Level Up Pro</a></li> <li><a href="https://www.advancedreact.com/">Wes’ Advanced React Course</a></li> </ul> <h2><a id="Tweet_us_your_tasty_treats_103" name= "Tweet_us_your_tasty_treats_103"></a>Tweet us your tasty treats!</h2> <ul> <li><a href="https://www.instagram.com/stolinski/">Scott’s Instagram</a></li> <li><a href= "https://www.instagram.com/LevelUpTutorials/">LevelUpTutorials Instagram</a></li> <li><a href="https://www.instagram.com/wesbos/">Wes’ Instagram</a></li> <li><a href="https://twitter.com/wesbos">Wes’ Twitter</a></li> <li><a href="https://www.facebook.com/wesbos.developer">Wes’ Facebook</a></li> <li><a href="https://twitter.com/stolinski">Scott’s Twitter</a></li> <li>Make sure to include <a href= "https://twitter.com/SyntaxFM">@SyntaxFM</a> in your tweets</li> </ul>

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 Syntax 112: The Freelance Client Lifecycle - Part 1
 Syntax 088: Pre-launch Checklist
 ××× SIIIIICK ××× PIIIICKS ××× Scott: Synology 4 bay NAS DiskStation DS918+

 Wes: Backblaze

 Shameless Plugs Scott’s Level Up Pro
 Wes’ Advanced React Course
 Tweet us your tasty treats! Scott’s Instagram
 LevelUpTutorials Instagram
 Wes’ Instagram
 Wes’ Twitter
 Wes’ Facebook
 Scott’s Twitter
 Make sure to include @SyntaxFM in your tweets

Aplikace Youradio Talk

The Freelance Client Lifecycle - Part 2

Poslechněte si podcast