The Missing Brief Checklist: How NOT to Ask Your Web Developer for Help
There is a magical sentence that can strike fear into the heart of even the most experienced web developer:
“Hey, the website is doing something weird. Can you fix it?”
No screenshot. No URL. No description of what happened. No indication of what device is involved. No browser information. No explanation of what they clicked. Just:
“It looks weird.”
Congratulations. You have successfully submitted the least useful support ticket in human history. If you’re running a business, your website is one of your most important pieces of marketing infrastructure. Whether you’re investing in personal website design, business website design, or a completely custom website, problems will occasionally happen. That’s normal. What isn’t helpful is expecting your web developer to diagnose the problem through psychic abilities.
That’s why we’re introducing:
The Missing Brief Checklist
A simple guide to communicating with your web developer without making them guess what happened. And because we’re here to help, we’re going to examine some of the greatest examples of completely useless website support requests.
Request #1: “It Looks Weird on My Cousin’s iPad”
Ah yes, the classic.
“It looks weird on my cousin’s iPad. Please fix.”
Excellent. Thank you. This tells your developer approximately nothing.
Which iPad?
Which model?
Which version of iPadOS?
Which browser?
Which page?
What looks weird?
Is the text too large?
Is the menu missing?
Is something overlapping?
Is the page blank?
Did your cousin accidentally activate some accessibility setting?
Is the iPad upside down?
Your developer now has to investigate approximately 9,000 possibilities.
What the Developer Actually Needs
Give them:
- The URL of the page
- The iPad model, if known
- The browser being used
- A screenshot
- What the page should look like
- What it actually looks like
Even better:
“On the Contact page, the navigation menu overlaps the logo when viewed in Safari on an iPad Air. Here’s a screenshot.”
Now we’re talking. That is an actual bug report. The first version was a cry for help.The second version is information.
Request #2: “The Website Is Down”
This one is terrifying.
“THE WEBSITE IS DOWN!!!”
Okay, let’s remain calm. The developer opens the website. It works. They open it on their phone. It works. They open it on another computer. It works.
They ask:
“What are you seeing?”
You respond:
“It doesn’t work.”
Wonderful.
What Does “Down” Mean?
Does it mean:
- The website won’t load?
- You’re getting a 404 error?
- You’re getting a 500 error?
- A page is missing?
- A form isn’t working?
- The site is extremely slow?
- You’re seeing a security warning?
- Your browser is displaying a cached version?
- Your internet connection is down?
“It’s down” is not a diagnosis. It’s a symptom.
Better:
“When I visit the homepage, I get a 500 Internal Server Error. It started around 2:15 PM. I’m using Chrome on Windows 11.”
Now the developer has somewhere to start.
Request #3: “The Button Doesn’t Work”
Which button? There may be 37 buttons. You have just asked the developer to play:
Where’s Waldo: Web Development Edition.
Give Them:
The page: Contact Us
The button: Submit
Expected behavior: Send the contact form
Actual behavior: Nothing happens
Device: Windows laptop
Browser: Chrome
When it started: This morning
That is useful. The developer can now investigate the form, JavaScript, browser console, plugin conflicts, server-side processing, or whatever else might be causing the problem. Without that information, they’re guessing.
Request #4: “It Was Working Yesterday”
This sentence is actually somewhat useful.
Unfortunately, it’s usually followed by:
“I don’t know what changed.”
That is where things get interesting. If something worked yesterday and doesn’t work today, something probably changed.
Maybe:
- A plugin updated
- WordPress updated
- A theme changed
- Content was edited
- A third-party service changed
- A browser updated
- A server configuration changed
- Someone installed something
- Someone deleted something
- Someone “just clicked around”
That last one deserves its own investigation.
If You Changed Something, SAY SO.
Your developer isn’t a detective. If you installed a plugin 15 minutes before the website broke, that’s relevant information. You aren’t going to get in trouble. Well…Probably. Just tell them.
Request #5: “Can You Make It Look Like This?”
Then you send a screenshot. Not a website. Not a design file. Not an explanation. A screenshot. It’s a picture of another company’s website. “Make ours look like this.” The developer stares at it. There are 14 different components visible.Animated graphics. Custom typography. Interactive navigation. A video background. Three different calls to action. A custom illustration. A shopping cart. A review system. And an entire development team apparently living inside the footer.
Your budget:
$800.
This is where expectations and reality meet.
What Helps
If you like another website, tell the developer what you like about it.
For example:
“I like the clean navigation, large hero image, simple typography, and way the services are organized.”
That gives a developer usable design direction.
That’s how good Business Website Design begins.
Not:
“Make it like Apple.”
Request #6: “SEO Isn’t Working”
This is another masterpiece.
“SEO isn’t working. Can you fix it?”
Excellent.
Define “working.”
Are you:
- Not appearing in Google?
- Ranking lower than expected?
- Not getting traffic?
- Not getting leads?
- Seeing an indexing problem?
- Targeting the wrong keywords?
- Missing metadata?
- Having technical SEO problems?
- Expecting to rank #1 immediately?
SEO is not a light switch. You don’t turn it on and wait for customers to appear. A useful SEO support request might look like:
“Our service page isn’t appearing in Google for our target phrase after several weeks. Can you check whether the page is indexed and whether there are technical SEO issues?”
Now the developer—or SEO professional—has a real question to investigate.
Request #7: “It’s Slow”
This one sounds simple. It’s not. Slow where? On which page? On what device? Using which connection? In which browser? Is the entire site slow or just one page? Is the initial load slow? Or does an interactive element take too long? Your developer needs evidence.
Useful Information Includes:
- Page URL
- Device
- Browser
- Approximate load time
- Screenshot or screen recording
- Whether it happens consistently
- Whether it happens on Wi-Fi and cellular
- Whether other people experience it
Even better:
“The homepage takes approximately 9 seconds to become usable on my iPhone over cellular, but loads much faster on desktop.”
Now we’re investigating a performance problem instead of chasing a ghost.
Request #8: “My Customer Says It Doesn’t Work”
This is one of the most frustrating phrases in web development.
Because now there are three people involved:
- You
- Your customer
- Your developer
And information is being transmitted through the world’s least reliable telephone game.
Customer:
“The form doesn’t work.”
You:
“My customer says the form doesn’t work.”
Developer:
“Which form?”
You:
“The form.”
Developer:
“What happens?”
You:
“They said it doesn’t work.”
At this point, the developer is considering becoming a beekeeper.
Get the Actual Information
Ask your customer:
- What page were you on?
- What did you click?
- What happened?
- What did you expect to happen?
- What device were you using?
- What browser?
- Can you provide a screenshot?
- Can you reproduce it?
Then send that information to your developer. Congratulations, you have become a functional middleman.
Request #9: “Can You Fix the Website?”
Technically, yes, but this is like calling a mechanic and saying:
“Can you fix the car?”
The answer is obviously yes.
The question is:
What’s wrong with it?
A professional Website Design company needs enough information to determine whether you’re dealing with:
- A design problem
- A technical problem
- A content problem
- A hosting problem
- A plugin problem
- A browser problem
- A user error
- A third-party service problem
- Or something else entirely
The more specific you are, the faster the problem can usually be isolated.
The Screenshot: Your Developer’s Best Friend
If you can provide a screenshot, do it… seriously.
A screenshot can immediately reveal:
- Error messages
- Broken layouts
- Missing images
- Overlapping elements
- Incorrect spacing
- Browser warnings
- Plugin conflicts
- Unexpected content
And if the problem involves something moving or changing?
Use a screen recording.
Don’t write:
“The menu does a weird thing.”
Record the weird thing.
Your developer will love you.
The URL: The Most Important Three Letters
If you are reporting a website problem, send the URL.
Not:
“It’s on the services page.”
Send:
The actual URL.
Websites can have:
- Multiple service pages
- Landing pages
- Hidden pages
- Duplicate pages
- Different templates
- Different versions
Your developer shouldn’t have to navigate a maze to find the problem.
Device Information Matters
“I’m on my phone” isn’t enough. There are thousands of phones.
Try to provide:
Device: iPhone 15
Operating system: iOS 18
Browser: Safari
Or:
Device: Windows laptop
Operating system: Windows 11
Browser: Chrome
This can make troubleshooting dramatically easier.
A website can behave differently depending on the browser, operating system, screen dimensions, and other environmental factors.
Browser Information Matters Too
Your developer may ask:
“Which browser?”
Don’t answer:
“The normal one.”
There is no normal one.
There is:
- Chrome
- Safari
- Firefox
- Edge
- Samsung Internet
- Opera
- Brave
- And approximately 400 browsers you’ve never heard of
If you’re not sure, tell them what device you’re using and they can help you determine it.
Tell Them What You Expected
This is incredibly useful.
Don’t just say:
“The button is broken.”
Say:
“When I click the Request a Quote button, I expect it to open the contact form, but nothing happens.”
Now the developer knows the intended behavior. That’s critical.
A developer can’t always tell whether something is actually broken or simply behaving differently than you expected.
Tell Them When It Started
Was it:
- Today?
- Yesterday?
- After an update?
- After you changed something?
- After a new plugin was installed?
- After your website was redesigned?
- After your hosting company migrated the server?
Timing provides clues. If the website worked perfectly until five minutes after you installed a new plugin, that’s useful information. Very useful. Possibly extremely useful. Please tell your developer.
The Perfect Website Support Request
If you want to make your web developer’s day, send something like this:
Problem:
The contact form isn’t submitting.
Page:
Device:
iPhone 15
Browser:
Safari
What I expected:
Clicking “Send Message” should submit the form and display a confirmation.
What actually happens:
The button changes color, but nothing else happens.
When it started:
This afternoon.
Recent changes:
We installed a new review plugin this morning.
Screenshot:
Attached.
Now THAT is a support request.
Your developer might actually smile.
The Missing Brief Checklist
Before sending your developer a message that begins with:
“Hey, something weird is happening…”
Run through this checklist.
1. What page?
Send the URL.
2. What happened?
Describe the problem.
3. What should happen?
Explain the expected behavior.
4. What actually happens?
Describe the result.
5. What device?
Phone, tablet, desktop, etc.
6. What browser?
Chrome, Safari, Firefox, Edge, etc.
7. When did it start?
Give an approximate time or date.
8. What changed?
Mention updates, plugins, edits, redesigns, or anything else relevant.
9. Can you reproduce it?
Does it happen every time?
10. Do you have evidence?
Screenshot, video, error message, or screen recording.
That’s it.
You don’t need to understand JavaScript.
You don’t need to understand CSS.
You don’t need to understand databases.
You don’t need to know what an API is.
You just need to provide enough information for someone who does understand those things to investigate the problem.
How Minnesota Website Wants You to Call for Help
At Minnesota Website, the goal isn’t to make clients become amateur web developers. You hired a professional Minnesota Website development company because you shouldn’t have to understand the technical architecture behind your website. But communication works both ways. The developer understands websites. You understand your business. You know what your customers are trying to do. You know what you changed. You know what you expected to happen. That information is incredibly valuable. A successful Business Website Design project isn’t just about code and pretty graphics. It’s about communication between the business owner and the people building the website. The same applies to Custom Websites. The more clearly you can explain a problem, the easier it is for the developer to diagnose it and determine the appropriate solution.
Stop Saying “It Looks Weird”
We aren’t saying you need to become a developer. We’re simply asking you to upgrade your vocabulary slightly.
Instead of:
“It looks weird.”
Try:
“The headline overlaps the image on the mobile version of the homepage.”
Instead of:
“The website is broken.”
Try:
“The homepage displays a 500 error when I visit it in Chrome.”
Instead of:
“The button doesn’t work.”
Try:
“The Submit button on the Contact page doesn’t submit the form when clicked.”
Instead of:
“It doesn’t work on my cousin’s iPad.”
Try:
“The navigation menu overlaps the logo on an iPad Air using Safari.”
See the difference? You’re not expected to diagnose the problem. You’re just expected to describe the crime scene. Your developer will investigate from there.
Final Rule: Don’t Be Afraid to Say “I Don’t Know”
This might actually be the most important rule. If you don’t know what browser you’re using, say:
“I’m not sure.”
If you don’t know when the problem started, say:
“I noticed it today.”
If you don’t know what changed, say:
“I don’t think anything changed.”
That’s perfectly fine. The developer can ask for additional information. What isn’t helpful is inventing technical explanations. Please don’t tell your developer:
“I think the CSS database is fighting the server because the JavaScript isn’t communicating with the HTML.”
They will know you watched a YouTube video. Just say:
“The menu isn’t working.”
We’ll take it from there.
The Bottom Line
A good web developer doesn’t expect you to know how to fix your website. That’s what you’re paying them for. But they do need enough information to know where to look.So the next time you need help with your website, remember:
URL.
Device.
Browser.
Problem.
Expected behavior.
Actual behavior.
When it started.
What changed.
Screenshot.
Those nine things can turn:
“It looks weird. Please fix.”
into an actual, solvable technical problem.
And if you need help with Website Design, Business Website Design, or a Custom Website, Minnesota Website can help you build and maintain a website without requiring you to learn CSS, JavaScript, HTML, PHP, APIs, databases, or whatever terrifying acronym the internet invents next. Just remember:
Your web developer can fix almost anything.
They just need to know what “anything” is.