If you read the last post by Gigg on design and development teams pairing, you know that here at DevMynd, the developers have it easy.
We take a design-focused approach to problem solving, which means a successful product has already been well crafted by our design team long before myself and the development team begin our contribution. In a hugely unfair generalization, here is how the typical project plays out:
- We consult with the client on scope, budget, etc.
- Design team performs field research and user interviews
- Design team recognizes the problem that the product is intended to solve
- Design team maps out a storyboard based on research and persona testing
- Design team iterates on diagrams and wireframes
- User stories are written and continuously iterated on
- Dev team starts implementation
- Design team produces high-res mockups and style guides
- Design team answers a million questions from dev team about user interactions and state
- Dev team iterates on the stories until a polished solution is produced
Why am I telling you this? To point out how much upfront work is accomplished by the design team at the onset (and throughout) a project’s lifecycle. Knowing the design effort that goes into a project, the dev team is fully committed to being pixel perfect on every implementation. It just wouldn’t be right to leave something omitted or to deliver unpolished work.
Dev & Designer Pairing
Design and UX is fascinating and so important to build product momentum. I love learning about it from the awesome design team here. When the idea was discussed that I pair* with Gigg, I was ecstatic. Not only would she bring her wonderful energy to the pairing station, but I also stood to gain a lot insight into what product design really entails. I know what I like from a product, but I often neglect the general use case.
* We love pair programming, this is my favorite post on the topic
Machine
This was pure comedy. We would be ready to start pairing and every day, without fail, the first question I would ask was, “Gigg, where is the terminal!?” It just wasn’t a tool that she routinely used. By pairing, I think she realized some benefits to knowing how to use the computer from the command line.
Other machine customization options were left up to her. I have my specific key bindings, aliases, and bash profile options, but did not pollute her world with my own craziness. Key mapping CAPS LOCK into CONTROL was the only option I really needed…
Mutual Construction
Gigg wrote a lot about setting up our Sass variables in order to maintain consistency. Pairing with her made this process insanely easier. Instead of me having to dig through a bunch of Sketch files* to find out how many different shades of gray were needed, she pretty much nailed it instantly. The designer has a better inventory of the various pages and how shared components are used throughout. We were able to turn that knowledge into simple CSS so anyone joining the project down the road would feel safe doing styles.
As Gigg would perform consistency checks, I would help to validate the designs. Sometimes, the design just doesn’t look the same when it’s loaded up in a browser. Add a little padding there? Bump that font size? Okay! What is the interaction when this button is clicked? Do we change the state on hover? Constantly resizing the screen and ensuring responsiveness was now a shared responsibility. Having a designer as a pair was key to getting these types of questions answered efficiently.
* Biiiiig fan of using Zeplin for implementation. To a developer, the tagline could be “Just like Sketch, but with 10x less clicks”….
Other Benefits
Sometimes, a mockup just isn’t enough for me. Those box shadows are quite hard to see, but the designer knows exactly what is needed. Having a second set of eyes on design implementation is definitely a productivity boost.
Our team structure often changes due to project / staffing demands. Another perk of using a dev/design cross-functional pair is that terminology becomes simple, consistent, and aligned accross both sides of the team. We can use an opaque term like “drop header” and the designers and developers know exactly what component is being referenced.
At DevMynd(software development company), the team participates in a group project retro once a week. These retros are crucial to our success, as they help us uncover problems, brainstorm on improvements, and keep rocking with what is working. In a retro, I mentioned that I was having trouble tracking all the design tweaks. Mockups were changing quickly and there was not a good way for me to follow the history or track what was left to tackle.
Gigg and I recommended that we try pairing together, the team endorsed the idea — and from there we knocked out the design implementation in less time and with fewer mistakes than usual. I can’t wait until we are able to do this again. We can continue to learn new skills and deliver great products as a team, plus it’s realllllly fun to pair with Gigg.
