Cross-functional Collaboration with Developers
A glimpse in the life: Understanding the developer’s workflow and their needs to bring designs to life.
Timeline
2-Day Sprint
Team
Katelyn Johnson (me)
3 designers
3 developers
Tools
Figma
Bootstrap
Express.js
Methods Used
Design Studio
Rapid Prototyping
Role
This was a highly collaborative project between all parties involved. I took additional responsibilities in designing the home page and annotating on Figma to communicate with developers.
OVERVIEW
Rapid collaboration with developers
This sprint was designed to give both designers and developers an enriching opportunity to experience a real-world scenario in which these two teams work together to see a design come to life.
I, along with three other designers, was linked up with three developers to design and build the following for an Extinct Birdwatching group:
A landing page that entices visitors to join the business’s group
A responsive version for desktop and mobile
An internal dashboard for the client to view membership activity
Overcoming the language barrier
To start out, we got a crash course on coding basics to begin understanding some of the language and terminology used in a developer’s day-to-day lives:
Front-end Developer = Responsible for working on what the users visibly see on any digital platform. Uses CSS, HTML, Javascript as their main coding languages.
Back-end Developer = The power house responsible for creating the building blocks for front-end developers.
Full-stack Developer = Having both front-end and back-end skillsets and capabilities
Master Branch = The main branch that houses the coding. Other branches can be tested throughout various stages within the master branch.
Camel-Casing = A type of method to name coding pages in a specific format, specifically referring to title-casing each word following the first.
EX: home_Page_Final_Draft.html
having_Some_Fun_With _Coding
Once we had a better grasp of the types of developers and basic terminology, we had the chance to code some small, yet surprisingly rewarding work within Visual Studio Code:
design_Studio_With_Developers
Rapidly brainstorming design solutions collectively as a team.
Once our crash course was completed, we linked up with our developers for the day and, once introduced, got right to work on the design for the Extinct Birdwatcher’s Group. We rapidly drafted some desktop-based solutions, and collectively discussed which features worked best for this sprint.
Moment of insight
It was fascinating to see how the developers reacted when it came time for us designers to share our work.
The developers mindsets were wired to quickly tell us if a component of our design was possible to create or not within the next 24 hours.
It was eye-opening to learn and better understand the general time-frame of building certain components of a design.
collectively_Creating_Wireframes
Connecting with the other designers to begin creating wireframes.
I, along with the other designers, began getting some lo-to-mid-fi designs set up in Figma to build the framework which developers would later use as their reference for coding these designs.
Landing Page
Lo-fi Design
Check-in with Devs #1
At this point of the design, we checked in with the developers to make sure this block-level design was manageable to create within the next 24 hours. We got the OK that this aspect of the design is safe to work with, so we continued to build it to mid-fi.
Mid-Fi Design
Check-in with Devs #2
Once we upped the fidelity to mid-fi, the developers main concern at this point was being able to successfully build a feedback message once someone join the Extinct Birdwatching group, so we continued to up the fidelity and work on the design of the success message we wanted the user to see once they joined.
Dashboard
Lo-fi Design
Mid-Fi Design
Check-in with Devs
The dashboard was a hugely collaborative discussion between the two teams, as there were a lot of elements to discuss on this page. As designers, we started asking questions about what was feasible to construct in the next 24 hours. Topics ranged from:
Filter & Search
We were curious to better understand the complexities of building a filter or search feature and if it was possible to build one given the time. Unfortunately, both took longer than our time frame to build, so we had to scrap these ideas in our design.
Pagination
We wanted our client to be able to switch from page to page in the list of emails, so we had designed a pagination bar, but to my surprised this was also too complex a feature to build in the time frame.
Active v. Inactive States
Luckily, our developers were excited to tell us that they were capable of building active v. inactive states for the left nav bar to visually indicate which tab the client was in when on the dashboard. This was a relief to us, as being able to visibly see and understand where the user is in the dashboard is a critical element to a good user experience.
Moment of disagreement
There came a moment of disagreement in our discussion when a developer showed excitement about being able to create a checkbox feature. I took a moment to consider this feature, and questioned what the value or need of this feature would be for the client if we’re only receiving basic information such as name and email.
My rationale:
In my eyes, there wasn’t any value being added to having a checkbox feature, unless we were gathering information from our users that indicated specific, useful information such as frequency of birdwatching or level of interest. If we were collecting data such as this, I could imagine a checkbox feature being valuable to sort our users by behavior.
We agreed earlier on in the day that we wouldn’t be asking for this information, as it complicated the form field submission and would require us to build out a separate modal, which we didn’t have time for if we were asking for more information than name and email.
As we concluded that we would only be collecting the minimal required information, I couldn’t find any rationale behind including a checkbox feature, as there was no justification for separating users only based off of name and email.
Moment of Insight
The developers were looking at the overall design from a functionality perspective - whatever they were capable of building in the timeframe, they were eager to do it.
The designers were trying to advocate for the user, trying to keep the “less is more” approach at the forefront of the decision and reduce unnecessary clutter.
annotating_For_Developers
Redlining
The developers expressed their appreciation for our redlining on specific elements to communicate the width and height via pixels. For the developers, this made their work go much faster by having clear direction from designers and the ability to input our requests directly into the coding.
Annotations
We utilized the annotation feature on Figma to quickly communicate back and forth on topics such as drop shadows, rounded edges, hover state, etc. Figma was an incredibly helpful resource, allowing for optimized communication between the designers and developers with the limited time we had.
Moment of Insight
One developer took ownership over pixel widths/heights on designs and “eye-balled” what looked best without the designer’s input.
This sparked my interest, as it went against everything we learned as designers to ensure optimal spacing between text, images, etc. and create intention behind spacing.
To hear that developers, if not given the exact spacing down to the pixel, would take ownership and make their own decision, surprised me more than I anticipated.
As a designer, this opened my eyes and made me understand how important communication, annotation, and redlining is when collaborating with developers to ensure we’re not misunderstanding one another’s expectations.
design:_Final_Products
Landing Page
Flipped bottom text and image to create a more dynamic layout
Horizontally flipped images to have the subject looking and pointing to guide user’s attention to important information
Simplified global nav, creating a hover state for the active page
Removed grey box from “See our rare sightings” for increased simplicity and white space
Responsive Mobile
Prioritized imagery and information to respond to mobile view
Expanded First and Last Name form fields and vertically stack them for better usability
Incorporated hamburger menu to keep global navigation element available
Dashboard
Created white space around vertical navigation to give it breathing room
Changed the main color to pass Accessibility requirements
Made a greater distinction between active v. inactive navigation with inverted buttons as inactive.
Removed checkbox, pagination, and search/filter features
developer:_Final_Products
Coding
The developers used VSCode to build out the landing page and dashboard
Landing Page
This is the final product the developers produced within ~5 hours after design decisions and wireframes had been agreed upon by everyone
“Join” button is active and live, providing a success message when clicked
The developers did not have time to create the active hover state underneath “Home”
Responsive design was in progress, but not completed within the time frame
Dashboard
This is the final dashboard the developers had time to produce
Developers chose to keep the checkbox feature, labeled “included”
The metrics functionality is live, tracking the increase in joined members per day, month, and year.
A hover state feature is live on the vertical navigation
Developers didn’t have time to change the color
next_Steps
If we had more time, I would’ve worked towards:
Taking more time to discuss and clarify the value of the checkbox feature with the developers
Taking time to build out a modal to ask more clarifying questions in the form field relating to behavior and frequency of activity for each user
Communicating with developers to update the dashboard to reflect our newest design version and improvements
Reflection
It was an absolutely incredible experience having the opportunity to work directly with developers. To my surprise, I found myself asking a lot of questions about the how out of pure curiosity. Luckily, this curiosity ended in increased shared understandings and empathy towards one another, which allowed us to discover how we approach the same problem differently.
I was intrigued throughout the entire sprint to understand why certain elements couldn’t be completed due to the time so I could have a better grasp on this moving forward with design decisions in the future. I had been told throughout the course the majority of designs aren’t able to be completed purely because of time and resources; this project validated this insight after experiencing it firsthand.
All in all, it was an enjoyable, refreshing, and extremely educational design sprint, where constraints were at quite an all-time high, but we were able to collaborate effectively to ensure we designed, developed, and delivered a fun product.
Project completed May, 2020.