Giving and receiving feedback
Similar to the last lesson, let’s have a broad stroke look at some principles on giving and receiving feedback. As we get into the course, we are going to look at in-context project examples in more detail. It’s still important to codify some principles for you to refer back to.
As we discussed earlier on in the course, core skills like communication are crucial in writing better HTML, CSS and JS. You might be thinking “how though?!”, which to be fair, is understandable. Allow me to change your perspective. By nailing communication you will by proxy, simplify and sanitise design work. This results in simpler code, which is what we should always be aiming for.
Simpler code is easier to maintain and harder to break. It’s more likely it will handle the plethora of conditions that can break it too, such as overloaded content, dodgy connections and oddly configured and clashing browser extensions. What we want to be avoiding is, writing code that you come back to it in the future and ask, “what the hell is going on here?”. It’s communication, review, quality of feedback and planning that will get you to that almost utopian point.
Giving feedbackpermalink
Related to our principles of not presuming knowledge in the previous lesson, when providing feedback to a designer or other stakeholder like a project manager, you need to explain in detail what the issue is.
Let’s take a look at this example. There’s a hero unit at the top of a page here with one of those autoplaying slider/carousels. In the real world, these are still extremely common and are often implemented to squeeze as much content as possible on to a home page. It’s a tired design pattern, but feeding that back alone is not going to cut it.
An example of a negative interaction
- Me
We shouldn’t use a slider on the homepage because it’s such a tired, old design pattern.
- Designer
It’s what the client wants and they have signed it off so there’s not much I can do.
That got us absolutely nowhere, did it? All we have achieved is getting the designer’s back up. Any chance of making positive adjustments is now likely gone forever, and you, my friend, are now building a user experience — an overwhelm and potential accessibility nightmare. Sure you can keep prodding like the above, but it won’t change anything.
Here’s how I’d approach it:
An example of a positive interaction
- Me
Hey! The designs are looking really great. There’s one section that I’m quite concerned about and would like to understand your decision more.
With the home page hero slider, I’ve got concerns about potential accessibility problems, overwhelm and user experience.
This is a useful quick read on the subject to give you more context about my concerns.
- Designer
Ah, got you. So to give you context, this section was a nightmare to get over the line because different stakeholders all thought their departments were equally as important as each other.
- Me
I get that and really feel for you having to navigate that situation. Considering their departments are all so important, they’ve not produced much content for them have they?
- Designer
Not at all. I’m going to have to produce a background for each one too, which isn’t ideal.
- Me
A problem there is we might not achieve the right levels of colour contrast with the text on each slide. Especially as this is CMS content. It might be right when we hand over, but that could change really quick!
Maybe we should get some data to support our concerns. It’ll be worth looking at what the average session time is on their current home page because we’re going to have to wait at least a few seconds before the next slide changes right? We could argue that a user will likely never get beyond the first slide.
- Designer
That’s a good shout. The problem is they still want an “impactful hero” and to promote each department equally. I’ll get some data for us to look at. I’ll have a think about other design ideas too in the interim.
The proof is in the pudding. Because we approached this situation descriptively and productively, there’s now a chance we’re going to be able to get a better pattern in place.
Let me give you a bit of insight as to how things can go in a client project: clients can be really difficult and set on a certain path. As designers on a tight deadline, admittedly, we sometimes choose the path of least resistance. When there’s a tight window to get designs signed off in a more traditional design process, you have got to take a loss sometimes to make progress.
What a designer doesn’t need at this point is hostility but instead ammo to go back with. Developers are in a strong position to provide that ammo because they’ve usually got a broader understanding of problems that can arise.
Remember, you are a team unit, not competing individuals.
Receiving feedbackpermalink
Ok, let’s imagine for a moment that a new design approach arrived to replace the slider (hooray). The designer came up with a new pattern that had an eye-catching hero unit with a nice big title, followed by a four column grid — one column for each department. Each column has a title, subtitle and a short paragraph of content.
On smaller screens this grid remains, but it’s an overflow pattern that allows the user to scroll. This shows only a part of the next item, indicating there’s more content.
You’ve gone ahead and built it and it’s looking great. The first item should change for each visitor — essentially randomising the content — so each department gets “priority”, but you’ve not implemented that.
An example of a negative interaction
- Designer
Hey, the new homepage section looks really great but the first grid item is the same on each page when I look at it, even after refreshes. The client really wanted those to change on each page load.
- Me
I can’t do that because they’ll all shift around. Large manipulations of the DOM aren’t good either.
This is a straight-up useless response. What is the designer expected to do with that? In these situations, it’s all about landing on a solution that pleases everyone. Try this for size instead:
An example of a positive interaction
- Designer
Hey, the new homepage section looks really great but the first grid item is the same on each page when I look at it, even after refreshes. The client really wanted those to change on each page load.
- Me
Thanks! Yeh I struggled to get this working well because I’d have to rearrange the content with client-side JavaScript. The problem with that is there’s a good chance JavaScript will fail and/or not be available. It’s why I got the overflow scrolling setup working with CSS only.
If JavaScript does work, manipulating the DOM like that can be quite clunky — especially on low powered devices.
- Designer
Got it. The reason they wanted to randomise the order of the content is similar to why they wanted a slider in the first place. They’re adamant that each department is as important as each other and they don’t want one department being prioritised over the other. It’s really frustrating because they won’t move on that.
- Me
Sounds very frustrating to me. The content comes from a CMS but the site is built with a static site generator. This means it’s built once, then a static HTML page is served to the user.
What if they changed the order of the content in the CMS quite regularly which would trigger a rebuild of the static site?
- Designer
It’s a good idea, but I know they won’t want to do that. They’re really quite lazy as well as demanding 😅
- Me
Ok, how about this: we set the site to rebuild every hour with automation and when it does rebuild, it randomises the order of the content each time?
- Designer
Now that’s a good idea! No client leg work required and they get what they want in essence. Let me run it past them!
See how much more productive that is? Not only have we avoided implementing a slider in the hero unit, but we’ve also avoided writing some nasty JavaScript that will almost certainly fail too.
I know each project has different tech stacks and challenges — you don’t want to see what I’ve seen in over 15 years of client services work — but the point I’m making is, that collaborating rather than battling will likely get you a happy medium that’s importantly, simple.
Trust me, designers want the best for users as much as you do, so help them achieve that rather than being prickly!
Wrapping uppermalink
Right, we’re going to cover all of the above in the context of our project. I just wanted to get you in the right frame of mind to start with and show you in a small use-case, the benefits of giving and receiving feedback productively.