Mob Designing — is it a thing?
Yep, we know about mob programming. It’s a technique the developers use here at Red Badger to work through stories, from complex programming problems to deciding on the lexical semantics of CSS, and is based upon the concept that more brains are better than one.
The basic principles are that you have a team (three or more, otherwise it’s just pairing really, isn’t it?) all positioned in front of one screen, with one keyboard and mouse. One member is the Driver, who controls the machine, and one is the Navigator, who gives instructions to the Driver. The rest of the team discuss and troubleshoot the problem you’re mobbing to solve. It uses the philosophy of Lean Thinking, and the idea is that you become one unit, a collective brain that thinks through the same thing at the same time.
We’d seen the developers do this a few times, sat in on a mob when they were going through design snag lists etc, and one day thought, well, there’s no reason we can’t mob design too, is there?
So we sat down with one story, one computer, and four designers. And it was marvellous.
The main change in workflow we noticed was that everything happened at such speed. It was like we were in a constant and infinite feedback loop, with immediate peer review and just-in-time explanations, which allowed for rapid feedback and validation. The principles and practices allowed us to keep focused — having just one monitor and no personal laptops or phones mitigated most of the usual modes of distraction. It turned out we were more resilient to interruptions from the rest of the studio, and also from absences of team members as the rest of us could continue working or even swap someone else in for a while. More eyes = better eyes.
Tinker, Tailor, Soldier… Driver
It was a strange feeling, having a Driver in control of your ideas — for that idea to go from your head into the computer, it HAD to go through someone else’s hands. It made obstacles seem less daunting, and it was easier to make brave decisions when facing them together. It accentuated the benefits of face-to-face and side-by-side communication, eliminated the need for meetings, and reduced delivery time buy removing the need to wait for a stand-up or review to raise issues — we frequently found that we all had the same thought at the same time, as we were all working on it together. We were continuously learning, from keyboard shortcuts to responsive behaviour rationale, and individual gaps in knowledge could be overcome. When you have to work through each other there’s nowhere to hide — you just get better.
Design by Committee?
This was not. I can imagine that for some Mob Designing sounds like a pale, first-world version of hell — no headphones, no cool, calm corner to burrow away in and try out shades of gradients, no ownership over button radiuses or line heights. But for us, it was a natural extension of how we work every day — not a morning goes by when I haven’t paired with a UX designer, or developer, to discuss a story or approach to a feature etc. At Red Badger we have constant conversations within our teams, so why not within our disciplines too? As consultants and proponents of Agile, we have the luxury of never working in silos.
Energised, Focused, Autonomous
I think mob designing makes perfect sense — after all the team _doing_ the work can best determine _how_ to do the work. There was no decision-making disarray, no analysis paralysis and no needless waste — everything was transparent and there was always someone there to say “come on, this is MVP guys” when we started to stray out of scope. When you’ve got someone who’s best friend is Sketch, someone who knows all the secrets of Craft, a couple of casual coders and four design lovers, what can go wrong?
First published on the Red Badger blog bit.ly/2iTqv8P