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:)
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. …
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.
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
Are we happy with the expectations that are being set? Let’s adjust the text as needed.
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.
@sbchittenden (username on GitHub):
@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
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)
FOSDEM panel “Design feedback in open source”
from @timthelion (GitHub username)