Custom WordPress web development is one of the things we do here at Full Stacks.

It’s fun, challenging, and sometimes makes you want to pull your hair out when you’re doing QA for the sixth day in a row and can no longer remember why you decided to try a new category filtering system on this project, with this budget, with this timeline, in this lunar cycle. With Jupiter in the seventh house? What were we thinking?!

You know how it goes, everything’s simple in the beginning when we dream big with our client about the best solution for their site. But a week from launch, with the bug fixes piling up and the client finding issues every other minute on the live site, we’re ready to change professions to something where we never have to touch a computer again (do those even truly exist anymore?).

If you work in an agency, this might sound familiar. Scarily familiar, maybe?

We (and our clients!) ended a lot of our web projects in the same way: tired. A more complex web design project might end up taking eight months or more. That’s a long time to keep momentum up, spirits high, and scope in check.

After some soul searching, much brainstorming, and from some help from our friends at the digital project management consultancy, Louder Than Ten, we realized that we were approaching projects the wrong way. And chances are, you might be too.

What is Waterfall web design and development?

Waterfall is a project management methodology where project activities happen in discrete, linear steps. One step is done, reviewed, then the next step begins. In web design and development, it describes a process of phases that might go something like this:

• Determining the direction of the site through a discovery/strategy phase. This involves uncovering the problem that needs to be solved by a new website, researching the audience, auditing existing content, doing keyword research, and more.
• Creating a sitemap, content structure, and functionality list. This is where the findings of discovery turn into a concrete plan for what content will be on each page of the site, how those pages interconnect, and what special features the site needs.
• Turning that plan into wireframes. Wireframes are black and white “blueprints” of the visual layout of the site to confirm hierarchy. Often these are built in a tool like Invision, which allows for low-fi prototyping.
• Turning the wireframes into high-fidelity design mockups. This is where colours are applied and everything looks like how the site really will once it’s finished.
• Passing those mockups off to a developer. They then go away and turn them into a website (MAGICALLY, in the opinion of the non-devs on our team), connected to a WordPress content management system (CMS).
• Doing quality assurance on the site after it’s been developed, uncovering bugs and then fixing them.
• Training the client on using the CMS and handing it off to them to do content entry.
• Launching the site once content entry and bug fixes are complete.

Waterfall is how Full Stacks used to and — we’d hazard a guess — many agencies still run their web design projects. (For clarification, we’re talking websites here, not apps/software.)

There are reasons why Waterfall has been the predominant form:

• It’s a straightforward and easy process to explain to clients
• There are less meetings and feedback loops required, so it feels like it’s saving time
• Scheduling is straightforward, because a developer doesn’t need to touch the project until the designs are all finished and approved
• Other methodologies require a project manager or team lead who can be very involved in running the project
• It’s how print projects usually work. Make your layout, send it off to be created. It feels comfortable because it’s how things have “always been done.”

The biggest issues with Waterfall web design & development

While running our projects in Waterfall didn’t always go poorly for us, we found we were consistently hitting the same issues over and over.

If you work at an agency, do any of these sound familiar?

If a client isn’t happy with the design direction, all page designs need to be changed

If you present a full design, with all of the pages in a certain aesthetic direction, a client might come back with feedback that affects every single page. That means your designer is going to have to redo work that’s already done… a good recipe for going over budget and sailing past your deadlines.

The budget gets gobbled up by earlier phases, and there’s no time or leeway to change the plan

When you’re working in Waterfall, every phase needs to be completed before you move on to the next. That means that if you go over budget in one phase, you’ll need to pare back in the next phase. But if all of your designs have been approved, you can’t really ask the client at that point if you can go back to the drawing board and cut some features. Well, you can, but it’s a tough conversation that often doesn’t go well.

Developers aren’t involved in the project until it’s too late for their input

In the traditional Waterfall approach, a developer might be involved in quoting, or a designer might ask their opinion when they’re designing the UI for a feature. Or they might quickly review the designs before they go out to a client. But on the whole, they aren’t really brought into the fold until the site designs are done and they’re supposed to start developing the site.

The issue with that? Only they really know how complex a template will be to code. Only they know that that slick hover state we imagined will actually take twelve hours to get right, not two. These are the types of issues that only really get caught when a developer is engaged with a project and has the time to start planning their build early.

Problems don’t always present themselves until they’re coded

That banner looks awesome in the mockup, but now that we see it resized on an iPhone, it looks totally off. Crap. Now what?

Sure, we might have been able to anticipate this issue, but some things aren’t obvious until they’re coded. When a whole site is coded at once, you don’t catch these issues until the end of the project, when you’re running low or out of budget, can’t go back to the client with a change, and just need to get the damn thing finished.

Clients might not recognize an issue until they see it on a live site

If we can’t anticipate every potential issue with a design, how can we expect our clients to be able to? We have clients sign off on a full site design with the hope that they really understand how things will work when that flat mockup becomes a functioning website. But unless they’re also web designers, that’s a tall order. When we don’t let the client see and use the site until the day before we’re aiming to launch, it’s no wonder we’re left with a huge list of requests from the client since “this doesn’t work how I thought it would.”

We lose momentum and the client isn’t engaged

Projects tend to drag for lots of reasons. Sometimes you haven’t prepared a client for how much time they’ll need to spend gathering feedback, writing content, or arranging interviews with their stakeholders. Or sometimes things just aren’t coming together smoothly with the site plan or design. It happens. But by the time we get into development and then pre-launch QA, we’ve lost all the excitement that our project started with.

In the beginning, there are concrete things to see and fun decisions to make. During development, there’s a whole lot of waiting and slogging through for both our team and the client’s.

The client just has to wait, anxiously hoping that we’ve been able to translate their needs into a useful product and that we’re going to meet the timeline their boss is demanding. It’s tough and tiring.

QA is long and exhausting

If you’ve ever done QA on a website, you know it takes a lot of time. There are a few people who genuinely enjoy this work, but it’s truthfully not a task that most of us want to do for days on end. It’s a lot of clicking, screenshotting, and writing, “this is what should have happened but this is what happened instead.” When you have an entire site to QA at once, it can feel like an unclimbable mountain.

So yeah, Waterfall sucks. But what do we do instead?

We had heard a lot about Agile project management, but had our doubts. At a very high level, Agile is a framework for managing projects that involves regular iterative phases (called “sprints”) and teams from different disciplines working closely together. When it comes to web development, the idea is to build prototypes of features early so they can be tested with real users.

Agile (and its specific methodologies, Kanban/Scrum), is often used for software development, and it’s a complex framework that we truthfully haven’t fully gotten into.

But that’s okay, because as website designers and developers who aren’t building apps, we don’t really need to be fully agile. Instead, we can be Agile-ish.

How we experimented with some Agile principles in our web design and development process

We started by thinking through our main process pain points:

• Dev wasn’t involved until it was too late
• Client feedback caused design work to be redone
• Issues were introduced in dev that then spread out to all pages
• The end of the project is tiring and frustrating for us and our clients

Then, we thought about how we could fix those problems.

Get dev involved as early as possible, without bogging them down too much in the discovery process or bloating our budgets

We didn’t want our devs sitting in every client meeting — that would be a waste of time and budget. Instead, we started to think about when their feedback and input would be the most helpful, and how early we could get them started building the site we were planning.

We realized that we could start planning the admin of the website (how the client would be able to update their content, what those content fields would need to be, how many templates there would be, what types of components might be on the site) way earlier than we had been. By the time we had an approved content plan (which we build out in Gather Content), we could really start mapping out these fields.

That turned into a spreadsheet that the project strategist and developer would work on together.

After wireframes were completed and approved by the client, the strategist and developer could run through the spreadsheet and make any adjustments that came from client feedback or the designer’s ideas. Then, the developer could get started on setting up the admin of the website: setting up the server, building the page templates, setting up Advanced Custom Fields.

This allowed that foundational work to be finished early and reviewed, so we would be ahead of the game when answering questions like, “how is the client supposed to edit this content? Which parts? To what level?”

In Waterfall, those questions would be answered as we were trying to get front-end development done, and there often just wasn’t time to get it right.

Break up design into rounds

This was such a simple solution it feels silly to even present it here. Don’t design all at once. Once we realized we could present design in rounds, we could then start developing in rounds, and QAing in rounds. We hesitated calling them “sprints” for a long time because it felt too official and Scrum-my but that’s really what they are.

Our clients now see a homepage design first, which presents the overall aesthetic of the design, the navigation, header and footer. It’s a good place to start because often changes here would end up affecting the rest of the pages.

Then, we present two or three more pages in another round, then three or four more in a final round. Each round, we tend to get less feedback on the aesthetics, because we’ve already worked through any issues that the client had earlier on.

Use sprints for dev, too!

In Waterfall, a simple bug that could be fixed easily if it was found early tends to proliferate throughout the entire site. An easy fix cascades into a big, time-intensive one to tackle at the end of a project.

Breaking up design into rounds gave us the freedom to explore developing in sprints. Instead of a traditional sprint where you might only work on one feature to completion, we instead decided to do this by pages.

Our developers now take a finished homepage design and develop it completely. It’s then passed to our QA team for review, and then the client can review it. Since the backend is done and set up, we can actually get the client in there so they can practice editing and adding content.

Working like this helps us catch issues super early in the process before they get duplicated across all of the templates on the site.

It also allows the client to provide their feedback and thoughts early, at a point where we can make real decisions about how to proceed. That might mean increasing scope, or reducing the complexity of another page.

Keep momentum going with regular “wins”

One of the major problems with Waterfall is that development and QA feels like spending a million dollars to ship your child off to a training academy, spending three years waiting and expecting them to become a world-class athlete, and then ending up with a bronze medal win. They’re still an Olympian, sure, but they still have work to do and the whole thing feels like a bit of a letdown. You weren’t there to see how hard they worked and the amazing strides they made along the way, so the reveal is kinda anticlimactic.

For both us and our client, there were very few visible wins during the development process before we changed our process. We tried to high five our developers when they finished a milestone on their end, but often no one else could see it because they were developing locally.

By working in sprints, we regularly have real, live, finished pages to review!

This keeps the momentum going because we’re seeing the fruits of our labour come to life quickly, we’re problem solving together, we’re not panicking about budget or timeline, and the client can actually see that we’re doing what we’ve said we’re doing. And there’s a lot of trust that comes from that kind of visibility.

Final thoughts

We’re super happy with how our new agile-ish process is going. We’re still learning, adjusting, and getting better. We’re figuring out how to manage scope and budgets more effectively (more on that another day).

When we asked our team how they felt about our new process, a metaphor quickly materialized because we’ve got a prolific knitter on our team… and we love metaphors.

Developing a website is like knitting a sweater.

In Waterfall, a developer has been given a pattern for a sweater and told, “Knit this as fast as you can with whatever bits of yarn you have hanging around ‘cause we don’t have much time or money left. But it needs to look exactly like this pattern okay?”

So the developer rushes through the sweater, not realizing that there are a bunch of holes and stitching errors in it the entire time. Then she hands it off to be reviewed in QA, and everyone says, “Um, hi? Look at this mess! This is the wrong colour, and you did a cable knit here when I meant it should be a lattice.” And the developer then has to go back and painstakingly pick through her stitches to fix them, but they can never be as perfect as they could have been if they were done right from the beginning. Oh, and it takes longer than it would have taken if it hadn’t been rushed.

In our new Agile-ish approach, the developer helps build the pattern, understanding how the sweater should look and feel. She starts by knitting a small test swatch and asks everyone, “Is this what we were all imagining?” If she needs to make changes, it’s easy. She’s got the time and budget to use the right materials and isn’t stressed, so her knitting comes out much nicer. There are still mistakes, but we catch them before they take over the whole sweater.

What a nice little analogy hey? Now go knit a sweater… just don’t do it all at once.

SVG files look sharp at all screen resolutions, have super small file sizes, and can be edited and modified using code. These files are commonly used for website logos to keep the image crisp no matter what device or browser a person is viewing your website on.

What an SVG is & Why You Should be Using it

Scalable Vector Graphics (SVG) are web-friendly vector images. Files in this format use an XML-based text format to describe how the image should appear. Because text is used to describe the graphic, a SVG file can be scaled to different sizes without losing quality, unlike a PNG or JPG file.

With PNG or JPG files you are restricted to pixels. You would use a PNG file when you require transparency in your images. Transparency in an image requires a large file size. The larger the file size, the slower the graphic is to load. When working with JPG files, you have the choice of quality or compression. More compression gives you a smaller file size, but you lose image quality. SVGs files are just code, which means they can have a smaller file size and a quicker load time.

Currently Squarespace only offers the option to add a .png or .jpg logo file. But there is a workaround! Squarespace doesn’t make it easy, but it is possible. Here’s how you can add an SVG logo to the Logo/Title section of your Squarespace site.

How to Add an SVG Logo to Logo/Title Section of Your Squarespace Website

These instructions may vary depending on the template your website is using. For this example we used the Brine template.

1. Add a Transparent PNG File

Hover over the page title you want to add the SVG to and click edit. Add a transparent PNG that is the same size as your .png or .jpg logo file.

2. Upload SVG*

Upload the SVG file using the link editor.

1. On any page, select “edit” and add text to the page. You can remove this text later
2. Highlight the text and select the link icon from the toolbar
3. Click the gear icon in the URL box
4. From the pop-up window, select the “File” tab
5. Click Upload File to select the SVG file from your computer. You can also drag and drop the file into the Upload File area
6. Once the file has uploaded click Save
7. In the link editor copy the URL to the SVG. It will look like this /s/file-name.svg**
8. Click apply

*Looking to turn a JPG or PNG image to an SVG file? Try Adobe Express. 

**In some cases you may need to add the full image URL. It will be much longer and look like this:

https://static1.squarespace.com/static/602d8c67675bb40d4f-1b1fcb/t/602e9574f59fb32c9e67195c/1613665652987/file-name.svg

You can find this URL by clicking on the link created above and copying/pasting the full URL from the browser window. 

Now that the SVG file has been uploaded and the URL has been created the linked text can be removed.

3. Add Custom CSS

Back to the Home Menu, select Design, and then Custom CSS.

Insert the following code:

.Header-branding-logo {
background-repeat: no-repeat;
background-image: url(PASTE IMAGE URL HERE);
}

Note: If you have the logo set to display in the top centre of the screen you may notice the logo appears slightly off-centre. To fix this you can add this line to the code above:

background-position:center;

The class or ID you are using as a selector will vary based on the template you are using. For this example we used the Brine template and the class is Header-branding-logo. You can find the name of your logo’s class or ID by right-clicking on the logo in your template and selecting Inspect Element.

4. Adjust Size

The SVG file may upload at smaller size. You can adjust the width by going back to the Home Menu, select Design, and then Site Styles. Under Header: Branding there is a slider to increase the logo’s width.

5. Add Mobile Logo

On most templates Squarespace uses a different class or ID to display the logo on mobile. What’s frustrating about this is that Squarespace does not give you the option to upload a mobile logo anywhere on the site so there is no real way of knowing this… until you open your website on mobile and realize your SVG logo is not there.

If you are using a different logo for mobile you’ll need to repeat Step 2 to upload this new logo. If you are using the same logo simply add the mobile class or ID to the Custom CSS you created in Step 3. For the Brine template the mobile class is .Mobile-bar-branding-logo.

.Mobile-bar-branding-logo {
background-repeat: no-repeat;
background-image: url(PASTE IMAGE URL HERE);
}

Now your SVG logo will appear in the header of your website! You can rest easy knowing that your logo will look great on any device.

When a client comes to us with very specific goals and also understands the value of planning and research, we will build a website that exceeds those goals.

You can also read our case study about this project.

At our first meeting, Fringe Theatre already knew what they wanted from their new website, and then we had to ensure the redesign would also be all that their audience needed it to be.

Fringe Theatre puts on the largest Fringe Festival in North America, the Edmonton International Fringe Festival, each August and delivers theatre programs and community events year-round as well. Fringe Theatre brings artists and audiences together to celebrate creativity, risk, craft, and community.

It was important to the Fringe Theatre team to:

• Sell more tickets online
• Be able to easily update the website themselves
• Integrate the website properly with their chosen ticketing program
• Fix issues caused by a previous agency’s poorly implemented migration

It was important to us to help the Fringe team:

• Introduce more people to “fringing” (more first-time ticket buyers)
• Add new pages to make first-timers’ experiences more enjoyable
• Connect with people attending the Fringe Festival from outside of the city
• Clarify key messaging to avoid alienating people who weren’t already “fringers”

You’ve hit that point. You keep hearing about how important your web presence is to your brand and your marketing, and you know it’s time to build a website or revamp your current one. But, you feel like it’s hard to get a straight answer about what’s involved.

What does it mean to build a website for your business?

Let’s get the elephant out of the room first. Why not just sign up for a Squarespace or Wix account?

The short answer is that it depends a lot on what you’re looking to get out of your website. If you’re on a tight budget, mostly need a website for the basics (like your contact information and your hours of operation), or aren’t too worried about how distinct your site looks, then a website builder like Squarespace or Wix may truly be be a great option for now.

Buuuut…let’s say it’s time to make your business stand out. Maybe you launched your last website when Netscape was still a thing. Maybe you’re tired of being on the third page of Google search results. Maybe you never quite found the time to build a website at all.

But now you’re ready.

You want your website to demonstrate what sets you apart from your competitors. You want it to say something about your business ethic and your brand. Surely if you build a shiny new website, the business is going to come rolling in.

It’s time to ask your niece to build something for you, right? Or your buddy knows this great freelancer, why not give him a call? They’ll know all about SEO and sitemaps and design and Google Analytics and copy and —

Maybe not.

It’s straight talk time. While it’s true there are some really great people out there doing work for hire, there are a lot of things going on in a well-constructed website, and each of them requires a good deal of time and expertise to master. If you want a website that’s going to look good AND be easy to use AND rank well on search, you’re looking for a unicorn to find one person who is an expert in all of those.

If you’re aiming for a website that’s distinct, professional, easy for both you and your clients to use, flexible across devices, and well-ranked on search engines, this is where a digital agency with a well-rounded team really shines.

So, what should you expect when you sign up for a professionally-built website then? Well, here’s some highlights.

A Needs Analysis

This will figure out what purpose the website is fulfilling for your business and how best to structure it to reach your base. Depending on your situation and need, this could include a website audit (if you have a site already), keyword research, competitor research, and so on.

A Site Map

This details how the new site will be structured. It’s usually a chart showing the top-level (most important and prominent) pages planned, plus all key sub-pages presented where they would appear in the site’s menu.

Wireframes

The wireframes will show how each major page type will appear on the final site, including user experience details like the how the navigation will function. Wireframes determine the UX (user experience) of the website — what the hierarchy of information should be so they can find what they need, where (and what) elements should be included on a page, and what key messages need to be featured.

Visual Design/User Interface Design

This is where the aesthetic elements of the website are created and applied. The skeleton defined by the wireframes is dressed up with brand colours, typefaces, imagery, iconography, and any other assets that are required to define the overall look — and feel — of the website.

Hosting and Domain Registration

If you don’t already have these in place, you’ll be set up with a domain (the address of your website) and hosting (the place where all your site’s files live to produce a functional website).

Content Strategy

This is all the content that will appear on your website, from what to say on your pages or what blogs posts to write, to what kinds of images or videos to put up, to how to say it all in a unified way that best represents your brand.

SEO (Search Engine Optimization)

This is all the little details that affect how search engines read your site and decide where it should appear in their rankings.

The Website Build

This is the ‘code stuff’ where the design is turned into a fully functional, interactive website. Depending on your needs, it can include a custom theme, custom plugins, interactive details, or business-specific functionality (like a shopping cart, live chat, or region targeting). It should always include responsiveness so your site will work well no matter what device or web browser your audience uses to view it.

Content Loading

Once the website is built and you’ve pulled together all your content, then it’s time to combine the two.

A Launch Plan

This is all the things that will make sure everything goes smoothly at launch. If you already have a website, it will include a migration plan to ensure all the links pointing at pages on your old site still work and that you don’t lose any organic search traffic in the changeover.

Performance Metrics

This is where tools like Google Analytics and Google Search Console come in so that you can measure search traffic, collect information about how people are interacting with your site, figure out conversion rates and all that good stuff.

Post-Launch Follow-Up

This takes place in the days and weeks post-launch to ensure your new website is performing as expected.

A Guide to Your Website

Because what good is a shiny new website if you can’t make heads or tails of it?

That’s a lot to keep track of! The good news is, if you hire the right agency, all of this will be documented in a detailed plan, and you’ll have regular check-ins to measure progress. In addition, they will help you identify the appropriate next steps to make sure your business can continue to build on your new digital foundation.

But let’s say you’re still leaning toward a DIY solution or a freelance web developer. These are valid options, though they do come with some risks. If you do choose to go that route, here are some considerations.

Platform

• Is the platform you choose (such as Squarespace or Wix) easy for you to use?
• If you’re going with a freelancer, is their preferred platform (ex: a content management system like WordPress, Drupal, or Joomla) friendly to non-developers?
• Or does the freelancer use a CMS at all (ex: the website can only be updated by accessing the server and site files)?

Ease of Use

• At the end of the process, can you update the website yourself (ex: add pages, update text, post pictures or PDFs)?
• Or has the website been constructed with the assumption that the developer will be on retainer for routine updates?

Migration

• If you’re redeveloping your site, do you know how to set up redirects and prevent dead links so you don’t lose organic search traffic?
• Does the freelancer you’ve chosen?

Content

• Are you, or do you have on staff, a person who is comfortable writing and is knowledgeable about what your base is looking for when they come to you?
• If you’re going with a freelancer, how are their writing skills?
• Are you confident they will ask the right questions about your audience to target them effectively?

Design

• Platforms like Squarespace or Wix use templates, which means websites built with them will all look similar. Is that a drawback for you?
• If you’re going with a freelancer, do they have a diverse design portfolio? Or when you look at their previous clients, do their websites all look alike?

Mobile

• How does the Squarespace or Wix template you’re considering look on a mobile phone or tablet? Is it still easy to use?
• How about the websites in a freelancer’s portfolio?

User Experience (UX)

• Do you know how to make a website easy to use for your clients?
• When you explore websites built by a freelancer, how easy do you find their websites to navigate?
• Do those websites anticipate questions you have about the business and put the answers front and centre?

Metrics

• How do you plan on measuring how successful your website is?
• Are you comfortable setting up tools like Google Analytics or Google Tag Manager so you can collect performance data and adjust accordingly?
• Is the freelancer you choose comfortable with them?
• If someone else is setting up these resources for you, will you own the accounts or will they?
• If you need help interpreting what these tools are telling you, where can you go?

Living in an age where anybody can create a website is great (and let’s be honest, pretty empowering), but if your new website doesn’t create the right experience for your audience, it can be worse than not having a website at all.

Before you start throwing all your time and resources into a website, think about your goals. Equally importantly, think about whether or not you have what you need to create a site that will help you achieve those goals. Websites are one of those things that can be more expensive to fix than they would have been to do right in the first place. Why take that chance? Contact us.

Design freelancers, teams, and agencies love design.

Designers spend years in school being technically trained, countless hours drawing and discovering on their own, and assemble impressive portfolios. Great designers create from the heart (while keeping on point with a project’s strategic direction).

What a design team produces for you is grounded in unique work and education experiences, as well as a commitment to keep up-to-date with best practices. The best designers don’t chase trends just for the sake of being trendy; they thoughtfully evaluate the ebbs and flows of the design industry to ensure that what they develop is purposeful and contemporary.

Remember the following points when reviewing designs, preparing feedback, and discussing concepts and projects with your internal team, freelancers, and design agencies.

Always Remember the End Goal

When you request a change, be sure to address how the change will improve the solution. It’s a good idea to be able to answer this question when preparing feedback:

How will what I am suggesting improve the way our audience interacts with our business?

These conversations uncover how much research your design team or agency did to inform the designs they presented you. For example, when you ask why something looks a certain way, or flows in a specific manner, you want to get more back than a blank stare and a mumbled, “well, just because.”

An agency that explains the functional whys behind their creative choices will produce work that will satisfy your business needs. They discovered how your real customers and clients need a design to look and feel, and then they built that for you.

Constructive feedback is a two-way street. Both you, the client, and the designer — whether they’re an agency team or a freelancer — need to be able to rationalize designs and design changes.

Leave the Scissors in a Drawer

If you see something on one of the design options you’re presented with that you wish to see on another, please discuss this with your designer instead of photoshopping together your own version. Similarly, printing design options and then cutting out an element from one option and gluing it on to another is not productive. Prepare your feedback and discuss with the designer why you think combining elements will better serve your audience.

Feedback that comes as a bulleted list of change requests with no rationale is similar to cutting elements up with a pair of scissors. This method doesn’t adequately address the needs of your audience or explain how they will benefit from any changes.

You Don’t Need to Have the Answers

If you spot a problem/issue/concern, your designer wants to know about it — but they do not expect you to come up with a solution to the problem. Collaborative discussion about concerns is certainly imperative and effective, but after, the designer needs to head back to their office to come up with an adjustment.

Less “We”, More “They”

Simply stating what you don’t like is often not helpful, but explaining where you think your audience might struggle is crucial. Remember, you’re working together with a designer or an agency to achieve your business goals and provide a better experience for your audience. You and the designer need to push personal likes and dislikes off to the side during the project.

Egos need to be shelved because the needs of your audience deserve top priority.

To sum up, it’s just as easy to get caught up in personal preferences as it is to get trapped in a desire to be “hip” and “flashy” (or to just do what your competitors are doing), but you must resist. You took on a design project for a reason: to make finding (and using) your product or service easier and more attractive for your audience.

The way you give design feedback can make your project a success, or it can derail it (and your sanity) completely.

If you enjoyed this post, may we suggest reading You’re My Favorite Client from the A Book Apart series.