So you’re designing a new website or online store, and you need a web developer. You might need them to develop a site from scratch. Or maybe you just need them to work through some tweaks, changes, issues, or extra functionality.
Either way, your relationship with your web developer can be difficult to manage. I’m a developer, so I know that there are so, so many ways the relationship can fall apart:
Practically every designer I work with has shared a horror story involving one of those things. In order to avoid becoming a horror story myself, I’ve developed a handy list of pre-kickoff discussion items to help us avoid these kinds of issues.
Before we get into it, let’s be clear: This is not a cure-all for all designer/developer relationships. At the end of the day, it’s still a human relationship—it’s complicated. But I’ve found that an open conversation about these items can start a project off on the right foot.
Table of Contents
1. How Will We Communicate?
How will you communicate while working on the project? Slack? Phone calls? Texts? Emails? PM software? Just as importantly: How often will you communicate? Every day? Once a week? At kickoff, and then not again until QA? If you’re doing a daily check-in, will it be a two-sentence email, or a 15-minute phone call? What’s the plan in case of emergencies?
More communication does not always equal better communication
There are no wrong answers here, as long as you set expectations at beginning. But remember: More communication does not always equal better communication.
Why This Matters
You want to have a good rapport with your developer, and to accomplish that, you need an established mode of communication. Usually a phone call is helpful to develop an initial personal connection, and to make sure it’s a good personality fit.
During development, work to strike a balance between checking in too much and too little. Too much and you’re micro-managing. Too little and the developer might not stay on track. It’s best to set the expectations at the top and stick to them.
2. How Will You Manage the Project?
Where are the files and login credentials the developer will need? Where will you track tasks, milestones, and deadlines? What software will you use? Basecamp? Trello? Asana? A spreadsheet or Google Doc? Basically, define the central hub for everything related to the project.
Why This Matters
During the project, your project management and communication should be centralized and trackable. A lot of time can be lost in the back-and-forth of looking for files, check-ins, updates, progress, questions, decisions, etc. That’s why it’s important to establish where the developer can find everything they need.
3. Who’s Calling the Shots?
Are you the final decision maker on the project? Is there a UI/UX team involved? Is there anyone else who has input on decisions? Is there a marketing team or a manager who wants to weigh in on decisions? Is anyone else other than you going to be giving direction directly to the developer? When does the client come in, and how many decisions does the client get to make? Will the client have direct communication with the developer?
Why This Matters
You don’t want to backpedal on development, or have your developer redo work. To avoid that, it’s important that every stakeholder is aware of all relevant decisions—and that each decision is recorded in a single, central location.
4. How Should the Developer Handle Assumptions and Small Decisions?
How much freedom does the developer have while interpreting designs? Should they build the website pixel-perfect according to the designs, or should they make small assumptions around consistency and reusability of sections? If you’ve designed a responsive site, have you designed for all breakpoints? Have you provided notes regarding animations, transitions, and hover effects? Have you designed validation states for fields? (i.e. the popups: “Password invalid.” or “Username doesn’t exist”.) If you haven’t, is the developer free to make decisions or suggestions?
Why This Matters
Very often, designers are dissatisfied when a website doesn’t closely match the designs—or conversely, when the site too closely follows the designs, to the detriment of its performance or the project’s timeline. At the beginning, define your intended level of detail. It makes for a much smoother QA process.
5. What is the timeline?
What’s the hard deadline for the project, and what’s the soft deadline? Is there a major press hit happening that the site needs to be launched for? If the deadline is ambitious, is there a way to launch it in phases? What’s the expectation for responding to quick changes? One week turnaround? Less than an hour?
Why This Matters
it really doesn’t help to create artificial hard deadlines…honesty is the best policy
If there’s a hard deadline, make the developer aware of it, and make sure to leave time for proper testing. After the site launches, know that most developers can’t be on call at all hours to make changes. Waiting for a developer to make a fix can be frustrating, but even small requests require maintaining version control, launching the development environment, connecting to the server, deploying to the production site, etc. Determine ahead of time how long you expect fixes and changes to take, and take stock of the priority level of each task.
Also, it really doesn’t help to create artificial hard deadlines. Just be transparent with your developer and trust them to deliver accordingly. Again, you’re building a relationship, here. Honesty is the best policy.
6. What’s the Structure of the Scope, Contract, and Payment Structure?
What’s the project fee? What’s the benchmark for the end of the project? What is included in the scope of the project? When does payment go out? Are you hiring the developer to do the project at an hourly or fixed rate?
Why This Matters
The last thing you want is a developer getting a site 95% of the way there, and then not launching the project due to a discrepancy in the scope/contract/payment.
Overall, setting expectations and communication are the critical things here. It can feel a bit silly to discuss how you’re going to talk to each other during a project, especially if you already have a good rapport. But it’s always good to just set expectations ahead of time, so you don’t end up inside your own a horror story.
Featured image via Unsplash
This content was originally published here.