How to handle critique and feedback for a design ticket

Design Lounge Communication and collaboration
1

On GitHub we talked about how we could and should accept and give design feedback on open source projects. There’s some great thoughts on this:

(sorry, this is a lot of copy paste, but it makes more sense to keep it all in one place:)

@simonv3:

We need to inform any non-designers how the design process works. We also need to inform designers how the open source and collective work process works. It’d be great if we could collect people’s thoughts on this and put them into a blog post. …

@elioqoshi:

I think there should be various options to choose from before starting a request. Mainly whether the requester wants to have full decision making on what to choose, whether there should be a specific group doing a decision, or whether there should be a completely open voting.

@simonv3:

A kind of toggle indicating how the client wants to go forward with the design, and where to take that conversation to the next stage if it’s an open format

@pdurbin:

Are we happy with the expectations that are being set? Let’s adjust the text as needed.

@evalica:

The problem is that it pretty much depends on the community, the designer, the people that participate, etc.

Since it would be hard for someone to write something that all the designers and all the organizations would agree on, I think a solution would be that the blog post would be a collection of quotes, where we say who we are and give either generic thought about “design feedback” or specific examples of how the feedback is handled in particular communities.

I followed the discussion on the Apache logo and it’s a telenovela :slight_smile: but it’s hard to say that it should go one way or another. Design style is subjective and designers and organizations have their own expectations. This doesn’t mean the work is not good, the designer cannot handle design critique or that the org is picky or disorganized.

@sbchittenden (username on GitHub):

How to give and receive criticism

Don’t defend your work

@sophiakc (username on GitHub):

  • I believe “Design” should be explicitly described: do we talk about graphic design or UX/UI? Those are 2 different things. Same for “Code”, do we talk about back-end, front-end, architecture…
  • Design like Programming isn’t a layer or an element separated from its context
  • I also don’t believe that open source contributions are a collection of subjective point of views. Instead contributors role should be a sum of qualitative inputs if appropriate. This requires to be clear about what kind of feedbacks are required. This logo issue in particular made me think about a painting from a museum anyone could interpret their own way. This is not the point of submitting a logo to open source feedbacks.
  • What brings value is:
    • being clear upfront about what is needed, whether it is related to the logo goals or the expected feedbacks from submitting it
    • being clear about the feedbacks wanted: from a usability perspective, from a code sustainability perspective…
    • defining constraints: time stamp for decision-making, expected outcomes, integration within the overall product…
    • getting things done and moving forward, considering that any tiny discussions are postponing possible deliverables. And time is our most value assets in open source community.
    • including usability perspectives and how bricks contribution can impact the whole structure
      problem-solve better and in a more sustainable way

@victoria-bondarchuk

Learning to communicate design and how to talk about it is an important skill not only in open source communities, but in the industry as well.

I’ve stumbled upon an interesting book “Articulating Design Decisions” by Tom Greever.
The book focuses on principles, tactics, and actionable methods for presenting designs. However it also has some advices for non-designers and those in a project besides designers who are interested in learning to talk about design.

Here is some advices from the book, which I find very useful:

  • Focus on what works
    Remove the word “like” from your vocabulary and always talk about what works or doesn’t work. Personal preferences are less important than the needs of the user.
  • Ask lots of questions
    This is the key to seeing from designer perspective and understanding designer motivations. Ask questions to uncover designers thought process.
  • Don’t claim to be the user
    The truth is that every user is different, and you don’t represent the target market any more than the designer. Claiming to be the user of your app or website does not add value to the conversation.
  • Let designers explain their decisions
    Don’t offer your own perspective and walk away. Allow designer the time and space to form an adequate response.
  • Empower designers to make decisions
    Even if you disagree with designer choice, learn to trust designers in areas where they have more expertise than you.
  • Use helpful language
    It can be difficult to receive feedback without becoming a little defensive. Avoid harsh or extreme language and focus your feedback on the designs.
  • Give designers what they need to be successful
    Whether it’s logins, access to analytics, or permission to do usability testing, we need things from you to work effectively. Make it a priority.

(from: Greever, Tom. Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience. O’Reilly Media)

from @evalica

FOSDEM panel “Design feedback in open source”

from @timthelion (GitHub username)

http://bikeshed.com/

from @grahamperrin:

http://www.dealingwithdisrespect.com/

3 Likes
2

I think we have enough here to have a very basic blog post. I can start drafting something.

4 Likes
3

@simonv3 I’m honored that you quoted me but to give more context, my original comment was about setting expectations when people click the link to create a job at Redirecting… and since that time the process has been much improved!

But enough about that little quote. I’d love to see a blog post and I’m glad you’re offering, @simonv3!

1 Like
4

If you put it on an etherpad or so, I’d be happy to chime in.

1 Like
5

(Quoted by Simon)

Hopefully not taking things out of context (I have not read the book) …

Spoken language, face-to-face

I think that it is OK to express personal opinions/preferences. Personal – without claiming to be representative of other people (unless those others have chosen the one person to speak on their behalf).

In design/implementation situations: when I hear (or overhear) phrases such as “that works for me”, more often than not I think of the vocubulary as unnaturally stilted.

Worse: when I hear the phrase “that works”, I sometimes understand it to mean that the person presumes to know, without consultation, what will work for other people.

In most situations I prefer to hear, and see, people speak more freely. Unnatural removal of commonplace words such as ‘like’ can be a hindrance.

YMMV :slight_smile: and of course, what’s appropriate when writing may be subtly different from what’s understood through face-to-face engagement with two or more people in the same room.

Background

For newcomers to this forum, who may be unfamiliar with the GitHub issue from which this topic originated: @simonv3 wrote:

We need to inform any non-designers how the design process works. We also need to inform designers how the open source and collective work process works. It’d be great if we could collect people’s thoughts on this and put them into a blog post. …

6

Good call on bringing in that context, I’ll add it to the first post!