Feedback and criticism are critical processes in web design, development and programming. It may seem like this technology is analytical with fairly clear answers to problems, but all of it is a more creative process than it looks.
In a recent episode of their excellent podcast Syntax, Scott Tolinski and Wes Bos discussed some approaches for developers and programmers dealing with criticism and feedback. Given that many developers are introverted and analytical, these soft skills are often confusing, frustrating and hard to parse. Our culture also reinforces the notion that criticism is always negative and should be taken personally. In fact, it’s likely that most friction and fighting in teams, between developers and clients, and so on, can be attributed to participants taking criticism personally.
I’d like to share some observations on this topic. I come at this as a developer with 23 years experience and even more experience in IT and working as a librarian.
How Criticism Should Be Shared (Negative and Positive)
It’s unfortunate that most people conflate criticism with negative feedback. In any kind of creative process, such as web development, design and programming (or the arts), criticism should include positive and negative words. It’s possible that criticism may be mostly negative or mostly positive, but constructive criticism usually involves a range of both.
This is one of the most important things I learned during art school, which I’ve always tried to mindfully apply to web design and development.
For example, let’s say you are looking at a new web design for the first time. It’s going to help the designer(s) and/or developer(s) to hear what you think works and what you think doesn’t work. You should outline the parts that you think work. You may say that the fonts look great. You like the overall color scheme. You like the masthead. On the other hand, you might point out that the masthead should be smaller, or placed differently. You may explain you need the elements on the home page placed differently. The slideshow should be moved down and the intro text featured more prominently.
Don’t Take Criticism Personally
This is probably something many of us techies hear, but practical application of this is harder to manage. When you’ve put hours of work into coding or a website design, it feels like it’s a personal thing. When you receive criticism, especially negative criticism or words that indicate some ignorance by the client, it’s easy to slip into a position of defending your work. But in the end, it’s just work. You are doing the work for somebody else, so the goal is to make them happy or make them feel like your work, or solution, matches their goals and priorities.
One effective psychological concept that helps you not take criticism personally is the idea and practice of detachment. There is a large amount of resources on detachment and how you can implement it mindfully in your work life. In the end, you want to do good work, get paid, and not have to think about work stuff when you aren’t working. Detachment is a great tool for developing healthy work-life balances.
Don’t Assume You Know What Other People Are Thinking, Or Their Motives
Mind reading is a skill that none of us possess. While you can “read” another person to some extent, it’s always smarter to engage the other person(s) in discussion and questions. It’s always possible that somebody may not say everything on their mind. They may be undecided. Have their mind elsewhere, like on a personal crisis. They may withhold feedback, thinking they are sparing your feelings. They may lack confidence in expressing themselves or sharing critical remarks. But if you focus on a smart feedback discussion, you will usually get most of the information that you need.
A quality feedback session doesn’t happen without some planning. While you may be able to wing a casual session with a client or team member who you’ve known for years, it is worth it to plan which topics you want to talk about. Prepare some questions. Make a list of items that you need feedback or criticism about.
They May Be Asking The Wrong Question, or, Are On A Different Page
I bring one method from librarianship to feedback interactions with peers, co-workers, clients, and team members. That’s a method called “the reference interview.” Wikipedia explains it:
A reference interview is a conversation between a librarian and a library user, usually at a reference desk, in which the librarian responds to the user’s initial explanation of his or her information need by first attempting to clarify that need and then by directing the user to appropriate information resources.
The methods are explained:
Parts of a reference interview
The reference interview is structured to help the librarian provide answers to the library user. In general, the interview is composed of the following stages.[3]
- Welcoming
- Gathering general information from the user and getting an overview of the problem
- Confirming the exact question
- Intervention, such as giving information, advice or instructions
- Finishing, including feedback and summary
These stages may occur in loops, for example when a clarification of the question leads to the need to establish more background information on the query topic. These steps are designed to put the user at their ease, and then help ensure that they have correctly explained what they require. When the reference librarian believes that the query is fully understood, they attempt to provide resources that help satisfy it. An important and often overlooked final step is checking that the information or service provided was indeed what the library user required.
I find it useful to be mindful of this concept and be ready to use some of these methods, because they make feedback and criticism sessions more efficient and empowering. When criticism and feedback sessions are unstructured or too casual, conflicts arise from assumptions about what other people are saying.
When It’s Time For A Divorce
There will come times that despite your best efforts to communicate smartly, be detached from the project, and accommodate the client’s requests, that you just have to walk away from a difficult client. You may have explained why things should be done certain ways, based on your professional experience and skills, but the client just insists on sticking with a bad decision. Sure, they are the client and they are paying for the solution that you know is bad, but there will be other factors that prompt the divorce process. These can include everything from missed or late payments, to constant uncompensated design changes beyond the contract terms, to mercurial temper tantrums on the phone or via emails, and clients who delay and obstruct the launch or ending of a project.
Good luck!
