Web design vs. web development. What's the difference?
Let’s suppose that you have a business idea and at the heart of that idea is a web product; perhaps a website or web application. You have to admit you don’t have the knowledge, skills, and time to create such a tool so you’ve got to hire people who will do it with you. These people are web designers and web developers but what are the differences between them? Why do you need them both? Or maybe one of these roles would be enough? Let’s talk about their responsibilities, skills and areas of focus from my own perspective as a frontend developer at Boldare.
Table of contents
Dev team members
People who are working on your web product usually don’t have the same roles, positions, and skills. A dev team consists of designers, frontend and backend developers, and full stack designers or full stack developers in varying proportions. They work towards the same goal but focus on different areas in the building process. Let’s find out what those areas are.
Web designers
Designers are responsible for the interaction with the user. They focus on the mood and visual aspects of the product but also the user’s feelings and behavior while using it. Their first and most important task is to agree the target user persona for the product before creating anything; without this step the team won’t be able to do their job well. They can then focus on the target persona’s needs, rather than on their own guesswork. This is done closely with the client.
When the target persona is settled and agreed, designers start thinking about a moodboard, wireframes, user flow and information architecture. It’s highly recommended to do this with developers as well. It is a crucial stage of any product development cycle regardless of whether it is built using an agile methodology (Scrum, Kanban) or using traditional project management techniques.
It is at this point that developers and designers can brainstorm ideas and check if everything that was designed can be converted into clean, working and optimized code. In order to present their ideas, designers can use a couple of tools and visual guides.
Moodboards are collections of colors, fonts, sizes, shapes and other components that can define the mood and character of the final product.
Wireframes tell the client and the team how information will be arranged, how the pages will be structured (the layout). Wireframes, unlike moodboards, don’t contain any moods or feelings, they are usually black & white and can be done with just an ordinary pen and a sheet of paper.
User flow is strictly connected with information architecture. It is the series of steps a user takes to receive a desired result. When creating the architecture, designers think about the whole concept of the product, they divide information into different views (dashboard/landing page, settings, contact page and so on).
The user flow defines what the connections and transitions between these views should look like. This helps setting up the shortest way for the user to achieve their goal. It’s clearly visible how many steps the user needs to take when going from point A to point B.
One common output from web designers is a style guide. It can take the form of any type of document containing all the core app components, such as forms, inputs, buttons, backgrounds, navigation bars and many more. A style guide is normally just a collection of components and includes their dimensions, colors, margins, paddings as well as their different states - e.g. hover, focus, open/closed. A style guide serves as a bridge between designers and developers and can be quickly referenced by either side to solve common implementation problems.
When everything is ready, the designers can finally create the designs. These are views and flows where you actually see how the product will appear when finished. This result won’t be used in the final product in its current form (it hasn’t got any code inside) that’s why in every dev team we have developers whose job is to fill in the content and make everything interactive.
When I mention design, I’m talking about the user interface and user experience, UI and UX for short. These two roles are often carried out by the same person but the accountabilities are totally different. In a nutshell, we can say that the UI is the graphics and the UX manages the behavior of the product user - there are plenty of articles that explain the difference.
Designers are commonly people with a strong sense of aesthetics. Of course, design skills can be mastered without that, but show me a person who has mastered a skill without being fascinated by it. Design is a kind of art. It refers to a large extent to aesthetic feelings, unlike a developer’s work, which should primarily be functional and reliable. Everyone can be a designer but if somebody doesn’t feel it and doesn’t love it it can’t be mastered practically.
Before we look at developers’ accountabilities, we’ll deal with a few questions.
Do we need designers at all in the dev team? No… And yes! Theoretically you can build scalable web product without designers… but also theoretically you can build a house, car, or a watch without any design but the effect won’t be satisfying. This is an extreme case because it’s hard to find a developer without any UI/UX knowledge but this example should show you that design is a part of the process that you can but shouldn’t ignore. You’ve got to remember that design is not only about a “good-looking product” but a product with great usability and accessibility.
Web developers
Web developers work mostly with code. For non-tech people their work is a mystery. They cooperate closely with the designers in the early stages of the project. They also decide on the best technologies for the project, hosting environments, deployment, CMS or an admin panel, databases and all the tech stuff. But the main responsibility of developers is to transform designers’ ideas into an actual usable and interactive product. They implement views, functionalities, and features using languages like HTML, CSS, JavaScript, PHP, Python, Ruby on Rails and many, many others. The code part of the product is large enough to be split into smaller parts and these parts are the respective responsibilities of frontend and backend developers.
Frontend developers deal with code that results in something visible for users while backend developers focus on code that works “in the background”. Frontend developers often work with designers very closely. They are often called web developers, despite fact, that for many professionals this title refers to both frontend and backend developers. They can be named JS or UI developers also. This brings us to another interesting topic.
In recent years, frontend development has started to split into two distinct job groups - UI developers and JS developers. While the former share some responsibilities with web designers and work with HTML and CSS on a regular basis, the latter have very little to do with the look and feel of the user interface and focus mainly on implementing business logic in JavaScript. To give an example: a UI Developer can write code responsible for the presentation of a button - its shape, size and color - but it will be up to the JS Developer to add interaction to it, such as toggling a dropdown or navigating the user to a different view. This is obviously an optional division of responsibilities and oftentimes you will find one developer working both on the UI and business logic.
Frontend and backend developers use plenty of tools and solutions, the community is enormous and lots of people share the code they develop under an open license. There are many frameworks, static site generators (SSG), content management systems (CMS), hosts providers, plugins, libraries and so on.
Cooperation
I’ve distinguished between the roles of designers and developers but this doesn’t mean that designers don’t have any idea what developers do, and vice versa. These professionals have to be in touch constantly. Designers who understand code and developers who understand design are much more effective.
There is one aspect that serves as a great example of how a front end developer should understand design: RWD (Responsive Web Design). This is a web design technique that makes web products scale and look good on all screen sizes (desktops, tablets and smartphones). Sometimes designers focus on one screen size, not so much at the beginning of the project but later, to save time. They can afford to do so because developers can feel the mood and understand the design on such a level that it allows them to think about design independently, or with a little help from a designer.
There is one more thing connected to RWD. Designers are not able to design a product for every possible screen resolution but only for the most popular few, so it is up to the developer to cover how a web page should render at specific resolutions.
There are many more areas where developers have to take some of the responsibilities of designers, this was only one little example.
Full stack designer vs full stack developer
What if I tell you that there are people who take numerous roles on themselves. Amazing, isn’t it? These guys are called full stack developers or designers. But first things first.
I’ve mentioned that developers can be divided into frontend and backend developers. When a person has skills for implementing both frontend and backend they are called a full stack developer. The line between those two types of developers is thin, thanks to many developer-friendly tools and facilities. To recap, a full stack developer is a person who can cover the client side (frontend) and the server side (backend).
Who are these full stack designers then? They are designers who can develop the frontend part of their work. They take care of UI/UX and all the visual and graphic stuff and are able to develop it in HTML, CSS, and JavaScript. That is particularly interesting because full stack designers can omit some parts of their work, enabling them to develop products faster.
This is possible because they can develop a design using the actual final code, and not start by using an intermediary like Sketch, Adobe XD, Adobe Photoshop, or Figma. They can also fix some design issues at the implementation stage without a developer.
In the picture below you can see which full stack role covers what areas. At Boldare, we’ve got even more superpowers because not only do our designers think about the product goals, so does every team member. You can read more how we build products here.
Web Design and Development - a project-saving combo
While it’s important to understand the different roles involved in digital product development, remember the end user doesn’t look at the final product and distinguish between the work of a UI or UX designer or frontend or backend developers.
All users are interested in is whether it’s a great product or not. And users are terribly (maybe even unreasonably) demanding. If just one part of the product is lame (or just one role behind the scenes is missing or poorly executed) the whole thing will be written off as lame as well. The reality is, it’s essential to build a dev team that covers all the requirements of your digital product. This requires a variety of essential skills and knowledge. Every product may be different but if you want to build something complex from scratch, with a large and committed user base, you need a team that has a range of knowledge to apply to each element of the process: UI/UX, frontend, and backend.
Although development team members focus on different areas, they work towards the same objective and all want to create an efficient and good-looking product with a great user experience.
Share this article:
