Skip to content

Latest commit

 

History

History
74 lines (54 loc) · 6.27 KB

Bangalore-workshop.md

File metadata and controls

74 lines (54 loc) · 6.27 KB
Raw

Bangalore: Open Design Workshop/Masterclass

This file is intended on being a reference for resources for the attendees of the Bangalore open Design workshop/masterclass at DesignUP! conference 2019 in Bangalore as well as a repository for learnings from the event for the wider Open Design methodology and project.

Slides

You can view the slides used at the Bangalore workshop/masterclass here

The agenda here

The challenges issued to the team here

The printed resource templates here

Workshop living document

You can find the workshop planning document here

Witness

Our witness was Akhila, a researcher involved in researching the Kerala flooding of 2018 and 2019. Akhila works for Centre for Migration and Inclusive Development you can find their report on the Kerala floodings in .PDF format via a google drive link here

Workshop Observations

  • Full Workshop, around 40.
  • Participants from all over India.
  • Design savvy.
  • Split of interested in OSS and interested in Humanitarian.
  • Most agreed on Humanitarian principles for design led contributions.
  • Ran 1 hour over time.
  • Unclear start time.
  • The general adoption to Adobe XD as a tool to prototype was super fast. Not everyone had used before.
  • There was a lot of enthusiasm in the room and a lot of the participants wanted to know more about TenFour and Open Design.
  • Breaks need to be better considered.
  • If a workshop is to be part of a conference it's best to do that on a dedicated workshop day and not alongside speaker slots.

Learnings

Learnings on how to amend the methodology and/or the workshop framework.

Methodology

  1. Witness inspired a lot of persona-details.
  2. Witness crucial during idea evaluation and final feedback on prototypes.
  3. As the audience was more design savvy they felt clearly restricted by too narrow briefs, the more open ones worked better.
  4. All groups had some digital results in the end.
  5. Groups still struggled with GitHub
  6. Some attendees asked about other open source projects to work on the design for.
  7. The question about 'When is a design 'ready' for development' or 'finished' came up. This is the process that must be in place in the OSS technology that allows for some laddered process of deciding when a design contribution is done. Because by the nature of design it can be subjective to both the designer and the person/s approving the design. Attendees satisfied with this not being defined via teh open Design project but are aware of the problem and keen to see suggested solutions. Open Design should be prepared for debate and discourse regarding this topic.
  8. However the offer to continue on the topic in remote sprints needs more moderation. It is not as self explanatory as we expected and it is hard to keep up motivation after the end of the workshop.
  9. Adding the outputs in GitHub comments was questioned. Is this really the best way to contribute design? Again, a topic where the meeting of OSS/Mainter expectations and non-OSS designers clash.
  10. Better guidance on what to document, how and when. E.g. Take a photo of this activity, now write your names and team now upload to github etc.
  11. Some difference in workshop process and outcome sdepending on professional positioning. Student vs. professionals. Attendees supported each other with learning and activities.
  12. One group had a coder/developer in their group and they were able to ask technical fesibility questions to this member that helped them ideate within technical constraints.
  13. Specific focus on learning during the process needs to be developed.
  14. Recommended and documented ways to 'pick apart' or better understand and construct OSS issues that designers want to contribute to could be beneficial for both the Open Design process and the OSS projects benefitting from Open Design.
  15. Many designers are keen to see projects where the OSS is 'started' with design issues or in close alignment with code issues. Basically some projects that are right at the start of being built are what some designers want to be part of as well as established OSS projects.

Workshop Framework

  1. Sending out a workshop pre-email 1 day before the activity was not enough time for some to plan to download software on company restricted laptops.
  2. SIgning up for all the attached resource and tool sites takes a while and you can't assume people will do it pre-workshop.
  3. We ran 1 hour overtime so we either need to cut activities, lengthen the workshop or find a remote option.
  4. Challenges we regarded as too short in description or there was a lot of clarifying questions to the workshop leads like 'What are the restrictions?' 'What is success for the iuser?' 'Who are we designing for?'.
  5. Ideation phase took a little longer as the teams had a lot of input on: the scenario, the technology, the purpose. Narrowing down was hard and time consuming.
  6. 1st GitHub upload needs to be part of the workshop processes and outline. It can't just be a demo.
  7. Workshop is best delivered with two Open Design leaders and 1 assistent with a content and social focus.
  8. Refining the role required in a group and what their function is/could be e.g. 1 UX designer, 1 Researcher, 1 Documenter.
  9. Being able to have activities that can happen in tandem when prototyping starts is to be developed. 1-2 people typically operate the prototyping tool and other complete tasks like sketching, storyboards and documenting. But this way not everyone gets a chance to prototype in one workshop.
  10. The exercises are part of de-constructing a typical OSS 'issue' and many of the attendees understood this afte rthe process was completed and this part explained.
  11. Picking apart challenges/issues could be more explicit as part of the workshop and less implied.