Continuous Design and the NoPSD Movement
thoughtworks.github.io
thoughtworks.github.io
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."
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.
I'm certainly biased since I work there but the above is a fact :-)
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.
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?"
Yes, frequently! (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.
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.
Ok. Six words. I got it.
Building an argument often takes a little bit of context.
"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.
However it really wasn't that big of a deal. We just re-did the thing in HTML and re-used most of their graphics. Hardly worthy of a "The No* Movement" title.
The part about "you stop talking about it, you stop challenging it" resonates with me. But isn't that the job of whoever's responsible for the website? Can we really blame a file format for that?
Let's all try to be a little bit flexible and try to let everyone use the tools they prefer.
And it's not the fileformat it's the process that leads to delivery of the fileformat that is being challenged as far as I understand it.
The argument is not a dictate, it's an argument for why they choose not to do it and some of the problem they think arise when people do it in sofware development.
Isn't "the NoPSD Movement" basically referring to Photoshop?
The NoPSD movement is making a point against what 90% of what all designers use. PSD is just used a common reference point.
If we went about promoting a "NoPython Movement" in the context of computer programming I suspect that some people would get the idea that we didn't like Python very much.
Substitute 'XCF' and 'Gimp' in place of 'PSD' and 'Photoshop' and my point still makes sense.
So no your point does not stand. All you have done is shown that you either doesn't know anything about the design community or you deliberately don't want to understand what is meant.
I am guessing the last.
Again, my point was simply that in our development process, "asset pipeline", or whatever you want to call it, we ought to be a bit flexible to let professionals use the tools they feel they are most productive in.
Obviously, sometimes the workflow calls for HTML output. But if there's a brilliant designer in town who only knows how to generate EPS, PDF, or PSD (we've all met them) maybe it's not the end of the world if someone else does the HTML/CSS/Javascript.
The tools and the processes exist to serve the talent, not the other way around.
It's not about the result of the PSD files, it's about the result of the process of designing for something that isn't a final composition but rather an ongoing process.
It doesn't matter whether someone is a brilliant designer. What matters is that the de-facto way most work is creating friction that isn't necessary and is often counter-productive.
It's not argument against photoshop or psd, but rather a process philosophy if you like. And for something very specific namely app design.
> It doesn't matter whether someone is a brilliant designer.
Perhaps we can agree to disagree on that.
> What matters is that the de-facto way most work is creating friction that isn't necessary and is often counter-productive.
Maybe I've just heard this 'lessons learned from assembly-line manufacturing' applied to design and construction too many times.
Perhaps you shouldn't take a sentence out of it's context.
Maybe I've just heard this 'lessons learned from assembly-line manufacturing' applied to design and construction too many times.
What on earth does it have to do with what we are dicussing?
Design process: "it's about the result of the process of designing for something that isn't a final composition but rather an ongoing process."
Process standardization: "It doesn't matter whether someone is a brilliant designer. What matters is that the de-facto way most work is creating friction"
Process philosophy: "but rather a process philosophy if you like. And for something very specific namely app design"
Process optimization: "It's such a bloated process, full of wasted energy. It might work for selling billboards but it certainly doesn't work for building software."
To be clear I don't disagree with any of these statements. But they trigger my PTSD flashbacks of Deming and TQM.
Additionally, if this friction is such an up-front one-time event early in the life of a new product, how important is it really to software development? How often does your development shop experience this friction really?
The article is arguing against the entire business model and workflow of these agencies: ...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...When dealing with traditional creative agencies it’s a well known fact that designs will not go back once they are pronounced final because they are too expensive to re-engage.
What he's advocating for is a change in the contract terms for their creative industries. So phrasing the solution in terms of "NoPSD movement" makes for good blog, but even as a metaphor for asset workflow it just totally understates the fundamental-ness of what he's asking. It's as if we were going to reign in unrecognized cyclic dependencies on Wall Street in the from of credit-default swaps by advocating a "NoXLS movement".
Of course this is largely innocuous in the grand sceme of things. But the danger lies in Dilbert's manager thinking himself cutting-edge by decreeing "OK team, from this day forward nobody uses Photoshop".
It depends on the skillset, if you only have a designer they will probably end up with Photoshop and Illustrator comps, if you have a UX/UI person they can probably work faster and make a better/real-world comp in html5/css3 etc that is also truer to the medium. Everything looks so good in PSD/AI and then the conversion leads to problems, better to comp in the final format nowadays.
However, we always (always always) treat the PSD step not as Final Design, but as a high-fidelity communication tool - the next step after our wireframes (which are as un-designed as possible) and story cards. When requirements change, we loop back as far as necessary; for small changes, new stories and in-view UI adjustments suffice; for more fundamental changes we'll go back to the PSD.
Don't get me wrong - being able to maintain design quality in the face of change is one of the most difficult aspects of being a designer on an agile team (and getting design involved in the entire delivery process is absolutely essential) but the tool you use to build initial design isn't necessarily going to solve that challenge for you.
Personally I find it healthy to be able to concept layout & UI without making stylesheet & DOM structure assumptions. Designing via code, for me, blurs my focus - when I'm making decisions in Photoshop, I'm aware of the CSS that will be required to replicate it, but I'm not having to actively execute on them. Designing and coding take very different parts of the brain for me, if that makes any sense. Try drawing a picture while listening to a podcast vs. reading a book while listening to a podcast.
> “When it comes to products, user experience trumps pretty pictures. It’s not easy for most designers to do, because you have to rebel against everything you’ve been taught as a designer: fight the pretty pictures, fight the urge to tweak your drop shadows or find the perfect border-radius.”
This is more than a little patronizing. Delivering a polished, professional design and being flexible to changing requirements aren't mutually exclusive goals.
I suspect the reason that this hasn't happen is because HTML has always been an evolving standard. So while you can use your copy of Quark from ten years ago today, you wouldn't be advised to do that with a ten year old copy of Dreamweaver if you want to make an HTML5 site.
Another reason Photoshop comps exist is because of clients who can't comprehend the abstract. As someone who does IA I can tell you that time I've had many clients (who are very intelligent) who just can't go from the abstraction of quickly done wireframes that show navigation to what the final site will be. So until you have clients like that (and maybe they're a generation away) you'll need Photoshop to what that final site will look like. And I say that knowing that Photoshop is really a hack given what the sites can do.
Why couldn't you make an HTML5 site with a ten-year-old copy of Dreamweaver? Sure you won't get fancy stuff like code highlighting and suggestions but you could make a HTML5 site with notepad if one really wanted to.
I agree about the clients angle. Clients want to see the images of what the end of the project will look like. Until that changes, mockups will always be with us.
Sure, you could just use it as a text editor but at that point there are better editors you could choose.
Currently I'm loving Jade/Stylus to implement a fairly static website design, and that's just building it with a simple script (with Live.JS to preview changes).
Just to save some time, HTML+CSS+JS fuses, poorly:
1) page description / layout
2) appearance
3) interaction / animation
4) forms
5) content
6) metadata / markup
7) typography
8) vector art and raster images
You could probably throw in HTTP stuff, cookies, how much the DOM sucks, and multimedia too.
Sadly, bad as HTML is, there hasn't been anything better.
I would agree with you that over the years people have pushed features into HTML beyond what it was originally intended for, but that's not what's being discussed.
Contrast to Jade where I would just go: p some text
and let the indentation sort out the DOM structure. It's simple, readable, and doesn't overuse a set of keys placed more or less to be used infrequently (the <> brackets). All this translates to more productivity.
CSS is different problems, but it still stems from being overly verbose (too many vendor tags to worry about) and lacking useful functions, interators etc. Basically CSS sans a preprocessor is just slow and clumsy to work in.
A quick look at HAML and I fail to see how one is more or less verbose than the other. Of course, since I don't use it I suppose I'm not a valid source of comparison.
But to risk negativity, this sounds a great deal like the no semi-colons in Javascript thing a while back.
By the way - no semi-colons in javascript was a good idea aside from a few major factor - it broke things and it was a hack based on loose syntax handling. If it was built into the language design then it would have been a good thing.
What you propose is trivial to the machine, but not necessarily easier for the human.
By the simple fact that no semi-colons broke things and was a hack contradicts the thought that it was a good idea. Building it into the language might be a good idea but it wasn't to try to go around the language.
Also as a designer I find myself telling potential clients that they don't need a designer and should just go with a template or a logo from 99designs. For the longest time I hated doing this, but I realized that if someone wants to spend from $10 to $500 to do something that I wasn't the right person for the gig!
The problem is that you end up with bland designs that tend to conform to the whims of the technology rather than the type of creative elegance that a PSD affords. Because photoshop is removed from the tech, a designer in Photoshop can use their imagination a little bit and force pushing the boundaries of the technology in ways that a developer typically wouldn't. Even when you are a developer and aware of the tech, spinning the design in Photoshop (and even better, further abstracted down to pencil sketches etc) just always gives more creative and aesthetically pleasing results in my opinion.
I have been trying to get fellow creatives to make this switch, but it falls on dead ears, most of them cant write code and so they dont want to switch process's..
Which makes me wonder, if they cant write HTML at a minimum, why are they designing interactive?
Forget about trying to explain how a responsive site works and that, yes indeed, they need to design several versions of the same page as the layout will change as the media queries kick in. The main reason for doing so is to prevent surprises when they look at the site on their phones. But since they don't understand how it works they can't design for it anyway.
I've always felt, based on job interviews with prospective designers, that the schools train backwards. They start with design concepts and at some point they introduce web design almost as an afterthought that barely touches coding. If a student wants to be a web designer they should learn how to code HTML and CSS before getting heavy into design. That way they know what they're designing for.
Seems non-parody, normal enough to me. Although, I did not read it in context.
Thanks to you and unwind for the explanation.
It's summarized as "Spikes [...] are a special type of Story used to drive out risk and uncertainty in a user story or other project facet".
It seems they "drive out risk" by focusing on analysis and research, rather than implementing stuff. I think.
Actually, spikes (originally called "spike solutions") emphasize implementing as a form of research. You implement the risky thing so that you can learn how it really works in practice. You leave out all your normal production development practices and just focus on the question at hand, then throw it away (or archive it) when you're done.
For example, let's say you had a need to send email from your software, but you had never done that before. You might create a series of spike solutions that send a hardcoded email from your server and through a variety of third-party services, then evaluate the results. When you're done, you throw away (or archive) the spikes and rewrite it at production quality in your real codebase.
It's sort of like a prototype, but narrowly focused on a specific question.
deep as in "all the architectural layers and major technologies are in place and proven working". Wide as in "the system can do everything that the user needs"
Delivering PSDs is worse than useless, and the results of a skilled UX/IX designer working directly on the implementation are always better than either of us would have come up with alone.
I still keep Photoshop and Illustrator around to prototype look and feel or specific design elements that can't be more readily achieved with CSS. Colors and type can at times be faster to experiment with in one of those tools. But I haven't sliced a PSD in years (except when developing another designer's work).
The other benefit is that your design can be readily kept in source control, in branches if need be, and if you have a good process in place and are thoughtful in your markup conventions, can be swapped between almost seamlessly.
Firebug/CDT are great for quickly tweaking a design...I imagine (hope?) the next wave of web design software would be much like those, except with an easier way to edit markup, work directly on files and integrate with source control. I suppose you can get some analogous with a browser reload plugin hooked to your text editor or filesystem.
There is a few tools I would like to see developed to help this process, so I still need illustrator or fireworks (haven't used PSD for a long time after religiously using it for almost a decade) for a few things, especially when sketching concepts, but other than that it's easier and faster to script it.
Now if someone would develop a proper animation tool then that would get me excited. Something like how Flash was in the beginning. I know how to user after effects and can kind of get around Quarts, but they are both every cumbersome and not by default very well integrated into the design process.
I am not convinced about his particular way of doing animation though.
With that in mind, I always felt Photoshop was the wrong tool for the job, hence my preference of Fireworks over Photoshop. Moving to a fully code-based workflow would probably work better with some additional tooling in place.
I've been looking at Sketch and Edge Reflow. Any other suggestions?
It has its quirks and constantly being updated so don't always expect commercial-quality right away on new features.
Now that I use Compass/Sass, it's even faster.
I for one am rooting this movement goes forward, since I like most did suffer the PSD to HTML cycle overhead.
More than just making the design process much more conducive to iteration, you also have a designer doing the implementation. This is great, because it means that you no longer have to explain that a certain design treatment can't be done in code. Moreover, if there's a problem with the experience of using a certain element, the designer can change it on the fly with little overhead.
I like avoiding photoshop for web design, but I've usually only seemed it championed by webapp businesses so far, not so much at places oriented towards more 'brochure-ish' sites - like another commenter said, even younger folks who arent used to tech can't interpret a wireframe as design progress. Also, similar to wasting time on a PSD that doesn't make interactive sense, I've fallen into a personal trap when designing code-first to stare too much at different SASS frameworks.
Unless you're doing patterns like linen, cloth and leather crap. Which... I don't even like.
Getting real sick of the anti designers, simply because they can't design. Tired of all the new super easy flat UI's, and bootstraps. Put as much work into your design as you do the rest of your product.
I can't stand designing on the fly. A wireframe is fine, sure, but I prefer to lay things out at a basic level in Photoshop purely for dimensions. I know exactly where things are supposed to go, how spaced apart they are, etc. Then when I code it, I know whether I'm doing it right or wrong rather than fiddling with values to and fro and constantly judging whether X or Y is off.
Design assets.
Layout wireframe.
Code wireframe.
Import assets.
I think you illustrate one of the problems with the "PSD" approach. You seem to think about design in this medium as a composition. But IMHO it's only a composition the same way a game is a composition. I.e. always in flux.
And it's a mistake to claim that just because people do flat ui they don't put enough time into the design.
Deleted comment
PhotoShop is just fine for a lot of things including web-design and app-design.
To somehow think that you are doing something wrong if you successfully use a tool to solve something it was not intended to do... well I don't even know what to say to such a claim.
Try and run a design business that way and see how long you last.
I miss actual design on the web, something fitting to whatever theme or persona the website hopes to engage the user in.
I appreciate pixel-pushing as much as anyone else, but I also have been in the design world long enough to see that for most startups it isn't and shouldn't be their first priority. Especially since most of them are going out of business in less than a year.
I always try to look at refined design as a way to optimize a product. Of course some basics are needed, but that's why we have design patterns.
Deleted comment
Talk about not wanting to understand what is being said.
Of course it isn't high up on priority, but it is a task that should be taken seriously and completed eventually. Right now, it's usually an after thought which to me looks like neglect.
[Edit: but if it works for you, great]