Who really designs websites?
Hi I’m Justine, I’m the new Web Designer at Code Enigma, I feel its best to introduce myself before I get into this post because it might help you see where I’m coming from.
I did New Media at University, mostly because my art teacher pointed out all my work had some kind of typography in it. I went to a University open day where the Graphic Design course looked a bit pants and the other course they were offering was recently renamed from New Typography to New Media… so I took it as a sign and went with it. Since then I’ve been a graphic designer making massive books, leaflets, signs, and the odd website which is what took me to Drupal. I then got a job as a frontend Drupal developer, turning flat designs into real life websites… and shortly after HTML designs, thankfully. And for the past three months I’ve been here at Code Enigma working on designing a wide range of sites.
Fast forward to today
I went to Antwerp, the home of Drupal, for Drupalcamp Belgium. I was absolutely honoured to be asked to give a talk on Basic Design Principles. Which you can read about here, but this blog post is about a question at the end of the talk.
The very first question was from a frontend developer who came to my talk just to ask this question.
Why do designers not consider longer headings and test real content in their designs?
Sometimes she gets designs from a designer where they’ve failed to test for long titles/names etc. She wanted to know why designers do it?
I’ve been there, I’ve had the same frustrations and I feel there’s not one single answer to that question, there could be a number of reasons as to why things like longer headings haven’t been tested. I thought I’d write about my thoughts on why this so frequently happens.
The designer doesn’t understand testing
Firstly maybe your designer doesn’t understand that designing with real content is best. Maybe they came from a time where Lorem Ipsum is fine and they usually make a design, get paid and leave. That doesn’t seem likely but if that’s the case point them to the oodles of research that says content comes first. Content is the key to your website, it’s the reason why people go there, it’s the solution to their problems.
https://alistapart.com/blog/post/content-first-design
http://uxmyths.com/post/718187422/myth-you-dont-need-the-content-to-design-a-website
Component Driven Design
Now I’m all for this but I think there’s one problem with how many people are doing it. The whole point of these design systems is that you design small parts of the website and not the whole page. I’m all for keeping things simple and not reinventing the wheel where necessary and that is what these systems are great for. You can clearly see what bits you have to make up your website, if nothing fits your needs, you make another.
But I feel that working from a wireframe/basic approach upwards means that real content is forgotten, you can’t see the wood for the trees with this approach, you’re not solving the problem of getting the content to the user if you’re not designing with content from the onset. Faker is great at providing different text lengths but we’ve removed the content first aspect from the design workflow. At Code Enigma, we’ve created a tool to try and resolve this, we’re still in the testing phase right now but we hope it’s something we’ll be able to release soon.
Not enough time
It’s possible that after solving the mound of overarching problems the client threw at them that there was just not time left in the budget to look at these things. I assume that if you ask any designer if they are 100% happy their work is finished how they wanted it to be they’d say no. There’s always something more to do, test, fix, tweak, re-do, try, test again.
And now that designers are working in HTML some of them might be working a little slower because they’re working with newer tools. Again the “Should designers code?” Question has been asked/answered millions of times, on Medium alone… so I’m not going to go there but I think lack of time is a valid consideration.
The real problem…
I feel that Designers are not the end of the design process.
In most cases the rest of the team believe that the designs don’t have anything to do with them. They’ve been signed off, what they see on the prototypes/PSDs/component libraries is final and shouldn’t be changed. They feel they’re job is to copy exactly what they see into a website that fits a whole load of specification they’ve been given and if it looks different then they haven’t done their job right.
I feel this mindset is wrong and it happens because the process is wrong. The design of a website should be a multi-discipline approach. The conversation with the designer shouldn’t be over when the development phase starts. The design at that point is the look and feel of the product/company combined with the findings of the UX research. The big problems are solved but not necessarily the ‘smaller’* ones. Remember websites are ‘living’ documents, things change, and like with children, they change quickly when young. The development team should be able to question why something has been done that way or be able push back on multiple instances of the same type of information.
- I’d love to be here saying that accessibility and user experience are actually the top priority, but when coming to a new project, understanding a clients problems as well as the users, their content, their goals etc and turning that into a new website is a big job and they are the first and most important tasks to be able to provide a great user experience.
Most people make the mistake of thinking design is what it looks like. People think it’s this veneer — that the designers are handed this box and told, “Make it look good!” That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.
— STEVE JOBS
I’ve had this type of conversation with designers several times in my role as a frontend developer:
Me: “Why does this event teaser have an image with a different aspect ratio to the blog teasers? Did you want them to work differently or could we just use one of these styles to save making so many image styles that are hard to maintain“
Designer: “Oh yeah sure, go for blog one, its got a better aspect ratio for the profile images — but could you ensure that the image doesn’t show on mobile for events please? I don’t want the blog image to crop too much either”
Woo! Instantly I don’t have to make another image style, can probably remove a whole load of CSS and I’ve learned something I didn’t pick up from the designs, that original images should be resized then cropped…
In an ideal world these things would be documented, but we’re only human, and we’ve got deadlines, things get missed. Constantly talking to each other is key! Not being afraid to push back and tell the designer that this bit of code is hard to change for the design or questioning why something is like it is a good thing. Most of the time I imagine the designer will be open to changing the design to fit the code but even if it’s a vital bit of design you’ll be able to understand their reasoning for it and probably come to some compromise to ensure a better site for the end user.
We’ve all got a part to play in designing a website, regardless of our job titles, the buck doesn’t stop with the designer.
Ask questions, give feedback!
