Collaborative Guidebook

The Collaborative Guidebook is a bridge for differing expertise between designers and developers by aligning their goals in an intimate setting.

Check it out!

Project Summary

Made as a practical application of ethnographic methods and human-centered cognitive design principles for the Cognitive Design Studio.

Exploring the Problem Space

Reaching Out to Potential Userbase

industry meetup
"Product Managers, Product Owners - are they really different?" meetup at ProductTank San Diego, where we scouted for contacts.

Our first step was exploring our problem space and talking to potential users to define and refine the design challenge.


We reached out to professional designers and developers we knew and those we didn't to broaden the userbase's scope and investigate what problems they had, their feedback processes, interactions with other departments and teams, etc.

Industry Meetups

Industry meetups introduced us to developers, designers, and even secondary stakeholders. In the ProductTank meetup shown above, we managed to connect with product managers and owners and UX Designers who provided helpful information and interviews.

Methods for Field Research and Interviewing

After establishing connections we interviewed them in-depth to discover what issues designers and developers faced when collaborating with each other.

Interview Guidelines

The interview protocols we made for everyone's convenience.
The interview protocols we made for everyone's convenience.

Before heading into formal interviews, the team made a set of guidelines as a reference for conducting efficient and effective interviews.

Online Surveys

Feedback Incorporation and User Research Surveys
Two of the surveys we sent out in the wild. Made with Google Forms.

“Team Feedback and Designers: A User Research Survey” aimed to target how design and development teams received and incorporated feedback into their work.

“Feedback Incorporation Survey” focused on collecting information on how individual designers and developers interacted with feedback in their work.

Defining the Problem Space

google spreadsheet of quotes and classifications
Highlights from our interviews where we aggregated and dissected them for key takeaways.

We extracted quotes from interviews and organized them into a spreadsheet that listed an ID number correlating to its specific interview, the quote itself, what kind of task the quote would be, Type (of category quotes/tasks can be placed under), and Post-It Note Color.

For example, there was one quote that said, “When engineers make assumptions about things it's always bad, that's why there's the stereotype of a website designed by an engineer versus a designer.”

We interpreted this statement as a belief that developers should not design interfaces and placed it under Feelings/Philosophy since this reflects someone's personal beliefs on engineers making assumptions about user interactions.

Insights and Problems

Tasks That Need to be Accomplished

  • Interviewees commonly stated that they would quickly message a designer or developer to check for feasibility and/or the usability of a design.
  • Designers and developers usually document notes from a feedback process which the whole team can look at.
  • Benefits of Team Feedback

  • Team feedback is important for bringing in context and background knowledge.
  • Team feedback gets rid of any assumptions a designer or developer might have.
  • Challenges of Team Feedback

  • There are often conflicts between designers and developers when it comes to the others' domain knowledge.
  • Incorporating team feedback can be messy and pull the project timeline back.
  • Going Forward

    Interviewing and consolidating research helped us realize we'd need to hone in on the issues surrounding the feedback process involving designers and developers. Findings also showed that project managers are also an important group in the feedback process, so we included them in the triad (designers-developers-project managers).

    whiteboard with words on them
    Our mission statement that helped us keep focus on design goals.
    Transcription: “We are solving the differing expertise between designers and developers by designing collaborative activities surrounding feedback.”

    Organizing Research

    Our first goal with organizing research was to make an affinity diagram to consolidate interview data for a big-picture perspective on findings and to confirm our hunches from gathering data.

    Affinity Diagramming

    initial organizing on post-it notes
    Initial organization of concepts and early findings.

    To start, the team directly translated quotes and categories from the spreadsheet into a rough draft of the diagram based on earlier assumptions made during field research.

    This turned out to be a mistake as we realized that we made these categories based on a top-down approach of forcing findings into labels rather than organically discovering commonalities and working bottom-up.

    The team researching and affinity diagramming
    The team writing down quotes and affinity diagramming. You can see me between my teammates' heads!

    During the diagramming we wound up with more than 100 points of color coded data and worked together to codify all of them into a physical artefact for our team's usage and understanding.

    Close up example of some quotes
    A close-up of a section of our affinity diagram, “developers' challenges/concerns with design”.

    During the process we made and replaced categories as we better understood the problem space we entered.

    full spread of affinity diagram
    The full view of the affinity diagram.

    We finalized commonalities in our research and began matching quotes with commonalities (with some outliers):

    Identity Models

    After affinity diagramming, my teammates Diana and Ben visualized the commonalities and how they relate to our stakeholders in an identity model. This way we could see how a user's identity impacts the integration between user and product. Understanding stakeholder identities was crucial to understanding how to improve team dynamics.

    Rough sketch of identity model
    A clear draft of how we visually organized the information on the identity model poster.

    The initial draft involved splitting the board into three sections, “I am”, “I like”, and “I do” that included terms describing the stakeholders we designed for.

    final identity model
    Our final identity model poster.

    The two gave the representations of stakeholders, or “proto-personas”, to life by providing each one background information (based on our interviews), a brief one-liner that sums up their identity and/or needs, a list of needs, and an image to give us a face.


    The persona of a stakeholder I made.
    The persona of a stakeholder I made named Jim. Legend says he's still under pressure to this day.

    With the identity model made and a better grasp of the stakeholders we were designing for, we proceeded to create concrete personas that would provide a deeper look into the more specific problems stakeholders face.

    Ideation Process


    Basic storyboard for designer-developer disaparity
    One of a few storyboards to help us ideate possible design solutions.

    Storyboarding helped us ideate possible design solutions* by exploring user scenarios to envision how solutions might fit into their workflows.

    Note: At this point in the project, we were a little wobbly on focusing on the design problem as a group. Storyboards thus included solutions that somewhat deviated from the problem space that we later reevaluated into the final solution.


    Initial whiteboarding
    The team discussing how we would direct the flow of feedback towards the end of the ideation process.

    We held a white-boarding session to confirm our collective understanding of the project scope. Eventually we worked out the best way to guide the flow of feedback sessions in the guidebook.


    The team diverged for a brief time so we could individually ideate solutions. Later we would converge again to critique, compare, and combine individual solutions.

    I came up with a color-coding system that would help track different types of feedback. To help the team prototype/envision it, I suggested building it with lo-fi materials such as straws or chopsticks.

    An unused idea I had
    A color-coding idea stemming from an earlier concept of using board games for collaboration.

    In a grid, a marker symbolizes the importance of a task/goal in relation to its progress in the project. The grid position is then categorized with a color and entered into a system.

    All those visualized markers would collectively indicate what tasks were on schedule and what endeavors were falling behind. This way, executives and project managers could be updated instantly.

    Due to feasibility and relevancy issues this idea wasn't used. But it's still pretty cool, at least in my book.


    The team discussing the design
    Early whiteboard drafting with our mission statement to keep us on track. A wise man once said, “This is where the fun begins.”

    Upon convergence we achieved singularity of minds to finalize the guidebook's format and contents.

    To achieve a unified direction we presented individual solutions, discussed their merits and short-comings, and then incorporated helpful elements into the development of what would become the final draft.

    Messy ideas on a whiteboard
    Making progress: the design is coming together.

    During the white-boarding session we further elaborated on storyboards to hone in on specific interactions users may have. Also considered was how the guidebook's information would be used in the greater user ecosystem.

    Finding common ground
    Coming to a consensus; the birth of the guidebook's blueprints.

    After a whole lot of discussions and smelling expo markers, we landed on an agreed guidebook flow that would direct the feedback process. All that was left was to produce a hi-fi prototype.


    Unfortunately due to the studio's final report (a whopping 37 pages) and other finals occurring, we didn't have enough time to test. Ideally we would have liked to:

    Ideal Steps

    Had we more time, we would have refined the guidebook's visual design, implemented an efficient triage system for task importance and viability, and provided more context or instructions for ease of use.

    Final Design Solution

    Final guidebook
    The final guidebook, made in Illustrator by another teammate.

    The final solution is a 5-page guidebook that helps facilitate collaboration between designers and developers while maintaining communication with project managers during the feedback process.


    While this project was difficult to wade through and to understand all of the moving parts, I still learned a lot about user research and how important it is to not be afraid to reach out to a userbase, carefully organize findings, and then discover root problems and needs through a bottom-up approach.

    Final Deliverables

    Collaborative Guidebook