Case study: A platform for fostering the collaborative spirit within the design community
Designing a collaborative platform for designers, by designers
Over the past few years, a lot of resources have popped up to make design a much easier field to get into. From ADPList’s mentorship platform to Google’s UX certificate program, anyone who was interested in design could easily find the resources they need to learn about UX alongside its tools. As a relatively new designer, I can attest to the numerous resources available to learn and present UX projects, but there was something fundamentally missing: how could I work with others?
Enter Beacon, a collaborative project to design a platform that gives designers the accessible, equitable, and practical tools they need to build teams around the world.
A Beacon for Collaboration
Beacon became a collaborative project by pure happenstance: after posting a hastily drawn design brief on my social media channels, Rachel, my collaborator on this project, responded. After a few discussions, we decided to work together to bring this project to life, and after having learned aboutUX for nearly a year at that point, Beacon became the first project I worked on with another designer.
This coincedental experience and the discussion that followed highlighted two issues that we wanted to solve:
- Finding others to work with was inefficient, often requiring designers to network on social media channels or persistent communication platforms like Discord or Slack.
- Specializing in a specific role (e.g. information architect, researcher, etc.) can be incredibly difficult as an independent designer.
Google’s UX certification program, as well as other bootcamps, focus on building up a designer’s knowledge base and practical skills, while communities like ADPList are more network-centric in its focus on giving and receiving feedback and advice. While these programs and communities do help to make getting into design easier than ever, they cannot currently address the fundamental need for collaboration.
Validating the Need
Before beginning on the designs, Rachel, the project’s primary UX researcher, set out to validate whether there was a need for the kind of collaborative platform Beacon set out to be. By using social media channels and design forums, she scouted designers to interview them about their career experiences.
She was able to interview two participants, one from the US and another from Denmark, both of which held mid to senior-level UX positions. Her main findings have been outlined in the chart below:
Based on these findings, we were confident that there was a need for a platform like Beacon. While our participants expressed that one of the challenges they faced was their comfort level when working with others, they also cited a collaborative environment as a major source of motivation for working in UX. Other notable findings include the importance of having an end-goal as well as the influence of monetization has on motivation level.
With these findings, Beacon needed to be a platform that:
- Enables designers to build teams that facilitates each designers’ growth and productivity
- Opens up paid opportunities for working on UX projects
- Emphasizes a clear objective or end-goal
Competitor Analysis
By understanding the needs of our potential users, we set out to find any platforms that could address those needs. To be considered as a “competitor,” the platform had to closely match what Beacon aimed to be, but differentiate itself in its approach to providing designers with collaborative opportunities.
Rachel found one such competitor called Co.Lab, which utilizes a paid approach that pairs mentors with predeteremined teams to work on real-world projects over the course of 8 weeks.
While Co.Lab offers a guaranteed way for aspiring designers to work with industry professionals, it curates a lot of the core experience. This approach limits the kind of projects a designer could work on, and the pricing can be a barrier for lower income designers from joining. Furthermore, limiting teams to 4 members isn’t entirely relflective of actual design teams and the people a designer would work with; designers also need to know how to interact with engineers, developers, marketers, and shareholders involved in the project.
Beacon is more inclusive, accessible, and versatile in this regard as it relegates control over how projects and team building are handled to its community members. By accounting for the wide variance of requirements a project may have, scalability became a constant consideration throughout our design decisions.
Information Architecture
After discussing Rachel’s initial research findings as well as evaluating potential competitors like Co.Lab, I worked on a simple information architecture to chart each main process’ flow. For our deliverables, I needed to plan out the flows for the registration process as well as building and discovering teams within the Beacon platform.
This information architecture highlights the simplicity of the platform while making sure that users aren’t overwhelmed by too much information at any point. While features like lost/forgotten passwords, messaging, and notifications are shown in subsequent screens, this diagram was primarily focused on how our deliverables would interact with one another rather than serving as a comprehensive map for the entire platform.
Wireframing
With an information architecture in place, we crafted a few wireframes to visualize how each component and section would look. By mixing in some aesthetic details with low-fidelity wireframes, we were able to plan out some of the visual aesthetics that would go into the final version.
Prototyping
Once the wireframing was complete, we set out to establish the visual, aesthetic, and functional identity of the core design. During this phase of the project, I established a basic style guide for the typography and color scheme that would apply to all of our screen renders.
The bulk of our time on the project was dedicated to crafting, and iterating on, our prototypes. We used our wireframes as a foundation and gradually adjusted element dimensions, typography, and other visual elements until we got to a point where we were both satisfied with the outcome.
While many designers would often use placeholder images and text, we wanted to design with the content in mind — if our hypothetical scenario wouldn’t look right in our current design, we needed to adjust the design accordingly. This was especially important for content fields, such as the bio in the Profile Registration Preview screen, or role descriptions on the Role Card Selection screen — by understanding how much content can fit inside those elements, we were better able to gauge the limitations of a specific component or input field.
Being content-aware throughout the prototyping phase also led to design decisions focused on inclusivity. Specifically, while most sites with user proiles ask for a user’s gender, we felt it was more appropriate to ask for their pronouns rather than gender; the gender of the user isn’t relevant, but knowing how to refer to them is.
Usability Test
Once the screen renders were rigged up for an interactive prototype, Rachel was tasked with recruiting participants for a usability test. Using the same methods as her needs validation research, she was able to recruit 5 participants across India, Germany, South Africa, and Russia to be a part of the usability test.
To measure the usability of Beacon, Rachel employed a mixed-methods research approach by merging quantitative data from the System Usability Scale (SUS) with qualitative interview data for each participant.
Based on the SUS, participants had a generally favorable view about Beacon’s usability, with all of the participants scoring higher than the threshold for “above average usability” provided by the SUS’ authors. This finding was also supported by comments made by participants during their interviews, as they were all able to perform a set number of tasks with ease.
Although participants generally found Beacon to be easy to use, the main criticisms seemed to be addressable through proper onboarding. A plan to include onboarding was planned, which would’ve provided a walkthrough of the platform and a step-by-step guide for each of the main task flows (building a team and discovering a team), but we were not able to include it in the initial usability test due to time constraints. A sample of an onboarding process made by Rachel could be seen below:
Revision
With the feedback gained from the usability test, we worked on a few revisions to the base design. As the project had been ongoing for a few months, we decided to use these revisions as a way to mark the last iterations we would make on the project to demonstrate our ability to address user feedback.
The revisions above represent the most major changes we made to specific screens based on the usability test feedback. For Registration Step 4, all of our users were confused by the inclusion of traits, which we had initially done as a way to allow the back-end to match users based on similar traits. The section was ultimately replaced with one that allows users to expand their online presence, which was something our users had wanted and allowed for more networking beyond the Beacon platform. Subsequent changes were then made to the Registration Profile Preview screen.
The other major change came to the Discovery Project Page screen, which was revised to better represent how roles are shown. For roles that were taken, an image of the user occupying the role is shown, while roles that a user could apply to had a clear indicator. This change makes it easier for users to quickly identify any available, or filled/pending, roles.
Outcomes and Learnings
Beacon marks my first collaborative project, and it helped me realize what I was able to do as well as what I need to continue to work on. Having a partner in the project helped to establish a point of accountability for me to finish this project; if I were to work on a project on my own, I would’ve been more likely to have given up on it if I hit a roadblock or lose interest. The feedback that Rachel was able to provide was also invaluable, as it helped me to recognize aspects of my designs that needed to be addressed before it was too late.
For Rachel, I was also able to impart some lessons on how to conduct good research based on foundational scientific practices merged with the rapid iterative research processes common in the UX field. By the end of the project, she came away knowing a lot more about how to ask necessary questions, interact with research participants, and plan out her research studies far better than when she began this project with me.
While there were plans to make Beacon a tangible product, the harsher reality is that while we were able to design a platform that was well-received, planning out how to make the platform a sustainable business was out of our capacities. Nevertheless, this collaborative design experience has helped both Rachel and I grow as designers and demonstrates our abilities to design an accessible, equitable, and helpful platform.
