The Inclusive Lab Space is an intended framework for the iGEM community to conduct their own inclusive design projects. Walk through our design process and learn about areas where our team performed or diverged from the best practices, and how to approach challenging aspects of an inclusive design project.
Purpose of this Page
The initial project idea started with the suggestion of engineers in dry lab suggesting to follow the course structure of UBC’s BMEG 455 “Professionalism and Ethics in Biomedical Engineering” course. It goes through a way in which engineers can do Inclusive Design Process. However, due to roadblocks our team on occasion diverged from the ideal way to go about the process. To ensure that the iGEM community is informed on best practices, we decided to document the best practices, and include examples of when our team performed or diverged from the best practices.
Why Inclusive Design Projects are Important
Inclusive design projects are an additional framework in the engineering method to fully understand a person’s lived experience when interacting with the environment around them. What is unique about this design process is that it aims to start the design process with a representative of a group as a user, either an individual or small group, then the process broadens to encompass more people. The design process also emphasizes that your user should be a collaborator, and be involved in the design process throughout. The reasoning is it’s crucial to first fully understand what difficulties a singular person experiences, so that the design fully targets their needs, then by fully ensuring it works for them, others who face similar difficulties can determine if it works for them. An individual’s specific lived experience is used as the requirements to the design before performing the usual engineering design process. Often designs are made based on what the designer believes to be important, which can lead to bias depending on what they expect to be needs. As well, scientific experiments often use random sampling, however, that would mean some people who are in the minority can be missed during the selection process. In inclusive designs, the user is not a research subject but an equal collaborator whose expertise comes from lived experience. Without adequate conversations of people with differing lived experiences, the designs will exclude them, increasing the number of barriers they may already face when interacting with the environment. By performing an inclusive design projects, which focuses on a single individual or small group’s barriers, the design can appropriately match their needs, then be built upon by others, ensuring inclusion for more by adequately tackling specific needs.
Here, we want to emphasize the fact that inclusive design isn’t just for those that are traditionally labeled as disabled, but rather it’s for everyone and anyone. Creating inclusive designs is to remove a barrier that society has created, intentionally or unintentionally. There may be barriers for people who are not medically considered to have a disability. People at different life stages, such as children or older adults, may also face barriers in access. As well, people may not consider themselves disabled. This aligns with the social model of disability, which defines disability as a division between a person and their social environment, rather than something inherent to the person. It is crucial that in inclusive design, one works from the lens of the social model of disability, so that instead of trying to change the person, they change the environment in which the person inhabits, so that the environment better aligns with what the person can do.
Within our own project, we focused on improving accessibility in wet labs. For many, wet lab is a source of employment, passion, livelihood, and enjoyment. As wet lab is heavily dependent on one’s hands, a single accident or overuse can lead to the development of a musculoskeletal disorder. Our idea with the Inclusive Lab Space is to create a tool to ensure wet lab remains accessible to researchers whose musculoskeletal disorders or wrist pain prevents them from accessing the wet lab in the same way as those who don’t struggle, ensuring no one is left behind.
Part 1: The User
Finding a User: How we did it
One large area that we learned from was our approach to finding a user. The engineering design process states that an inclusive design project should begin from one user, and is designed solely for that user before it becomes widespread and universal. This is to be inclusive of all levels of abilities, and to not introduce bias during the design process. Based on literature reviews of statistics, we identified a few disability groups based on prevalence, that we wanted to work with. From there we reached out to community organizations and campus clubs based around accessibility to initiate collaboration and potential user outreach. We began most collaboration by email, before further pursuing online meetings and even in-person meetings. While this route sparked initial collaboration, it was also important to note we were in search of a user with a wet lab background. We quickly pivoted to specifying our outreach to professors and campus alumni in our relevant field, physical therapy and musculoskeletal clinics, and research labs. Ultimately, our user was found as she was a colleague of an iGEM member who put us in contact.
Finding a User: Best Practices
Due to the broad range of abilities, it is unlikely that a single solution will work perfectly for every person. However, those people then become excluded from the design. In inclusive design projects, the design process is to understand one person’s individual needs and solve for that one person. That will ensure that the design actually helps a person with specific needs, then the design can be branched outwards to positively impact others. This is why the user is the most important component of the project; the project ultimately revolves around their needs. Therefore, the best practice is to first find a user, understand areas that they face exclusion, then develop solutions to help them. Although our team did not find users this way, the optimal way would be to first find a user. This could be done by connecting with University accommodations and to see whether they can connect the team to students who face difficulties in their fields due to insufficient solutions to their needs. By talking to different students and understanding their different needs, the team can determine what is a feasible approach for a fellow student and begin evaluating if your team would have the ability to design something for them. However note that it might not be immediately clear how to go about designing a solution, so be careful not to give up on creating a solution if it’s not immediately obvious.
Part 2: Understanding the Barriers
Literature Review: How we did it
Literature review was conducted before beginning this project to determine its prevalence and feasibility, but also during the design process to better understand how we should formulate our target design specifications. While our design was centered around our user, literature review was done prior to even beginning to find a user, as our team didn’t manage to find one for a long time. Literature review was done to ensure we were educated on the range of who is affected by MSK disorders, how it affects them, and how MSK disorders might affect individuals in ways that are not easily apparent. We learned about many different MSK disorders and were able to identify reoccurring and common struggles for those with MSK working in wet labs. All of these factors ensured we were inclusive of all perspectives and individuals, which also helped us understand the range in which we could tackle this issue. Additionally, we conducted literature review to research what tools already exist to aid this group, providing us with inspiration and resources that aided early stages of our concept generation. To continue our design process without a user, we translated common user statements from the literature reviews into user requirements that we built our design specifications around. We compiled user statements and derived an associated need that targeted each statement, then determined what requirement we would implement as the “solution” to that need. Based on how many times a statement came up in our literature reviews and how prevalent it was, we distributed weightings across all needs.
Literature Review: Best Practices
Use the literature review to better understand any common struggles that your user can come across. The literature review can help generalize your users struggles, however it is crucial to remember that the priority is to help your user, rather then targets the common struggles that the literature describes. However, the literature can still answer some crucial questions, such as what tools already exist to aid your user, what would be their benefits and drawbacks that you can build upon, what is the scope that your team can actually work with, what are needs that your user may not be aware affects them, and known factors that cause or worsen your users experience. Literature review is also crucial in creating questions for your user, so that you are aware of what to look out for in the interview process, however the questions shouldn’t lead the user into stating what the team expects them to say, so the questions shouldn’t be leading and should mainly be open ended.
Formulating Questions for User: How we did it
Upon securing a user, we were provided with a brief backstory of her disorder and her wet lab work. We held two interviews with our user that were solely to better understand her needs before we began designing. Our initial interview was open-ended and gave our user the control to lead the direction of the conversation. Our objective was to make her feel comfortable in working with us, and this is where she further shared details of her initial injury, and how it still impacts her now in her wet lab work. Our second interview featured more technical aspects. We incorporated statements from her initial interview into our user requirements, and presented these to her. We went over all statements and ensure she agreed with all needs and associated requirements, as we were going to begin designing based on this. We also formulated open-ended questions to better understand sources/triggers of pain for our user. Instead of expecting our user to be able to give us information that we could directly translate into target specifications, we asked open-ended questions that guided both our team and our user towards a quantifiable answer. When formulating questions, it was important to not introduce any bias and to remain open-ended.
Formulating Questions for User: Best Practices
User agreements are key when working with a user. This is to ensure that the user understands completely what the point of the process is, what will be asked of them and what they are comfortable sharing when the project is documented. It is also meant to ensure that the user completely understands the voluntary nature of the working relationship between the team and the user. Just like in clinical studies, it should be explicitly stated that the work the user is helping with is completely voluntary, and at any time the user can stop participating at any point for any reason, without any backlash from the team. For a competition like iGEM, this is crucial to be aware of because of the timeline. A user backing out midway through the competition term could have a massive impact on the project, however it is crucial for the team to be completely understanding of the situation and to take it well. A project can go sideways for many reasons, and in no way is that the fault of the user, who had been volunteering their time to aid the team.
Part 3: Design Idea
Formulate a Main Project Target: How we did it
Our main project target was to formulate a framework to ensure wet lab remains accessible to researchers of all abilities. Our user in particular works with a wrist limitation, which led us to design an add-on for a micropipette with the objective of minimizing strain and overuse on her wrist. Multiple interviews with our user allowed us to translate her statements into requirements to formulate our design specifications. To ensure our design was the best fit it could be for our specific user, we held follow-up interviews that verified her agreement with our translated needs, and presented designs and received feedback from her. Additionally, we met with her in person and used modelling clay to mold to our user, and were able to better study her pipetting form. During the design process, we returned to our previous literature review and conducted further literature review to identify any gaps in our understanding, and to further solidify our overarching idea.
Formulate a Main Project Target: Best Practices
One aspect that our team wishes to improve upon is that although we reminded ourselves we would follow what the user stated to be most useful, we were biased with the idea of wanting to create a tool that can attach to the pipette from the get go. This is because of the delay in finding a user, so we started brainstorming design ideas from the literature and our own preconceptions of what would help us. This mindset could have prevented us from being able to brainstorm all possible ideas as to what could help remove barrier for those with musculoskeletal disorders in the wet lab. We want to highlight this for other teams, so that if they want to perform an inclusive design project, they try to remove any preconceptions of what their project design would be before working with the user.
Conclusion
After determining the requirements based on the user interviews, the process lends itself to a usual engineering process, however with additional interviews with the user to determine their thoughts on the iterative steps. We hope to inspire future iGEM teams to pursue an Inclusive Design Project so that they may use this page as a resource to help guide their project, and to follow the best practices and suggestions we we learnt throughout the process.
