When we first moved into the Jitterbug building, my two brothers came to help fix it up. I wanted to get rid of the bar that had been in place before, and build a little bakery counter that would be a comfortable height for me to work behind (I’m short) and use some old windows I’d bought off craigslist to showcase the baked goods.
Brother #1’s Approach:
We can definitely build it. First I need you to figure out exactly what size you want it to be, where the windows should go, and draw me up a plan — a basic blueprint to work from. Then we can look it over and figure out what exactly we’ll need and then we can put it together.
Brother #2’s Approach:
Counter about this high, stretching across this space, and using as many of those windows as we can fit in, with a shelf inside and some kind of back covering to keep dirt away? Yeah, I can do that. I’ll do it right after I finish this other thing.
Jane: But, Brother #2, don’t you need a plan, a blueprint?
Nah, I know what you want. If it’s not exactly what you were thinking as we go along, we’ll just check in along the way and we can always redo a bit if I don’t do it how you pictured it. It’s not rocket science, you’ll be happy with the end result one way or another.
Guess which brother was in charge of building the counter? Brother #2. Brother #1 worked on it as well, and so did I, but Brother #2 was ready to jump in and rough it out to move things along quickly. He had no compunction about ripping something out if it didn’t work the way we intended, and embodied the idea of prototyping into iterative improvement/development so completely that I couldn’t help compare this experience to working on WordPress.
There are two schools of thought among WordPress core developers, it seems — the coding equivalents of Brother #1 and Brother #2. Â Brother #1 in core terms would be asking for wireframes before writing a line of code, and for everything to be completely figured out in advance. Brother #2 would be more of a jump in and get something started kind of dev, who prototypes using his best judgment and solicits feedback on design aspects as the build itself comes together and can be experienced as a prototype.
When I started working on WordPress, it was mostly Brother #2s. If I said an idea in skype or IRC, someone had it roughly coded to look at before the rest of us were even done talking. Lately, it has felt like we’ve shifted more toward Brother #1s. Statements like, “We need wireframes,” or “You have to decide exactly how you want it to work,” come at me in IRC and Skype, making me a bottleneck and a gatekeeper to development. Yuck!
I don’t want to make any more wireframes. Period. 10+ years is too much. I don’t mind doing up a sketch now and then and putting it on Trac, but I’d like to see more of a return to Brother #2 style development. (There are definitely some in core who do work this way currently.) Just start prototyping. Better UX decisions will almost always come from playing with a prototype vs just imagining with pen and paper (or computer and mouse/wacom). That’s not to say there isn’t a place for specs — when there are a lot of developers working on something, a spec is really useful for keeping people on the same page. But that spec could be as simple as a written description of the feature or change that’s archived and updated as the project evolves.
I did a lot of wireframes in the beginning with WP. In 2.7 we had the Crazyhorse wireframes, which Liz and I did to communicate something totally different to developers I’d never worked with before. In 2.8 with widgets, I did them because we were radically changing the UI, but even more because the underlying widgets code was so sucky that experimentation would have taken forever in a live situation and I didn’t want to put Andrew through that.
Since then, I’ve avoided doing many wireframes. I like it when the dev takes the first stab. Not only does it remove me as a bottleneck, it puts more UI/UX ideas into play before things get finalized. If I do wireframes, then the devs are basically just builders. Which some like, I know, but many want to do product design thinking as well. And really, even for devs that don’t want input into design, having a conversation with a whiteboard or doing a rough sketch is just about always enough for a dev to rough it in as a 1st pass/prototype.
Think about how fast we could go. In this example, we’re talking about doing an update to the way Gallery tab works.
Brother #1 Style: I (and/or some other UI people and devs with a UI bent) review what we have, look at what else is out there right now, get some community feedback, throw around some interaction model ideas, core group debates, pick one, wireframe/write spec, start the build.
Brother #2 Style: “Hey, let’s make the Gallery tab better! Here are the 3 things we want to solve in this iteration. Core people: if you have an idea of how to improve 1-3 of these things, we want you!” Core people discuss their ideas, those deemed of interest make a rough prototype, I/core team/Matt/whoever reviews proposals (in prototype and/or mockup form depending on skillsets), picks one to use as base, makes list (for reference) of what to change in next round to better address the goals, someone starts development.
In the Brother #2 scenario, there’s no initial ux bottleneck, more people have a chance to propose ideas, proposals are focused on solving specific issues (vs being everything cool we can think of), and the real development begins with something to look at/refer to already in place. In Brother #1 scenario, it could be up to several weeks before anything gets coded… the same amount of time it would take to do several rounds of prototypes in the Brother #2 scenario!
I forgot to mention: my counter came out awesome. Not exactly as I’d first imagined it, true, but it served all my goals, was attractive — I’d never even thought of using beadboard until Brother #2 told me to start putting it on the front panel — and I was really happy with the end result:
The counter whose construction was led by Brother #2.
So: no more wireframes for me. Brother #2s, I’m at your disposal for ux feedback!
Jen (aka Jane) on WordPress 