Organizing and simplifying, one illumination at a time
The last of my three rants about Big Up-Front Design discusses the conditions in which big up-front design is a really good idea.
It’s not always be a good idea to do big up-front design. Conversely, it’s not always a good idea to skip it. Th trick with this technique as with all techniques is to know when to use it and when not to.
I attended ForgeConf, a one-day conference about making and designing for the web. Because I believe excellence should be celebrated, I wrote a review for for the conference on The Interconnected.
Tickets normally go on sale in January or February so keep an eye out if you’re in the Philadelphia area.
I’ve tweeted a couple of times about a project I’m on where we’re doing a big up-front design. It’s a long project.
Every time I have, someone has replied back to me to tell me that if I’m doing a big up-front design, I’m not doing Agile correctly and I’m going to get burned.
Outside of the fact that it’s incredibly rude to tweet someone and tell them that their process (which the vast majority of us working in big companies get no control over) is wrong, there’s a problem here: there’s nothing wrong with big up-front design.
Explaining why front-loading a development process with a design process has been more difficult than I expected. My first draft was long and rambling. Turned out I really had three posts hiding within it.
My October 7 article for The Interconnected, Doing Agile Wrong: Design is not Development describes the difference between Agile and UX. It’ll be followed by an article on the difference between big up-front software design and big up-front product design. Then sometime after that, we’ll post the final article, which explains when big up-front (product) design is right for a project.
My September 20th post for The Interconnected, Two lessons, more than two bricks, discussed estimating software, stubbornness, and eleven tons of bricks.
My design estimating skills are pretty solid. My landscaping estimating skills? Not so much actually.
I’ve got a quest going, and that quest is to talk about the heuristics and theories behind my designs.
It’s one thing to design a big green button to start a process because the primary stakeholder likes big green buttons. It’s another to design a big green button because it needs to be noticeable, inviting, use color cues that for the primary audience’s culture mean “go ahead”, instruct the user, and make the call to action more visible. The first is client-centered design and that’s got its place in the world. The second is data-driven user-centered design, and that’s my bread and butter.
Similarly, it’s one thing to say that people need to learn a system I’m designing, and it’s another to be able to present my designs with the knowledge that the decisions I made were based on learnability heuristics.
Today’s post on The Interconnected — Learnability and Common Sense — talks a little about why learnability is important, a lot about why common sense isn’t the same thing as good design, and then a whole lot more about what good design for learnability is. Check it out.