I recently read an interesting post on medium.com entitled: It’s Time to Dump Photoshop and Embrace Sketch: The quest to find a lightweight, focused alternative to Photoshop for UI/UX designers. It was interesting as only that day that I had been venting on Twitter:
I mean, in the responsive web world is photoshop even useful for webdesign planning any more? It's a hindrance more than a help.
— JonWalmsley (@UXJon) November 19, 2013
However I think that the suggestion to move from Photoshop to Sketch for doing UI design is only kicking the can down the street and not dealing with it while it’s in-front of you.
That Medium post makes the classic web design mistake of coming up with a solution and then trying to tweak that solution when what you should be doing is looking at the main problem in the first place and deciding how to address that. This is known as the X-Y Problem – having decided that Y isn’t quite the solution to X you then look for other ways to do Y, when you should be looking at X itself and working from there.
So what is the problem?
In this situation the problem is twofold.
Photoshop isn’t a web design tool
The first issue has been discussed many times before: Using a design tool – in particular Photoshop – to create a web UI isn’t compatible with web design in the responsive and multiple-device web world we are now in. Photoshop is the main issue here. The clue is in the name; it is designed for editing photographs. It does other design stuff (possibly too much, as the Medium article points out) but it is still built for one purpose and being used for something else. The issue is still present with other tools to a greater or lesser extent.
The responsive web doesn’t exist in one fixed dimension so in order to accommodate the fluid nature of the web you’d need to create multiple Photoshop files. Once you start creating more than one design file that introduces a large overhead of maintenance and potential for contradictions and omissions. Sure, decent designers would be aware of this and are capable of managing this risk, but it exists none-the-less. You can’t design how a UI will look when you don’t know what it is going to be used on.
However, there is more to designing a web UI than having to consider various breakpoints, bringing me onto my second point.
A design tool is still a tool
A tool being an instrument to be used for actioning a specific task. This is the main problem with any design tool; it is a single entity for creating a design. What are these designs going to be used for? Will they be shown to various project stakeholders to see if they like it? Will they be used for slicing up and creating full front-end templates? Will they be used as conversation aids within the development team before build?
If it is any of these reasons then I believe this is the wrong use. The problem is that once you have a design then you have something to aim for. And this isn’t always ideal. You’re basically working backwards; starting with a design and then trying to achieve it. This is a problem because you can never reach that design as every device will display differently. Different sizes, different OS’s, different assistive technologies… You can’t aim for something that cannot exist.
What happens when you start building to these designs and find that the menu text doesn’t fit on a portrait Nexus 5? Well you have to go off-piste against the designs in order to accommodate that quirk, or make changes to the designs. Then you’ll find that IE8 adds in extra padding around assets that you weren’t expecting, so you have to either tweak the designs again or you have to tweak the code to get it to display as per the designs. And on you go, compromising your way to a finished product that may or may not match the intended goal the designs presented.
What is the alternative?
Perhaps a better option is to come at the design from the other end.
Don’t create a visual for you (or anyone) to aim at; define the problem and then build the whole solution together; Design, development, stakeholders, usability practitioners, Infrastructure teams… Everyone who has an involvement in the project. Your end goal should be to meet the project requirements, not to meet a pre-made design decision.
Creating a design using a design tool is a hangover from the over-the-wall mentality of web design. Don’t create a spec and throw it over-the-wall to the design team. Don’t create the designs and throw it over-the-wall to the stakeholders for approval. Don’t create something separately that has to be interpreted and converted into the final layout and design; build the layout, design and website itself with everybody involved. Call it Agile, Lean UX, whatever you like, but designing a website in Photoshop and trying to build it is something we should be trying to get away from as a whole concept, we shouldn’t just be searching for a Photoshop replacement.