A blog post about how to handle critique and feedback for a design ticket. about jobs HOT 20 CLOSED

I think #108 is a great example how everyone in the community is learning how to talk about design.
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 jobs.

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.

Does anyone want to take steps in that direction?

@simonv3, @evalica
Not sure I would be up for authoring a blog post, but after following this thread, here are a couple of links to some articles that touch upon some of the responses:

How to give and receive criticism

and

Don't defend your work

from jobs.

We could actually have a talk at FOSDEM about this :) ("Expectations" vs. "Reality" in design critique)

from jobs.

I'm not sure whether it is productive to lay blame with any one person. Continuously calling out someone and bringing them back to the thread when they've moved on, are trying to move on, or burned up their energy on it is not bound to end well.

I don't think the code of conduct was breached. Some people said some defensive things, and tones might have been curt, but the conversation had moved on, and later comments seemed like straight-up unnecessary baiting.

I don't want it to continue here. If you have a personal grievance, please stop baiting people in public and take it to a private channel, like I said in the other thread, feel free to include me in whatever conversation you end up having.

In this case...

There was a dissonance between what the "client" in this case expected and what the designer expected to do. I think @pdurbin hit it on the nail - we don't set those expectations anywhere and maybe we should. I think @elioqoshi's suggestion is a great way to do that.

I also think that @evalica is right. A) we should have a talk about this at FOSDEM and B) an article / post gathering the different ways of doing things makes a lot of sense to me. Which is also why setting that expectation up front and talking it up front is a very important piece of making this "jobs" board operate smoothly.

from jobs.

At FOSDEM, on 5 Feb, we will have a session dedicated to "Design feedback in open source".

It will be in panel format, discussing max 7 questions (with max 3 minutes per question). The issue is that we have just 20 minutes to talk about such a complex subject, but at least we have this chance to discuss things :)

So, I want to know who would be interested in participating as panel members. I need MIN 3 people and MAX 5. I can ask this question also on the location, but I would like to know people are interested and I won't talk alone :) Thanks

from jobs.

Hey there! My feedbacks:

• 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

from jobs.

I'd love to be part of it :)

from jobs.

Topic moved here: https://discourse.opensourcedesign.net/t/how-to-handle-critique-and-feedback-for-a-design-ticket/107

from jobs.

(raises hand)

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.

This would prevent similar problems beforehand. I brainstormed with @bnvk about this in Berlin, he might have more opinions about this

from jobs.

That is an excellent suggestion. 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 (whether on OSD's GitHub or a project's Trello board - whatever).

from jobs.

At https://botbot.me/freenode/opensourcedesign/msg/76912549/ I'm asking if expectations have been set properly when someone clicks the link at http://opensourcedesign.net/jobs/ that says "You can easily add a job through our GitHub repository!"

When you click the link you are brought to https://github.com/opensourcedesign/jobs#jobs and this is currently the place where we can set expectations about how jobs are to be posted and what happens after a job is posted. Are we happy with the expectations that are being set? Let's adjust the text as needed.

from jobs.

A blog post about Design Critique would be very interesting and useful. 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 :) 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.

Anyway :) lovely topic... and the base stone in working in open source, as designer or even developer (when it comes to code).

from jobs.

I rarely do this type of thing but I have three things to say:

1. I am not particularly happy with the way this whole Apache Camel logo issue (#108) played out but I am also not completely disappointed. The traffic alone is a success IMO: https://cl.ly/2n3k3v393R21
2. I wanted @elioqoshi's design to be the winner (as many others did) but I think the way he acted after was completely hypocritical since he gave a talk about "Overcoming Your Designer Ego".

...But Elio says we can learn how to add transparency to our workflow, and praise “sharing is caring” more than “made by me”

3. If Open Source Design has a Code of Conduct and our own member(s) don't abide by it, how do we expect others to respect it?

I think you are very talented @elioqoshi but I also think you handled this very poorly.

from jobs.

@simonv3 I agree on not continuing here and I that is why I said, "I rarely do this type of thing..."

The only reason I brought up the Code of Conduct is because you brought it up.

What is the private channel? IRC is unreliable in terms of attendance. I want to hash this out and not just sweep it under the rug.

from jobs.

I brought it up because I wanted to call it to people's attention to make sure people kept it in mind and didn't overstep it. If you're concerned that that was the case, let me know via e-mail. Or anyone listed in that to-contact list on there.

Private channel is up to you! I realize IRC is spotty, but it's readily available and accessible by everyone. Another option is Twitter DMs?

We can hash things out, and that's what this thread is about, but I'd love to do this blamelessly.

from jobs.

Still completely confused why people bring something up when I apologized very clearly in the thread. But not going to go into the ego and hypocrite topic here, since this is a meta discussion and not about me (or even the example of my actions).

from jobs.

Maybe I'm biased, but it's also important to have some best practices on how to give feedback as well, as that's the other side of the coin. Of course, as a collective we need to focus on being better in receiving feedback, but ideally, all parties involved should be aware of their responsibility when being in such a process.

from jobs.

I've not read the entire thread on the apache camel logo, however, it seems to me that any blog post on this topic should include a link to this seminal essay: http://bikeshed.com/

from jobs.

… how to handle critique …

http://www.dealingwithdisrespect.com/

… how to handle your audience and critics, no matter what they throw at you. …

from jobs.

Is there anyone who wants to craft a blog post out of this? :) @simonv3 @evalica @elioqoshi @sophiakc @victoria-bondarchuk? :)

I’ll just close this issue cause we want to have all issues related to the website (including job board) in our website issue tracker at https://github.com/opensourcedesign/opensourcedesign.github.io/issues (less confusion where issues are ;) – please reopen there. :)

For general discussion, we recommend to use our new Discourse forum at https://discourse.opensourcedesign.net – we even have a category for »Communication & collab between designers & devs«! :)

from jobs.