iQ Talk: Continuous Design Part I – When designers met developers

Last week, this article from ThoughtWorks on Continuous Design went around the office. You should read it. We did. It’s full of rallying calls:

“There needs to be a revolution in the marketing world…It might work for selling billboards but it certainly doesn’t work for building software.”

“Designs will not go back once they are pronounced final because they are too expensive to re-engage.”

“By working with an embedded designer in your project you’ll find you will have a comparable dollar cost and a much better design because they will be in the development team and do only what is needed.”

That same week, a client sent us a brief with an image in the last slide of the deck saying, “No PSDs”.

In this brave new world of responsive design and multiple screen sizes, is there any use for static images as part of the web design process? Is it finally the time for the industry to move to a Continuous Design process? Are we seeing the rise of the No PSD movement?

We locked a few iQ designers, an analyst and a coder into a room to discuss.

‘Continuous Design’ is a fairly new term. What does it mean to you?

David Donohoe: The standard web workflow breaks a problem up into discrete stages  – first UX, then visual design, then development – when essentially you’re trying to answer one question. Continuous Design means not being so fragmented in the way you solve a design problem. It’s about being involved as designers in the whole process.

It’s irrelevant to a client if the page is in a wireframe or a PSD. What the client wants to know is: “What will the experience be like?”

Owen Derby: Exactly. Our design work adapts to the product during development. We’re not dealing in the realm of static PSDs or JPEGS anymore.

It’s not about deleting UX designers or developers from the process. It’s about figuring out how those experts become more closely meshed together. You want everybody looking down the same tunnel towards the end goal. Continuous Design removes the fences from the workflow.

When you think about what’s going on with the responsive web, are flat JPEGs starting to make less sense as deliverables?

DD: It’s an incredibly wasteful activity. Consider the amount of time we spend on what is essentially visual documentation. These flat designs are just illustrations of how the page will behave.

Patrick Cusack: There’s a tension between designing for fluid, responsive web and using a tool that produces static images. Photoshop was more relevant when a fixed width website was standard, but with responsive layouts now becoming the standard, that’s no longer the case.

Laurence Veale: It makes complete sense, of course, and it’s an idea that’s been around a while. For me, what it’s ultimately about is how we can evaluate multiple ideas relatively rapidly and throw out the bad ones. Telling people about something, via a static image and getting them to try it out are two very different experiences, and the closer you can get to an interaction, even if it’s the wrong one, the better you can evaluate it against some alternatives.

DD: Today, we’re also designing for more complex interactions with multiple states. And all you have as a client are 12 JPEGs to “imagine” what the interaction is like. We need to be able to create those interactions on the fly. That would be pretty good.

So this move towards a “No PSD” world is a positive development?

DD: I think it is. As web designers we have all been learning as we go because it’s a medium that’s always evolving. Up until recently, we’ve been making do with the tools we have. I think what’s happening now is that we’ve got the technology, and enough lessons learned, to find a better way of working.

Conor Luddy: I don’t think there’s a choice in the matter – with so many different devices and screen sizes it’s just going to have to happen.

LV: With a live, interactive demo, you can instantly understand how it’s meant to work and feel, in a way that words or static images will never be able to achieve. That said, I wouldn’t go surrendering your PS licence just yet. PhotoShop is just a tool, and what’s good for one thing is bad for something else.

So what are the pitfalls?

OD: For practitioners, I don’t see any.

Where you might see resistance is from some agency owners, because you can charge more for building out separate stages. With Continuous Design, suddenly you have a whole line item gone from your purchase order.

But I think the clever people in the room are going to be looking at this and think, “we can work faster and deliver a better result at the end of it”.

Nickel and diming people for stuff that’s not needed is going to become something of the past.

How do you think Continuous Design will impact on the client relationship?

OD Hopefully it makes the iterative process much easier. And clients will feel more engaged in the process. Now, if you’re working with 30 static pages and a client changes a font you’ve got to send 30 updated JPEGs to the client.

I mean that there is something ridiculous about having to write the constituent code for basic building blocks. The parallel I draw is, as a print designer in Quark or InDesign you are dealing with picture boxes and text frames, and their relative positions on a page.

Each time you go to design a page, you don’t have to write the code behind each picture box or text frame, the application does it for you. Up till now WYSIWYG editors have mostly failed at replicating this process for web. On the face of it, the emerging batch of tools seem to have sorted this.

DD:  And there’s still a perceptual difference between interacting with something and looking at static representations of how it should work. That’s why clients are often slow to sign off on static JPEGs. With working prototypes, you’ll get sign-off quicker and have a less frustrating relationship on both ends.

PC: I think it comes down to, do you want to send a client a picture of a website, or a website?

LV: Well, it should have a positive impact, but mindfulness is required here. This process is a lot less risky, but it may not feel that way. Where a client might feel comfort in “seeing” every screen before sign-off, we need to bring them along with us.

OD: Ultimately, a client will be more confident when he knows the final result is going to look like the design he’s seeing in a browser. That’s a really good proposition for clients and one way to sell the approach to them.

We picked up this discussion in Continuous Design Part II,  looking at some of the new graphics tools that make Continuous Design possible.

And answering the big question: is this the end of PhotoShop? Read on

What do you think? Let us know in the comments.

3 Comments

  1. Interesting stuff.

    Not sure the tools are there just yet, although I can see something like the wonderful Macaw making this much easier. I guess it depends on the product. For example, continuous design is great for websites because the tech has matured, but much harder to do for apps with ground breaking UI or software.

    It might also discourage innovation. One of the strengths of continuous design is making us think of the constraints up front. Constraints are important but too much focus on constraints not so much. I fear an over use of existing UI patterns.

    Dave

  2. Yep I think it’s going to depend on the tools alright. It seems inevitable that web design will head that way if/when the products are up to scratch.

  3. Where I’m working continuous design seems to be what people expect. There’s little respect for traditional design techniques or tools, it’s just “What’s it look like? How’s it work?”. Adobe have responded excellently to the challenge with ReFlow and Muse. Muse creates clickable prototypes to a high-fidelity and quickly. ReFlow is a bit more clunky but is a responsive design tool. Both excellent.

    The one thing I notice is that the output tends to reflect the tool. – if you use a predominantly vector based tool, you get a certain style, so I’d still go for Photoshop for image-led retail sites, but definitely not for apps.

    Looking forward to next week!

    Also try Axure. It looks like Balsamiq, but it’s a great way of mocking up user-flows.