Tutorial: Web Design 101 for Web Developers
Before becoming a web developer I used to be a photographer. I also played around with graphic design, laying out my own portfolio site as well as designing sites for other arty friends. This design-oriented background is something that crossed over with me into front end work. Even though now my job is much more about the code, I still prioritize making stuff look good.
And you should too: like it or not, people do judge our apps and projects based on looks. If what you make looks good and is easy and intuitive to use, the end users are going to trust it more. They don’t care about your amazing code. Sorry. But it’s the UX that makes people feel like you know what you’re doing. When they feel that way, then they are going to use your app. That’s just the way it is.
So, time for some truth-tellin’ — web dev style.
Design is a Legit Important Part of the Programming Workflow.
When I first started doing web dev projects in front end boot camp, I was kind of startled how little (cough zero cough) attention was given to the actual design of the projects we were assigned to build. The attitude was that design is someone else’s responsibility, outside the developer’s job description. We are just here to build it. This may have been how things used to work, but it is simply not true anymore.
You don’t just sit down with all 4,018 pieces of the Lego Death Star and start building: you look at the picture, you follow the directions. So it goes with web design.
No matter whether you work in a large corporation, a small company, or for yourself, at least understanding the essentials of good web design and starting to incorporate them into your own projects is becoming an essential job skill. Working on a team in a bigger company in this age of agile development means everyone needs to be able do a little bit of everything. For us, this means more than stitching together the APIs — it means also making the final render look good. Knowing even a few design basics is going to save time and boost your value.
If you’re in a small shop, out on your own, or simply dreaming of bootstrapping a profitable side project, you’ve already recognized the imperative to have a wide skills spread that enables you to do a lot of different jobs. Being a designer is one of them.
You Can Do This. Yes, You.
Don’t panic: a solid web app design doesn’t require sophistication, a subscription to a font library, or a bunch of Dribbble upvotes.
Instead, a good design is one you don’t even notice in the first place. It’s the perfect balance of “my granny could do that” and “that is cool!”
Design is not some innate artistic talent. It is just a skill, and like any skill it can be learned. Coming up with a good web app design is a lot more like building something from Legos than painting the Mona Lisa. You don’t just sit down with all 4,018 pieces of the Lego Death Star and start building: you look at the picture, you follow the directions. So it goes with web design. Pick something you like, figure out how it goes together. Try it for yourself. Now change it and see what happens.
Free Your Mind, and Your UX Will Follow.
As coders, we are used to taking a general set of project goals and coding toward them. The different pieces ultimately will need to talk to each other and work together, but how we get to that point is entirely up to us. There is a lot of creative freedom and flexibility in writing code.
Strangely, this is not the case with design. Design tools work very, very differently, in a kind of almost rigid way. At first, this is really hard to get used to, and honestly kind of maddening, but there is a reason. Code is iterative, and the tools for writing code are very open-ended. Design tools, however, force you to work as though every element is static in nature and absolutely positioned. This feels really limiting at first, but try to roll with it. This way of working actually makes experimenting and moving layouts around much easier, because changing one small thing doesn’t end up cascading down the whole rest of your design. Which is important, because design is an ongoing process and things evolve and change constantly.
Speaking of Design Tools.
As developers, we are used to working in our favorite IDE. Even that is not strictly necessary — we could even use Notepad to code an app indistinguishable from one built using Visual Studio. Adding design to the dev workflow does mean learning at least one new tool, though, no matter how you go about building the darn thing. Fortunately, just as there is no practical difference in using React vs. Vue for your front-end framework, there is no real difference between design tools. It’s simply a matter of preference.
Web design tools to consider are:
- Sketch: A Mac-only tool that, similar to React, seems to be hard-coded in every dev job listing out there. $99/year.
- Adobe XD: A cross-platform tool that is a newer arrival to the design ecosystem. Think of it like Vue: a smaller number of people use it, so there is a smaller support community, but it’s reasonably intuitive and easy-ish to get started with. It’s also free.
- Adobe Photoshop: The most powerful and expensive option. It’s the designer’s multitool, able to take on any kind of task. Think JSON: use any time, anywhere. $9.99/mo.
- MS Paint: Windows classic built-in image editing app would be the equivalent of using Notepad. Tempting, but. Just. Don’t.
My recommendation for most devs interested in playing around with design is to go Adobe XD. The UI is a lot simpler than Photoshop, because it simply does a lot less than Photoshop does, but even XD’s basic capabilities will get the job done.
Now Design Something.
The best way to learn a new tool is by playing around with it. What are you interested in building?
A Website
A website project begins, naturally, with a landing page. In web development, when we say “layout” we typically mean a header with navigation, a center section for content, and a footer. There are infinite ways to implement this basic structure – think of it as a newly opened Caryola box. The coloring sheet in front of you has some basic shapes established, and you get to color it in however you like with all those bright, fun crayons.
Easier said than done? If you’ve never actually designed anything before, it is totally common to just completely freeze and lock up when faced with a blank project. What we all do in times like these is head straight for the designer’s equivalent of copy-pasting from Stack Overflow: land-book.com, This is like Dribbble but only for landing pages, a vast directory of every kind of conceivable layout that, again just like SO, designers upvote or downvote. The key is to scroll through freely until (a) you find a design you would like to try to replicate or (b) note the designs you like the most, identify whatever common design theme is drawing your eye, and build something from scratch using that aesthetic.
Once you’ve got the landing page built, the related pages will often just fall into place, and you can reuse your base design from page to page, changing the code and content to suit. See? You got this.
A Web App
Designing an entire app is obviously more complicated than a landing page project. You start the same way, though, by not just jumping straight into building it. Different from a landing page, where the interior of the site can follow once the front door has been constructed, with an app you need to think about functionality up front. The ultimate goal is a simple but logical visual layout and ease of use.
This actually begins with a pencil and paper (or a pen and napkin, whatever you got). Draw it out. Sketch a plan for what your app needs to include, where it will go, and how to navigate between. If there are other apps already out there along the lines of what you’re interested in building, go have a good long look-see at how they do it. Not just what they do, but whether it works, and even if they are missing any important functionality that smart ol’ you can now build into your design.
(This is the point where “real” designers use wireframes, which are simple schematics of the layout. No graphics or colors, just a skeletal representation of what goes where. Lots of times you can just accomplish what is necessary with pen and paper, but if you have to present your design to anyone, chances are you’re going to have to generate a formal wireframe. Adobe XD has a whole menu to make that quick and easy).
Web apps almost always fall into one of two-page layout categories, fixed-width container or fluid container. The choice is often dictated by the app’s function.
Fixed-width container apps are harder to build, due to working in the constraints of a smaller design field, plus all the head-clutching permutations of screen widths and orientation that are possible in today’s teeming universe of devices. Fixed apps do have benefits — they typically have a cleaner, more minimalist appearance and thus tend to be easier to engage with, especially for new or tech-challenged users. They are also solid, immovable targets for API content delivery because what you see is always what you are going to get. A good use case for fixed width design is a simple interface where delivering one big main content item is the entire point of the app: think Twitter. Another example of an app using fixed width is good ol’ GitHub.
Fluid containers, on the other hand, are designed to fill the entire screen — whatever screen that may be since they are size-agnostic by design — and then some. They let you use state of the art responsive design tools like Flexbox and CSS Grids, but from personal experience, I can tell you it’s easy to get carried away trying to cram everything in. Fluid container apps are the go-to for apps whose function is presenting lots of information — chat apps, spreadsheets, tracker apps: think Slack. If your wireframe ends up looking suspiciously like a table layout, chances are this is your kind of app. Just stay vigilant to not overloading the screen; discretion is the better part of valor in all design, and especially in this case. Keep the layout as simple and uncluttered as possible, and give careful thought to the visual hierarchy of information you’re displaying — less crucial stuff does down low in the scroll zone, dig?
The Arty Part
Technically, we have been talking laying out a website or app. Creating an intelligent, elegant structure befitting the beautiful code you’re going to be writing behind this project.
Design encompasses other things as well. Color choices — white background, or tinted? How many different colors can I use without it looking like a carnival in there? Typography — lord, that is a deep rabbit hole right there. Graphics and images and animations, oh my….
The main thing web developers need to do, whenever wearing the web designer cap by choice or necessity, is to just build a simple, sensible structure. That is genuinely the hardest part. If you like playing with the pretty parts — if CSS is your favorite language — then, by all means, have at it. But, honestly, lots of people like that part of design, which is more akin to decorating. If you don’t want to pick the color scheme, chances are there are plenty of people you know who will be happy to.
Then you can get back to the good stuff, like figuring out how to implement a JavaScript interface.
