The step-by-step process of turning design into code

Original link: css-tricks.com/a-step-by-s…

Converting Web design files to a combination of HTML, CSS, and JavaScript is the foundation of much front-end Web development work, but parts of that work are not entirely appropriate for tutorials on any particular topic. Breaking down the design and figuring out how to build it seems like on-the-job training for new front-end developers. It is not something that is taught in conjunction with core technologies (no matter where we learn them — university, boot camp or ourselves).

In this article, we’ll look at how to go from design to code, and why you might want to follow such a process instead of diving headlong into code — and let’s face it, we love doing it! The content of this article is based on my onboarding experience with new developers, the types of conversations we have, and the help and feedback I provide in those situations.

One reason the process from design to code is a core expertise of a front-end developer is that ** Without some way to mine and predict how you’ll approach something, it’s hard to estimate how long it will take or what questions you might need to answer before you start. ** Many designs seem simple at first glance but quickly become complicated when they get caught in the weeds. I’ve seen this lead to overcommitment, which often leads to tighter deadlines, stress, and even worse side effects. Suddenly, everything is much more complicated than we first imagined. Let’s see if we can avoid that.

To evaluate the design

As a way to discuss this, let’s use an example design of a “marketing style” web page and assume we’ve been asked to implement it. We can also assume that the site was created in an environment where marketing professionals could enter and edit content, reorder sections, replace images, and change styles through some content management system (CMS). Therefore, we need to decide which page components will be used as building blocks in the CMS.

This is another reason to ignore in education: often in our own personal projects, we can set static content in HTML and weave parts together to form brand new pages and sections. But once you get into a more realistic development environment, things become more dynamic, and we often work at the “make things that non-developers can use to make web pages” level.

Let’s take this site as an example of a clinical trial. As we can see, there are many familiar design elements. Marketing sites often have a common pattern:

• A big hero part
• Product pictures
• A short piece of content that emphasizes one thing or another
• Your company information
• And so on.

On mobile devices, we can assume that in each section, the left column will stack on top of the right, and some other fairly typical backflow will occur. No structure on a mobile device changes. So we’re looking at the heart of the design.

In this case, there is a header, then a number of different sections, and a footer. At first glance, some sections look somewhat similar — for example, some sections have a two-column layout. Button and title styles seem to be consistent throughout. As soon as you see something like this, your eyes will start to notice the repeated pattern.

This is where we start taking notes. Before we do any coding, let’s understand the ideas involved in the design. These ideas fall into several categories, and we wanted our final product — the web itself — to get them all right. Here are some of my frequent concerns:

1. Layout level pattern — Repeat layout ideas and overall grid
2. Element-level patterns — title, text size, font, spacing, icon, button size
3. The palette
4. Structure thought – logical organization of parts, independent of layout
5. ** Other — ** Ideas that exist only in one component

Documenting patterns in this way is very useful for figuring out our CSS approach, as well as for choosing HTML elements to use and starting conversations with designers or other stakeholders where there is ambiguity. If you have access to the source file of the design, you might mark sections and layers in it to give you a good idea of what the designer has in mind. This is helpful when you want to talk about specific parts.

So let’s take a look at the ideas included in the sample design. We’ll go through the design multiple times, and in all of these, we’ll go from ** to **, top to bottom, and left to right, ** to make sure we evaluate each element. In each of the five walks, we were looking for something that only made it into one of the lists.

We don’t care about making the list perfect; It can always be changed later — we just want to record our first impressions.

Step 1: Layout-level ideas

In this design, we have some layout ideas that can immediately stand out.

• Title with horizontal navigation section
• The main content column within the content area – the left and right edges are aligned across all sections from header to footer
• A part having two columns
• A part having a single center column
• A section with a single left-aligned column
• Footer containing three columns
• There’s a lot of padding in each section

The first impression

We should pay attention to any other first impressions, good or bad, that we have on our first pass. We can never have two first impressions, and if we ignore them now, some of our gut reactions and problems may be forgotten. Also, when we talk to designers, it might be good to identify specific things in your design that you like. It helps both to celebrate the good and to combine it with other constructive criticism.

Our first impression might look something like this:

• 👍 Design is simple and easy to read.
• 👍 These sections are all titled with questions (good, it helps to engage the reader and provide a clear purpose for each section).
• 🤨 question mark used inconsistently in title (could it just be an oversight?) .
• 🙋♀️ sometimes have very similar font sizes adjacent to each other (may need to be followed up to see if this is intentional as it doesn’t look as smooth and professional as the rest of the site).
• 👍 is a nice sign with that little gradient.

Step 2: Element-level ideas

Here are some things we might notice on the second pass:

• The primary (blue) and secondary (white) button styles, as well as the “Learn more” button with a small arrow in the title (expand menu perhaps?).
• Title and subtitle styles
• Three “body” sizes (16px.18px.20px)
• “Dark Mode” section, the text color is white, the background is dark
• Consistent rendering of the image and Title set
• Various customization points
• Inline links in text are underlined, while other links, such as links in footers, are not.
• A repeating card component with an icon at the top, a title and a list inside the card
• The logo is repeated several times in different contexts/sizes.
• The footer contains capitalized headings that do not appear elsewhere.

Step 3: Color palette

There is not much variation in color in this design.

• Blue/purple primary color
• Light/dark text color
• Light/dark link colors
• A nice gradient under the word “hope” in the logo
• Light grey background color
• Dark navy background color
• Specific red and green “check mark” and “Stop” icon colors

Some design tools allow you to export color hexadecimal values used in design files, or even full Sass or CSS variable declarations. If you have this option, use it. Otherwise, find your own way to get these values and name them, because these are the basis of much of our original CSS work.

In our CSS and other code, we want to refer to colors using tags or classes, such as “primary” and “secondary,” that we can reuse throughout our code. This makes it easier to adjust values later and add themes as needed.

Step 4: Structural thinking

At this point, we might actually name the page area in a way that makes sense to us and determine the hierarchy of content. By documenting in simple language the nature and structure of the page content we see, we can begin to understand the requirements of our implementation. As always, when we evaluate, we evaluate from the outside in, from the top down, from the left to the right.

Focusing on structure helps us figure out the underlying patterns that ultimately become our components, and also helps us understand the way we want people using assistive technologies to perceive content. In turn, it guides us through which HTML elements we need to use to write semantic HTML. Semantic HTML describes the nature and structure of the content so that browsers can perceive it correctly. Browsers use our HTML to create assistive trees that assistive technologies, such as screen readers, use to render pages. They need a good outline to succeed, and semantic HTML provides a good structure.

This means that we need to fully understand the nature of the content on the page so that we can explain it verbally without visual support. With this understanding, we can work backwards through the accessibility tree to find the correct HTML to express this understanding, which can be checked in the browser’s developer tools.

This is a quick example of an accessibility tree in Chrome if all div contents on a page are, and elements are selected correctly to match the nature of the content. Determining the best element choice for a given situation is beyond the scope of this article, but it can be said that the expressive, non-” generic “accessibility tree below is created entirely from HTML elements and attributes, and makes its structure more accessible to the content and people using assistive technologies.

So, in the fourth pass, we might make the following notes:

• Top-level structure:
  • The title
  • The main content
  • The footer

Not bad for a first pass from top to bottom. Let’s dig a little deeper. We still don’t care about the elements inside the child elements of the section itself — we just need enough information to mark the top-level items within each section.

• inIn the titleThere are:
  • The home page link
  • The navigation part
• inAmong the main contentsThere are
  • Hero part
  • A brief explanation of the disease itself
  • Treatment instructions
  • The trial is introduced
  • The interpreter provides more details about the tests
  • A statement about who can participate in the study
  • Call to action
  • Company profile
• inIn the footerThere are:
  • Logo
  • The words of
  • A list of links with titles
  • Dividing line
  • Copyright statement

This step reveals something. First, the header and footer sections are very shallow and show raw elements such as links and text. Secondly, the main section has eight different sections, each with its own theme.

We’ll do it again here and look at some of the deeper details in these sections.

• ** Title home page link -** Wow, it’s just a link and we’re done.
• ** Title Navigation – ** This is an extended hover navigation that requires JavaScript to work properly. There may be many accessible examples to follow, but it still takes more time to develop and test than using raw links.
• Hero
  • The title
  • 1 bar
    • Subtitles (we missed this in the first element-level pass)
    • The paragraph
    • Home button link
    • Secondary button link
  • Column 2,
    • The hero image
• Disease interpreter
  • The title
  • The paragraph
  • Unordered list
  • Large text
  • Unordered list
  • Image and description (diagram and diagram description)
  • List of links
• Therapy instructor
  • The title
  • 1 bar
    • The paragraph
  • Column 2,
    • Image and description (diagram and diagram description)
• Trial – Introduction
  • The title
  • 1 bar
    • YouTube Video Player
  • Column 2,
    • The paragraph
• Trial — more details
  • The title
  • subtitle
  • Cards (with ICONS, titles, and lists)
• “Who can join” statement
  • The title
  • 1 bar
    • The paragraph
    • Unordered list
  • Column 2,
    • The paragraph
    • Unordered list
• A call to action
  • The title
  • The paragraph
  • Secondary button link
• About the company
  • The title
  • The paragraph

Wow, that’s fast! But now we have a pretty good idea of the kinds of things we need to build, and what parts might be tricky. We also see that there may be some ancillary components to build any of these parts have not been fully represented, for example, two-column layout component stack on the mobile device on a column and has a title at the top, or a general “part of the container” component, it USES the background and foreground, and provide the correct style and standardized internal filling.

By the way, with this breakdown, we’ve pretty well expressed the final accessibility tree we want HTML to create, so we’re well on our way to making the implementation a smooth experience without having to do a lot of rework to get accessibility.

Step 5: Others

What other ideas, standouts, or challenges did we notice in the design? Maybe not much, but that’s the flip side of the “first impression” note. Now our heads are full of design.

If something stands out right now, especially about how something works, grab it. For example, “Well, what should the ‘learn more’ link in the navigation do?” The answer might be: “This is the list of links that open when you hover over each section.” From time to time, designers hope that something like this is already implicit in the design, even if it’s not explicitly documented and only appears during the design review phase after the thing has been developed — which is often too late to correct without affecting dates and deadlines.

We should also delve deeper now and identify any hidden “glue jobs” — things like cleaning up our styles, working with mobile devices, configuring our CMS, authoring options and arrangements for adding and testing our building blocks, and things like adding automated tests.

At this point, we are ready to determine exactly what components can be created in the CMS. Maybe we’ve done some basic setup on the current system in our past work. In any case, we have enough resources to provide a reasonable estimate of the work required, grouped by category. For example, we might classify the following components:

• 100% ready (no development time required)
• Exists but needs to be adapted for new purposes (requires predictable development time)
• Is brand new, but the path is obvious and safe (requires predictable development time),
• It’s brand new and needs some research to implement. Or the design is not clear, or something about it is causing you trouble, and you need to discuss it with stakeholders. The sooner we find that out, the better. Discuss with anyone running the project.

Now we have enough information to make a reasonable estimate. More importantly, we reduced the total time required for the project and reduced the amount of trouble we might run into because we gained several advantages from the plan.

There are benefits of process

The exact steps we take and the order in which they are done are beside the point. The most important thing is to understand the type of information you need to collect when you start a project. You probably have ideas about how work should be done and in what order, and anything that works for you is great.

Here are some of the advantages I realized while evaluating the design during the consideration process, compared to just diving in, “making things work” and dealing with things as they come up.

You found something extra

Although we want every project to be fully formed and ready to start, in reality, design often contains assumptions that may not be implementable or contradict other things we care about, such as accessibility. In this case, you can evaluate the whole thing up front and start a conversation with someone who can address these issues early in the process. This can happen as you drill down into the part where the code is ready, and can prevent you from running into these obstacles later when you build that part. People who like to solve problems will ask questions early.

You can get help from others

Without a plan, it can be difficult to know where you are in completing the project and whether you need help meeting the deadline. Even if you do need help and can ask for it, it’s hard to use the extra helping hand effectively without breaking the work down into easily divisible pieces. When you have a plan that makes sense, you can quickly delegate to someone who will eventually come together.

It’s easy (and common) for new developers to think that a huge workload and working around the clock is a good thing. But as you mature in your role, you’ll find it more valuable to delve into the whole picture of a project, or even a ticket, while creating a better impression that you’re “ahead of the game.” Recognizing early on that the schedule doesn’t look right allows you to choose how to fix it in other ways, rather than trying to be the hero and spend some weekends.

Component architectures are more fluid

Building decisions are the worst for me. Name components, figure out where things go, which components need to talk to each other, and where to break things up into smaller components. Many of these choices only make sense if we look at the big picture and consider all the various ways visitors and content creators might use certain elements. And many of these choices are marginal — choosing the “best” option between two acceptable solutions can be time-consuming or entirely subjective.

Designing a process helps, because you will have all or most of the information you need about your design before delving into the development effort. Figuring out what parts I need to make and figuring out the best code to make those parts are two different things for me. Sometimes WHAT I need isn’t the most natural thing in the code. Sometimes, after I know something about what’s needed, I can avoid spending time on marginal decisions because it’s clearer what really doesn’t matter.

Of course, you can still learn new things as you write code, but you are now better prepared to deal with them as they arise. You even have a good idea of the types that might appear.

Style is more meaningful

As you plan your work, you can really figure out which styles are global, which are section-specific, which are component-specific, and which are one-off. If you don’t already have a favorite system, Andy Bell’s Cube CSS is perfect for the kind of problem I’m talking about. This is a video of Andy working with Chris Coyier to complete an example, and you can check out more information about this approach.

Accessibility starts early in the process

This is huge for me. By really understanding the ideas included in your design, you’ll have an easier time selecting semantic HTML elements and finding the right accessible patterns to build what you see there. Accessibility can be built into your daily routine, not an afterthought or additional burden. Our view is that high-quality front-end code correctly expresses the nature and structure of its content to all users, and accessibility is how we measure this.

In a short amount of time, you’ll see how often the design conforms to one known pattern or another, and you’ll decompose something into a known pattern, and the flow of implementation will speed up. Carie Fisher nicely summarizes the ideas associated with this “accessibility first” approach.

finishing

As I said at the beginning, a lot of this is on-the-job training, the “oral tradition” of Web development. You may hear this from senior developers on your team when you take on your first front-end role. I’m sure many people will have different priorities than I do and recommend a slightly different process. I also know for sure that many people work without a reliable process and no senior person to consult.

If you are in this situation, or if you are not already in the top job, I hope this provides a baseline for you to think about how to do your work in relation to it. We are eager to make progress and see results.

I was very grateful to have someone who actually worked with me in my first development job, who showed me how to break down the pieces of design and estimate the work of large, long-term projects. That’s what inspired me to start thinking about it, and — as I started overseeing other developers and teams — think about how I wanted to tweak the process and make it my own. I also realized that when teaching technical skills about using a particular language, I didn’t notice people talking about it too much. So thanks!

Thanks also to Drew Clements and Nerando Johnson for providing early feedback on this article. You’re the best.