I was actually questioning my current design process yesterday while mocking up a landing page in Fireworks. "Why not start the process in HTML using CSS3?" I thought. However, beyond basic layouts, I find it hard to programmatically mix and match colors, fonts during the creative process.
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?
I've been using Adobe Brackets for a while now, called Edge Code in Adobe's CC suite, and find it quite helpful in building out a page from scratch. It feeds your changes to a Chrome window in real-time with visual feedback so it's easy to play with fonts, colors, and other CSS-based stuff. Has a decent selection of user-created extensions as well.
It has its quirks and constantly being updated so don't always expect commercial-quality right away on new features.
Why not simply define the mood (or theme) of the site in FW - perhaps design some of the key elements. Once you're happy with that, you move into the browser and get to grips with the structure of your layout.
Though continuous design makes sense on paper, I am skeptical about the practicality of it. It was a big jump for developers to move to TDD & continuous delivery practices. I think unless a set of designer friendly tools and practices emerge, NoPSD requires a bigger cognitive "jump".
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.
The best designers I have worked with have been able to write textual documentation about what they want to achieve, doodle in whatever medium they prefer until they have visual concepts, and then work with me to turn those concepts into functionality.
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.
It's a good thought, but it's named wrong. Emphasis on 'psds vs not psds' makes it seem like it's about the tools, but it's not: it's about the process.
Most of the problems stated in the article can be solved by simply not outsourcing design and doing it in-house. After that, all you have to do is learn how to iterate quickly.
Designing for software products and designing for marketing/advertising are very different processes because they have very different needs. Software goes out and is updated as it lives and is used. Ad campaigns and branding materials very rarely are. I think the big thing here is that we have to recognize that, and not try to do all design in the same way.
This is similar to why NoSQL was a hard sell after the novelty wore off. People have uses for SQL and its alternatives. Similarly, NoPSD is a fantastic, catchy term but of course we'll still want PSDs for graphic work. The point of NoX movements isn't really "None" just "Much less" and as a shorthand of expressing a way to do things differently.
I havent touched photoshop for interactive design in 5+ years.. First I switched to Illustrator, because photoshop is for photography not graphics.. and then 2 years ago I switched to pure CSS/JS built on top of HTML. I will do nice sketches of wireframes/ideas and then dive straight into the code. It's much faster production time.
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?
I always found this interesting. For the designers that simply cannot write HTML code to reflect the desired design. What tools are they using to get the job done? Are they just taking existing templates and "hacking" it together?
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.
I've been designing and prototyping this way for a few years now.
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.
The animation software Bret Victor demos in his "Inventing on Principle" talk looks pretty cool [1]. I don't know of anywhere the software from the talk is available though.
One of the biggest problems with full design first (i.e., PSD, Fireworks, etc.) is that you don't really have content. How many of you here have experienced the, "I like that little side bar they have - let's do something like that.", or, "I really like how they have a menu here and a top on there." syndrome, followed by shoveling content into that side bar or stuffing random links into that top menu when the concept is actually coded, because content was an afterthought.
It's very exciting to see this being addressed in a formal way. The movement toward code-based design has been growing in strength since (I'd say) about 2010, and is now stronger than ever, thanks to Bootstrap, Foundation, et al.
The only way in the real world to kill to PSDs is to have an easy-to-use WYSIWYG web design tool which would allow designers (and the non-technical) to eliminate HTML production pros. This has existed for desktop publishing since the 80s when programs like PageMaker eliminated the need for designers to work with phototypesetters who entered everything by hand.
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.
We've had WYSIWYG web editors for years. It's just another tool for someone who doesn't know what they're doing to create something they don't understand how it works. This is fine for people who have a specific need but for others it is not a solution.
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.
Well, I was referring to the text editor and not the WYSIWYG editor since that'll likely create bloated code no matter how recent the version. I didn't dispute that there are better choices, it's just that it could be done if one wanted to.
There wasn't even one decent WYSIWG html editor ever. Either they keep close to html which is horrible because html model is pure crap from design perspective. Those editors end up being text editors that type some texts for you when you click the button. The other kind of html editors are just fancy wizards that allow you to generate some limited outcomes that are easy on the eyes but they severly lack versatility.
Raw HTML/CSS is god awful - especially HTML, which has to be about the most unfriendly possible syntax to type out on a keyboard.
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).
Then how do you inform the browser where a span ends when it is enclosed by text inside a div?
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.
A tag could be closed without repeating it's name. It's obvious from the DOM which tag is being closed. It's the job of code editors to help you out by matching start/close tags - not the job of the language.
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.
But closing a tag with its name makes it clear to the person writing the code what's being closed. Think of a div that contains, say, a hundred lines of HTML. There's a habit with some people to insert a comment at the closing div to identify which div is being closed by referring to its id.
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.
But you are clearly covering topics that XorNot did not mention. He specifically stated disliking the syntax and having to type it.
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.
Simply put: <p>some text</p> involves more awkward use of the right-side of my keyboard then there's any need for it to.
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.
Yes it's easy to learn the basics of HTML/CSS, but to do it really well (i.e. on a professional level) really requires an investment of time. From a financial point of view I'm not even sure that it's time well spent given that you can always outsource the work cheaply on the low end.
Spending time designing in photoshop and then "cheaply" "outsourcing" HTML and CSS development, aka your _actual_ website, is a terrible idea. There are people who implement designs well, and they are worthwhile to hire if you don't know browsers; they're certainly not cheap.
It depends on what you're doing. Yes if you're doing a large scale project that's mission critical you want a front end pro and wouldn't dream of going cheap. But on the other hand say you have to do a single simple landing page for a one time marketing campaign it would be silly to bring in the best.
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!
Depending on what I'm working on, I'll either skip photoshop almost completely, or I'll design almost every single thing in photoshop first. It's really up to the task at had. That said, I've started using Sketch for quick ui mockup work, and I'm really impressed. Granted, there's some serious performance issues they need to work out, but it's been pretty good so far.
Those large, fixed next and previous arrows are horrible. Does the author REALLY want me to consider skipping next or forward throughout the duration of the article? Probably not. Put the buttons at the bottom where they belong, similar to how Medium does it.
Does "spike out a mainframe in two weeks" mean anything? I assume it's meant to be a designer parody of developer talk, but it just seems an odd phrase.
Spike has specific meaning in agile terminology. Two weeks is more than I'd allocate to a spike, but needs vary and agile's biggest point is adaptability. "Mainframe" I assume refers to UI element and not Big Iron.
Seems non-parody, normal enough to me. Although, I did not read it in context.
This page: http://scaledagileframework.com/spikes/ talks about the "spike" term (which I had never heard, but I've not worked with Seriously Formal Agile folks, as far as I know).
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.
You don't have to be a "Seriously Formal Agile folk" for a "spike" to be a useful concept. It just means that for a certain feature, you admit that you really don't know how hard it is, so you give yourself some time to get a better sense of it, usually by doing a quick and dirty version of the feature that you may or may not end up using. I'm sure you've done the same thing for years without needing a word for it, but hey, it can be useful to label concepts.
> 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.
A "spike" in agile terminology is a prototype/proof of concept that is deep but not wide. i.e. no need to prototype all the UI screens, but do prototype a ui backed by a service persisting to a DB (for example).
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"
I do this. Or at least I started now. I only use Pixelmator for making icons and smaller images for in-app icons. But most of the time, I style using code on iOS. The CPU can take it these days.
Unless you're doing patterns like linen, cloth and leather crap. Which... I don't even like.
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."
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.
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.
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?"
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.
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.
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.
"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.
Who is saying people can't 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.
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.
The difference is that 90% af developers do not use python, 90% of designers do use photoshop.
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 do understand about the popularity of Photoshop. I know relatively little about "the design community" and am just a bit skeptical that it is as monlithic as some folks make it out to be.
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.
I don't think you got are getting the point they are making though.
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.
I get it: using bitmap files for an app introduces a big ugly manual process step and so using them as a static master for an app design discourages iteration and evolution.
> 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.
Phrases that make me think of assembly-line software construction:
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".
What is wrong with designing in Photoshop? I use PSD's as sort of a visual playground to experiment with new styles and prototypes of website assets (buttons/navbars/other reusable assets).
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.
I can design, but I have to say that I do not believe the future belongs to PhotoShop.
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.
A business is very rarely build on design the way you and I probably think about good design.
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.
I like to treat all aspects of launching a product with equal perfectionism. I don't believe one aspect of launch should be shunned. Yes they may go down in a year, but working on a pristine design doesn't take that much time and makes it that much better.
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.
Sorry but if there is one thing I have learned it is to not let the purpose of something dictate what I use to solve a customers problem.
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.
PSD and doing (visual) design upfront is analogous to bloated (not code, probably outdated by time it is done, disjoint to actual app/needs, not quick to change/adapt, etc.) specification and (non-visual) design upfront that is largely viewed (for many types of software development) to be a complete fail.
The biggest problem with this is the apparently large number of designers out there that design for the web but have no idea how web pages work. It's not just that they don't know HTML or CSS coding, but that they don't how it works in the browser. I've had numerous discussions with designers of why their pretty design is simply not workable on a web page, not including the fact of the rendering differences between browsers. They expect pixel perfect matching of the mockup and almost always fail to understand why this is incredibly difficult to do. Plus the fact it's a wasteful exercise to begin with. The visitors are not going to care that the last sentence in the third paragraph breaks differently between IE, Firefox, and the mockup.
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.
Designer here. The specific downsides addressed in the article, IMHO, can be a problem of process, not tools. On my projects (I work at Hashrocket, RoR shop) we put clients through an initial look & feel phase to nail down general palette & styles, and move forward with PSDs that are approved prior to HAML/SASS slicing and actual implementation.
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.
This design-in-markup concept has been around for a while (I like the new term "NoPSD" though). I tend to flip both ways on this issue. For expediency's sake, and often in terms of usability and performance, designing in CSS definitely wins out.
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 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.
I would like to find a version of this manifesto that might be a little more approachable for some traditionally minded design folks that I work with. I guess I'll just have to write it myself.
You would think someone with such strong opinions about Design would have bothered to actually Design their own site instead of being pretty blatantly "inspired" by Medium.com.
111 comments
[ 2.8 ms ] story [ 271 ms ] threadWith 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.
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.
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 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?
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.
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.
http://vimeo.com/36579366
I am not convinced about his particular way of doing animation though.
It's very exciting to see this being addressed in a formal way. The movement toward code-based design has been growing in strength since (I'd say) about 2010, and is now stronger than ever, thanks to Bootstrap, Foundation, et al.
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).
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.
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.
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!
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"
Unless you're doing patterns like linen, cloth and leather crap. Which... I don't even like.
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".
http://24ways.org/2009/make-your-mockup-in-markup/
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.
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.
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.
Talk about not wanting to understand what is being said.
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.
[Edit: but if it works for you, great]
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.
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.
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 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.