3 ms·

Should you design your entire app before you start coding? You can, but that doesn't work very well. Part of the whole agile and test-driven development moveme

Should you design your entire app before you start coding? 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-enough-design.html http://bradapp.blogspot.com/2009/07/jedi-programming-just-en... http://www.featuredrivendevelopment.com/node/507 http://www.featuredrivendevelopment.com/node/507

alabut 17y ago
You can, but that doesn't work very well. 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.
- StrawberryFrog 17y ago
  The problem seems to be that "design" means two different things here - #1 User experience and graphic design, and #2 program architecture. I was talking mostly about #2. 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.
  - alabut 17y ago
    Agreed that we agree - I limited the discussion to #1 because that's how the blog post described it. #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.
    - StrawberryFrog 17y ago
      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" 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".

alabut 17y ago

You can, but that doesn't work very well. 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.

StrawberryFrog 17y ago
The problem seems to be that "design" means two different things here - #1 User experience and graphic design, and #2 program architecture. I was talking mostly about #2. 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.
- alabut 17y ago
  Agreed that we agree - I limited the discussion to #1 because that's how the blog post described it. #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.
  - StrawberryFrog 17y ago
    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" 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".