Design first, then code.
emilhajric.wordpress.com
emilhajric.wordpress.com
Most programmers aren't. And it's often a tug-of-war between designers and programmers to gain respect for their roles: have a designer always come later in the process and you'll get more of a limited traditional visual designer; have one always come earlier in the process and hand down visual specs like they're stone tablets, now you've got old school art directors from the Mad Men era and programmers are treated like code monkeys (still mostly the case at ad agencies today, actually); have one on your team that can design upfront while doing usability testing to validate features, all on a tight schedule, now you're talking about today's interaction designers, but they don't come cheap and most startups have a hard time landing one.
Moral of the story: Always have a design up front. I didn't have a design so the structure of my code was incorrect for the "visual" the other person had in mind, so it broke. If that visual is solid, especially when working with/for another person, then fewer mistakes will be made down the road.
You can, but that doesn't work very well. Part of the whole agile and test-driven development movement is a rejection of that "waterfall" / "Big Design Upfront" approach after seeing how it fails in the real world. Slogans like "do the simplest thing that could possibly work" and "You aren't going to need it" are there to stop you doing too much design.
Should you do design?
Of course. Slogans like "red, green, refactor" and "Don't repeat yourself" are there to get you to think about program design as you code. Also doing a bit of design thought before each coding task is good.
See also JEDI Programming - Just Enough Design Initially
http://bradapp.blogspot.com/2009/07/jedi-programming-just-en...
Sure it does, just along a different metric - visual cohesiveness. It's a big difference between design and programming - you can and probably should slice off pieces of functionality to implement but doing that with design leads to one of the biggest criticisms of designers within an agile/xp/scrum programming setup: a frankenstein-looking interface.
There's a reason why "agile design" and "agile ux" is gaining steam as topics amongst designers (especially startup-focused ones like me) and it's because yes designing everything upfront is old school waterfall and clearly bad but designing on the go with super fast iterations can lead to an ill-considered spray-and-pray approach to the visuals. So we're trying to figure out a middle ground where the designer isn't just following behind and applying polish. That diminishes a designer's role just as much as it does to make a programmer always come later in the process and treat them like someone that simply implements what the designers make.
I'm not advocating an approach, just pointing out that there's definitely positives to having design go first, especially if you do user-focused research like running usability tests on mockups or paper prototypes. It'd be great if you could flip flop back and forth from having design or engineering drive the discussion and that's exactly the setup promoted in Bill Buxton's Sketching The User Experience.
I agree that if you want a slick-looking app, you have to put some upfront thought into #1 - maybe not nail down where every pixel goes, but establish the metaphors, colour schemes, mock up some sample screens and so on.
#2 is important as well, but honestly, I find that worrying too much about #2 upfront makes it too easy for coders to go down blind alleys and turn into "architecture astronauts" as Spolsky would say because they're busy implementing what's technically interesting rather than pure minimum needed to make an interface work. And don't get me wrong, that's just as much a danger for designers to go off into visual polish mode and get the interface looking like lickable candy rather than making the bare minimum interface they need to test with real users, whether with usability testing or metrics or what have you. I'm definitely an advocate for both designers and programmers to implement the smallest possible feature set they need to test their app or site in the real world.
Speaking of which, I'm not sure the original blog author limited the scope of their app either - they didn't explain how they define "success". I think it might just be that the interface actually got made and photoshop files got sliced up into html/css? That's a pretty low bar if that's the case.
I am still agreeing, and that's about where I came in. The words "Design first, then code" are fighting talk to an agile software guy. But if you add "but I meant graphic design not software design" I would say "oh... that's all right then, I guess".
When I did the Nasdaq Market Replay app, we sketched out some of the vital areas of the application, then tested to see whether they where viable, in the meantime we went on to do the rest of the design and getting feedback from the developers to see whether what we wanted was possible.
My personal philosophy is to design in the environment that we are developing in as early as possible.
That way we don't have this blind tag team situation where designers mindfuck and developers has to solve their mindfucks because the client approved them.
The agile process requires that all the involved are contributing all the time.
Maybe the reason that he succeeded the second time around was that he had already tried and failed, and so knew where the pitfalls were. It's not proven that design on it's own, without trying out some ideas first, is going to help. Many people would say that it' doesn't. I'd say that big upfront design without any reality checks can be a major hindrance later on when it turns out to be impractical.
Also "designing the entire User interface" ? Is he talking about graphic design or program architecture?
I have to agree with the article up to a certain point though: creating mockups helps me find out what I need to build. Of course, creating a graphic design is something entirely different.
Yeah, it looks like it. So the article is poorly titled and poorly worded in that respect.
You can design all you want, but you aren't going to take into account every last interaction. You can only do this by reacting to a prototype or implementation. Do some design, then some code, then react to the running system.
The important bit is to get to the minimal running system so that you can react to it.
This will also help you achieve conceptual integrity in your design; the missing stuff that you never thought of will come to you.
see: http://gettingreal.37signals.com/ch09_Interface_First.php
With one-time projects I've meant products like a micro-page that a customer wants for some ad-campaign an then after some weeks have passed nobody will ever visit again.
But I agree, anything more than that is destined to be modified one day.
You're always going to design before you code, even if you just take ten seconds before starting to type your tests into the IDE.
The question is "how much design is too much?"
The reason we have to ask that question is that for some folks design is supposed to eliminate all uncertainty and control execution. When design is taken to this extreme, bad things happen. But bad things happen when no forethought is put into work as well.
High-performing teams use design as a way of getting common understanding about a general plan of attack on the problem domain -- which can include things like initial data models. But the general idea is to do simple, easy things repetitively. So whatever you do for design, make it something that's easy enough to do every sprint. Perhaps that means an hour or two at the beginning of each sprint -- perhaps a day or two. But thinking ahead and getting group buy-in is always a good idea when there's more than just one of you. Heck, it's a good idea even when there's only one of you. Good design can try out and throw away ideas really quickly. Designing from code is a lot more painful.