5 ms·

Wow, that is a lot of text to describe--I think--a process most of us non-designer types who have to do nominal design at times have used for years without assi

by bhauer 13y ago

Wow, that is a lot of text to describe--I think--a process most of us non-designer types who have to do nominal design at times have used for years without assigning it a name. Namely, we tweak CSS (and markup as needed) until the page looks good. We don't have an image-editing tool, nor do we want to invest the time necessary to learn how to use one. By comparison, we know what the CSS rules do. So we just design using CSS. It's obvious that even some who call themselves "designers" would use the same process now that CSS3 gives us so many graphic effects. Calling this Continuous Design or NoPSD speaks more to a somewhat irksome need to brand everything than it does to a new "movement."

threeseed 13y ago
This is Thoughtworks we are talking about. They make money from "consulting" on agile projects. Which means every ridiculous slogan they come up with is another way for them to paint companies as being stuck in the past and in need of some Thoughtworks magic.
- ABS 13y ago
  correction: Thoughtworks makes the majority of their money by delivering software for their clients. Not a small difference. I'm certainly biased since I work there but the above is a fact :-)
  - malandrew 13y ago
    I'm also the first person to jump on the "ridicule corporate sloganisms" bandwagon (and I'll jump on this one too since it's pretty absurd), but TW, unlike most consultancies I've had the (dis)pleasure to work with is actually really good at delivering software projects to clients. In a world where most corporate software projects are a complete failure, TW would be one of the few companies that knows how to deal with difficult ass-backwards clients and still deliver software that does was the client wanted it to do (instead of what they asked for). FWIW, I've never worked there, but I have worked for a company that has hired them and I've worked with numerous TW employees after they've left Thoughtworks to pursue other career paths.
robertnealan 13y ago
I've often just seen it referred to as "designing in the browser." Simple enough I'd think. Unfortunately any designing that's dealt with clients knows it's much easier to convince them of something they weren't previously aware of when it comes off as some new movement/idea/trend/etc. It's why Apple brands everything they introduce to their products, even if it's a technology thats been around for years. Telling client, "I know most designers do PSD mockups first, but I just design in the browser instead," likely wouldn't go over very well as they feel they're getting less than they otherwise would, even if the missing part is wasted time. I personally havn't come across a client that'd go for pure designing in the browser (yet). Instead I've generally just encouraged a hybrid approach where the final PSD's are subject to changes and subtle tweaks once in development so that the PSD's can be seen as a rough draft and not necessarily a pixel perfect execution. My most recent client was skeptical, but I think I managed to sell it with something like: "Does a painter paint a painting of his painting before he paints it?"
- gilrain 13y ago
  > "Does a painter paint a painting of his painting before he paints it?" Yes, frequently! (http://en.wikipedia.org/wiki/Study_%28art%29 http://en.wikipedia.org/wiki/Study_%28art%29) I'm also trying to push designing in the browser, and it's how I do all my personal projects. Just pointing out you may get a retort from a client if you keep using that example.
- blindhippo 13y ago
  I suspect most clients will never be comfortable with "designing in the browser" for exactly the reasons you state. It does come across as amateur. There is another reason this wouldn't work for most projects. Many, many projects are not just web based. They are part of an overall campaign that includes assets for all different types of media, especially print. Designers have to create assets for all potential media in the campaign, designing in the browser would be duplicating work. However, if all you're concerned with is a pump and dump web product, then this approach may have merit.
  - redblacktree 13y ago
DanielBMarkham 13y ago
This article is way too overblown for the simple concept they're trying to get across, which is something like "stop doing big UX up front!" Ok. Six words. I got it.
- ThomPete 13y ago
  Which would require that you already got it of course :) Building an argument often takes a little bit of context.
  - Jare 13y ago
    But the article doesn't really build an argument, more like paints the alternative as "the old and bad and non-agile way". Which may be true, but it's not an argument.
    - ThomPete 13y ago
      I think this is a pretty strong argument: "There is a legacy process that sits behind the design methods we apply to software creation; most of it comes from traditional marketing and design. It's an approach that's worked for creative agencies: magazines, TV advertisements, advertising campaigns – all these things are planned meticulously up front. In some cases, it's necessary – after all, it's harder to change an advertisement that's aired, or a magazine that's been printed then it is to change software. Most software design is still outsourced to firms who are traditionally marketing 'creative' companies. They're expensive, they'll deliver you a pixel-perfect layout of your entire application, and they'll charge you for it. It's what they know. "But it's all just documentation, really." says Andrew, "Comps, mockups, pitches, they're just requirements: visual documentation." What's worse is that we freeze this documentation as The Final Design, a canonical reference. Once that happens you stop talking about it, you stop challenging it or even being aware it needs adaptation. Worse still, there's a tendency to fall back to what you consider absolute, and the design starts driving the product. He sums it up: the accepted practice is not to redesign. Even some of the most successful Agile delivery teams are doing design the old fashioned way. Segmenting the design off as something that has to be done first. Only then do we shift into a happy Agile land. Wherein when we get feedback, we change and pivot on our product. We need to pivot our design, too. When everything is designed up front, and we change – then the vestigial parts of the design become waste. We must be leaner." Having founded and run a design and dev agency myself I was made painfully aware of this issue.
SkyMarshal 13y ago
Agreed, here's a much better article from 2009 advocating the same thing, and with a code walkthrough even: http://24ways.org/2009/make-your-mockup-in-markup/ http://24ways.org/2009/make-your-mockup-in-markup/

by bhauer 13y ago

threeseed 13y ago

This is Thoughtworks we are talking about. They make money from "consulting" on agile projects. Which means every ridiculous slogan they come up with is another way for them to paint companies as being stuck in the past and in need of some Thoughtworks magic.

ABS 13y ago
correction: Thoughtworks makes the majority of their money by delivering software for their clients. Not a small difference. I'm certainly biased since I work there but the above is a fact :-)
- malandrew 13y ago
  I'm also the first person to jump on the "ridicule corporate sloganisms" bandwagon (and I'll jump on this one too since it's pretty absurd), but TW, unlike most consultancies I've had the (dis)pleasure to work with is actually really good at delivering software projects to clients. In a world where most corporate software projects are a complete failure, TW would be one of the few companies that knows how to deal with difficult ass-backwards clients and still deliver software that does was the client wanted it to do (instead of what they asked for). FWIW, I've never worked there, but I have worked for a company that has hired them and I've worked with numerous TW employees after they've left Thoughtworks to pursue other career paths.

robertnealan 13y ago

I've often just seen it referred to as "designing in the browser." Simple enough I'd think. Unfortunately any designing that's dealt with clients knows it's much easier to convince them of something they weren't previously aware of when it comes off as some new movement/idea/trend/etc. It's why Apple brands everything they introduce to their products, even if it's a technology thats been around for years. Telling client, "I know most designers do PSD mockups first, but I just design in the browser instead," likely wouldn't go over very well as they feel they're getting less than they otherwise would, even if the missing part is wasted time. I personally havn't come across a client that'd go for pure designing in the browser (yet). Instead I've generally just encouraged a hybrid approach where the final PSD's are subject to changes and subtle tweaks once in development so that the PSD's can be seen as a rough draft and not necessarily a pixel perfect execution. My most recent client was skeptical, but I think I managed to sell it with something like: "Does a painter paint a painting of his painting before he paints it?"

gilrain 13y ago
> "Does a painter paint a painting of his painting before he paints it?" Yes, frequently! (http://en.wikipedia.org/wiki/Study_%28art%29 http://en.wikipedia.org/wiki/Study_%28art%29) I'm also trying to push designing in the browser, and it's how I do all my personal projects. Just pointing out you may get a retort from a client if you keep using that example.
blindhippo 13y ago
I suspect most clients will never be comfortable with "designing in the browser" for exactly the reasons you state. It does come across as amateur. There is another reason this wouldn't work for most projects. Many, many projects are not just web based. They are part of an overall campaign that includes assets for all different types of media, especially print. Designers have to create assets for all potential media in the campaign, designing in the browser would be duplicating work. However, if all you're concerned with is a pump and dump web product, then this approach may have merit.
- redblacktree 13y ago

DanielBMarkham 13y ago

This article is way too overblown for the simple concept they're trying to get across, which is something like "stop doing big UX up front!" Ok. Six words. I got it.

ThomPete 13y ago
Which would require that you already got it of course :) Building an argument often takes a little bit of context.
- Jare 13y ago
  But the article doesn't really build an argument, more like paints the alternative as "the old and bad and non-agile way". Which may be true, but it's not an argument.
  - ThomPete 13y ago
    I think this is a pretty strong argument: "There is a legacy process that sits behind the design methods we apply to software creation; most of it comes from traditional marketing and design. It's an approach that's worked for creative agencies: magazines, TV advertisements, advertising campaigns – all these things are planned meticulously up front. In some cases, it's necessary – after all, it's harder to change an advertisement that's aired, or a magazine that's been printed then it is to change software. Most software design is still outsourced to firms who are traditionally marketing 'creative' companies. They're expensive, they'll deliver you a pixel-perfect layout of your entire application, and they'll charge you for it. It's what they know. "But it's all just documentation, really." says Andrew, "Comps, mockups, pitches, they're just requirements: visual documentation." What's worse is that we freeze this documentation as The Final Design, a canonical reference. Once that happens you stop talking about it, you stop challenging it or even being aware it needs adaptation. Worse still, there's a tendency to fall back to what you consider absolute, and the design starts driving the product. He sums it up: the accepted practice is not to redesign. Even some of the most successful Agile delivery teams are doing design the old fashioned way. Segmenting the design off as something that has to be done first. Only then do we shift into a happy Agile land. Wherein when we get feedback, we change and pivot on our product. We need to pivot our design, too. When everything is designed up front, and we change – then the vestigial parts of the design become waste. We must be leaner." Having founded and run a design and dev agency myself I was made painfully aware of this issue.

SkyMarshal 13y ago

Agreed, here's a much better article from 2009 advocating the same thing, and with a code walkthrough even: http://24ways.org/2009/make-your-mockup-in-markup/ http://24ways.org/2009/make-your-mockup-in-markup/