As someone who heads up a user experience team at a decent sized organization, I concur that PSD-driven development and design is dead. If a design isn't in code for people to use and feel, it's not done. It's just a start.

A design can start in Photoshop (or Sketch, more likely), but the iterative process of doing high-fidelity prototypes and getting feedback is how good design is done. We are also talking about interaction design here. It's not how it looks, but how it works and feels. That cannot be accurately modeled with a PSD file.

Our design process starts with hand-drawn sketches or paper prototyping and goes up from there in fidelity. You cannot work in an Agile environment with PSD-drive development.

My team has designers, developers, usability experts and people with a combo of these skills. No one is allowed to work in a silo.

We've been moving to high-fidelity prototypes from PSD-design, it's good.

The days before we moved to PSD-driven development, it was "We need a page with a list of X's, so the user can Y each. It should look sort of like the list of Z's on ABC.com. Build a prototype for next week"... one week of back and forth and a bunch of hacks later..."Ok, the prototype looks good, let's put this in production by Friday."

Bringing in a full time designer and bringing in PSD-driven development was very welcome relief. We still had a week and a Friday, and didn't need to allocate time for prototyping.

Interactive first has the same problem as design first.

I believe both design, interaction and logic could be done agile.

Simplified: The use must login. So we need a screen with a login method. What fields are needed? What should happen on interaction with the form elements? How should the form elements look?

The whole team of graphic, interaction and logic designers work together with the client to make this happen.

We are moving away from high fidelity prototypes to low-fi whiteboard sketches and prototyping in the actual application.

Occasionally we do pixel perfect prototypes with clickable simulated logic and all but we can't maintain it all, and we try to use it only when something is logically complex to reason about without pictures...

It's about as fast to do in the real code with mocked services when you have the application already there.

It requires more collaboration but that can only be a good thing.

I agree going without prototypes or PSD can be a fast way to grow - that's how our company built it's initial MVPs and became profitable in the first place. The PSD's and pixel perfect prototypes come in handy when the non-engineering parts of the company are so intimate with customer's wants, they are very precise about the requirements (especially to fit in an existing market).

Hmm so, it looks to me precise prototypes are good for precise requirements, while vague requirements are better when engineering is also customer development, and customer requirements are not known precisely yet.

In our company we have 1.5 designers and 5 in engineering and we're good with maintaining the prototypes. The designers have to do other non-digital stuff like print media too...Maybe our web applications are mostly CRUD's with permissions so it's easy to maintain?

Aha.

We have 6 teams with full stack developers and testers, sharing a (too) small group of UX experts. Each group have a product owner focusing on a specific area, but there is a lot of overlap.

But the general idea is to avoid big upfront design and instead try and retry the design.

PSD driven development is insane, but way worse is "not my job" driven development.

As stated in the article, their is a lot of task that no one want to do; like determining goals, slicing png, animations, transitions between views...

When you get a PSD with no hover, no "view when no data", no sense of navigation, no specifications whatsoever.... You know your project will be tough and made of thousand of meetings.

Communication helps, good software helps, being agile does help too. But company does not value well how costly it is to be that much "agile".

Yep, lately more and more, I think the root problem is that actually creating high-quality software is so expensive that few can afford to do it, but they need software anyway.

I think it's actually a big societal problem, not just a contractor-client-relations problem. Our lives are full of crappy software, and the economy probably literally could not bear the cost to fill them with high quality software instead. Software cost savings are a lie formed out of crappy software.

High-quality software isn't expensive - it has a high initial cost, but the difference between a successful product and a crappy product you can't sell and need to hire hundreds of people to bugfix is more than enough to cover this.

Some people tend to want cheap. They don't see what software developers, testers, UX guys and so on bring to the party. Unfortunately they don't really have a choice - they pay now or pay later.

Yes, but you are forgeting a very important decision, usually how these things go, the person doing the decision for now and the person doing the decision later aren't the same one.

So companies keep doing this, because whoever does the "cheap" decision gets his/her bonus for reaching the target and moves on.

High quality, mostly-custom software is expensive.

That's why I thinking bringing everyone as close together produces the best results. Yes, the designer wants X, but is Y acceptable if it's doable in a tenth of the time?

Start focusing on "What's best for the team / product?" rather than only on {whatever hat the asker is wearing}.

It's expensive as f*ck I'd say, but you are right.

You pay now or you pay later for a worse result.

High-quality software is a documented way to reduce costs. The evidence is filling books, while there is none that shows that low quality leads anywhere.

This problem is the bane of my existence as a css/html guy. However I don't believe the core problem is what you suggest. Forcing designers to just work within wireframes isn't going to work. Assets and wireframes is only a small part of what a designer does when creating a good user experience.

I think the solution is going to lie somewhere inbetween, with designers needing to expand their knowledge and working within tools that are based on how CSS and HTML actually function instead of a program that allows you to just place boxes wherever you want and hope its easy to code.

I've been following what these guys are doing over at BoxBox, they are onto something big I think. https://keminglabs.com/boxbox/

Ten years ago I had wonderful experiences with Qt Designer. You can build a UI that's an actual UI, you can run it, resize it, click the buttons and all the rest. And then that becomes the real UI - in development you connect up the buttons and the like to the business logic.

Maybe the web's finally catching up with that?

Yes, I think if the designer is going beyond wireframes, they should probably be doing CSS themselves. Ideally applying CSS to a live prototype that the 'programmer' developed based on the wireframe.

I don't know, I'm not sure what the solution is. But I'm pretty sure it's not PSD-driven development.

I assume when referring to PSD-driven development you mean to say the process of having a designer design a non-responsive, static mockup which is delivered the the front end dev team? I think this is important to clarify because a lot of people tout Sketch as being the answer despite it having the exact same pitfalls and issues Photoshop does.

https://keminglabs.com/boxbox/dynamic-layout-engine/

Check out this demonstration. I really think this is going to be the next big step forwards for designers. I don't think they need to fully understand CSS, the box model, flexbox, the dom, inheritance, etc to deliver effective designs. They just need to be forced to follow these limitations of these things within the design tool itself.

I think the idea is to make every change the designer makes reflect a nearly identical change that the frontend devs are going to have to also make. For example, text color inheritance is a notoriously hard thing for a designer to grasp. If that was handled automatically for them, they are going to out of necessity, create a more code friendly color inheritance hierachy in their designs.

Maybe a "web" designer really needs to know their medium.

A sculptor needs to know about clay and ovens, a clothes designer needs to know how to sew, the strengths and weaknesses of different fabrics and so on (even if Gaultier or Lagerfeld didn't do any sewing and stitching when they made it big, you bet they learned to when they were apprentice designers). Knowing your medium makes you aware of the limitations and possibilities and a better designer.

Why do we insist on coddling designers with tools like Photoshop? What's wrong with making them learn CSS and HTML?

All mobile graphics should be in vector form. There's no excuse for raster except photos. And if we are talking about vectors, it's easy to use them and everything's pixel-perfect.

Yeah easy. Unfortunately vector drawables are API21+ on Android. A large chunk of my users aren't on API21+. Google helpfully provides app compatibility with older versions by rasterizing to all possible dpi sizes during the gradle build process which makes your apk huge of course and defeats the purpose of vector drawables. So you probably want to try a third party library instead of vector drawables. The most popular one seems to be badaboom/androidsvg. It requires setup code on every imageview to load. So you probably want to use a custom view to make it easier and avoid repeating code everywhere. Of course then you use other libraries that aren't setup to use those custom views and your back to manually rasterizing in code. Easy!

Are you assuming that everything is flat?

You are assuming that vector design can't be 3D-ish.

The parent is refering to the fact that it's much easier to make a design work on more resolutions with vectors.

I am more pointing out that it is not so black and white, since designs can include images/bitmaps/patterns etc so just saying "svg it" doesn't really cut it.

But yeah, it is easier to make it work and it can be non-flat as well.