Evaluating a design<\/h3>\n\n\n
As a way to talk about this, let\u2019s use an example design for a \u201cmarketing-style\u201d web page and assume we have been asked to implement it. We can also assume this site is created in a context where marketing professionals may come in and edit the content via some content management system (CMS), re-order the sections, replace images, and make style changes. So we need to decide on the components of the page that will be the building blocks used in the CMS.<\/p>\n\n\n\n
This gets at another reason that this can be missed in education: often in our own solo projects, we can have static content right there in the HTML, and component parts aren\u2019t going to be Frankenstein-ed together by strangers to form whole new pages and sections. But once you step into more real-world dev situations, things are a lot more dynamic, and we are often working at the layer of \u201cmake things that a non-developer can use to make a web page.\u201d<\/p>\n\n\n\n
![\"The](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/07\/s_F0B5AD641171C319D4646FE40F7489ABC260F6D7541A0726504CBC69E4AAAB1D_1624216949922_CVShope.png?resize=399%2C2160&ssl=1\")
Let’s use this website for a clinical trial is example. As we can see there are a lot of familiar design elements. Marketing sites tend to share common patterns:<\/p>\n\n\n\n
- a big hero section<\/li>
- product images<\/li>
- small separate sections of short-form content emphasizing one thing or another<\/li>
- information about the company<\/li>
- etc.<\/li><\/ul>\n\n\n\n
On mobile, we can take it as a given that in each section, the left columns will stack on top of the right, and some other fairly typical reflow will happen. Nothing structural will change on mobile. So what we are looking at is the core of the design.<\/p>\n\n\n\n
In this example, there is a header, then a lot of distinct sections, and a footer. At a glance, some of the sections look kind of similar\u2014several have a two-column layout, for example. There are button and heading styles that seem to be consistent throughout. As soon as you take a look at something like this, your eye will start to notice repeated patterns like that.<\/p>\n\n\n\n
This is where we start making notes. Before we do any coding, let\u2019s understand the ideas contained in the design. These ideas can fall into a few buckets, and we want our final product\u2014the web page itself\u2014to correctly represent all these ideas. Here are the buckets I commonly use:<\/p>\n\n\n\n
- Layout-level patterns<\/strong>\u2014repeating layout ideas and the overall grid<\/li>
- Element-level patterns<\/strong>\u2014headings, text sizes, fonts, spacing, icons, button sizes<\/li>
- Color palette<\/strong><\/li>
- Structural ideas<\/strong>\u2014the logical organization of sections, independent from the layout<\/li>
- Everything else<\/strong>\u2014ideas that are only present in one component<\/li><\/ol>\n\n\n\n
Documenting the patterns this way comes in handy for figuring out our CSS approach, but also for choosing what HTML elements to use and starting conversations with the designer or other stakeholders if something is unclear. If you have access to the source files for the design, sections and layers might be labelled in there that give you a good idea what the designer was thinking. This can be helpful when you want to talk about specific sections.<\/p>\n\n\n\n
So let\u2019s look at the ideas contained in our example design. We\u2019re going to do several passes through the design, and in all of them, we\u2019re going outside-in, top-to-bottom, and left-to-right<\/strong> to ensure we evaluate every element. In each of the five passes, we\u2019re looking for stuff that goes into just one of the buckets.<\/p>\n\n\n\n
We\u2019re unconcerned with getting this list perfect; it can always be changed later\u2014we just want to record our first impressions.<\/p>\n<\/div>\n<\/div>\n\n\n
Pass 1: Layout-level ideas<\/h4>\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/07\/layout.png?resize=1024%2C613&ssl=1\")
<\/figure>\n\n\n\nIn this design we have a few layout ideas that stand out right off the bat.<\/p>\n\n\n\n
- A header with a horizontal nav section<\/li>
- A main content column within the content area\u2014left and right edges align within all sections from header to footer<\/li>
- Sections with two columns<\/li>
- Sections with a single centered column<\/li>
- Sections with a single left-aligned column<\/li>
- A footer with three columns<\/li>
- Fairly generous padding inside each section<\/li><\/ul>\n\n\n
First impressions<\/h5>\n\n\n
We should note any other first impressions we have during this first pass, good or bad. We can never have a first impression twice, and some of our gut reactions and questions can be forgotten if we neglect noting them now. Plus, identifying specific stuff that you like in the design can be nice when we get to talking with the designer. It both helps to celebrate the good stuff and mix it in with other constructive criticism.<\/p>\n\n\n\n
Our first impressions might be things like:<\/p>\n\n\n\n
- 👍 The design is clean-looking and readable.<\/li>
- 👍 The sections are all titled by questions (good, helps draw reader in and gives each section a clear purpose).<\/li>
- 🤨 Question marks are used inconsistently in the titles (possibly just an oversight?).<\/li>
- 🙋♀️ Sometimes there are very similar font sizes right next to each other (may need to follow up to see if this is intentional because it seems a less slick and professional than the rest of the site).<\/li>
- 👍 The logo is nice with that little gradient going on.<\/li><\/ul>\n\n\n
Pass 2: Element-level ideas<\/h4>\n\n\n
![\"The](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/07\/s_F0B5AD641171C319D4646FE40F7489ABC260F6D7541A0726504CBC69E4AAAB1D_1624836033173_font-sizes.png?resize=1000%2C609&ssl=1\")
<\/figure>\n\n\n\nHere are things we might notice in this second pass:<\/p>\n\n\n\n
- Primary (blue) and Secondary (white) button styles, plus a \u201cLearn more\u201d button in the header with a little arrow (an expanding menu maybe?)<\/li>
- Heading and sub-heading styles<\/li>
- Three \u201cbody text\u201d sizes (
16px<\/code>,18px<\/code>,20px<\/code>)<\/li>- A \u201cdark-mode\u201d section where text color is white and the background is dark<\/li>
- A consistent presentation of \u201cimage & caption\u201d sets<\/li>
- Custom bullet points of various kinds<\/li>
- Inline links in the text are underlined and, other links, like those in the footer, are not.<\/li>
- A repeated card component with an icon on top, and a heading and a list inside the card<\/li>
- The logo repeats a few times in different contexts\/sizes.<\/li>
- The footer contains uppercase headings that don\u2019t appear elsewhere.<\/li><\/ul>\n\n\n
Pass 3: Color palette<\/h4>\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/07\/colors.png?resize=1024%2C695&ssl=1\")
<\/figure>\n\n\n\nThere is not too much going on in this design color-wise.<\/p>\n\n\n\n
- blue\/purple primary color<\/li>
- light\/dark body text colors<\/li>
- light\/dark link colors<\/li>
- nice gradient under the word \u201chope\u201d in the logo<\/li>
- light gray background color<\/li>
- dark navy background color<\/li>
- specific red and green \u201ccheckmark\u201d and \u201cstop\u201d icon colors<\/li><\/ul>\n\n\n\n
Some design tools let you export the color hex values used in the design file, or even full-on Sass or CSS variable declarations. If you have that option, use it. Otherwise, find your own way to grab those values and name them because those are the foundation for lots of our initial CSS work.<\/p>\n\n\n\n
Throughout our CSS and other code, we want to be refer to colors with labels or classes like \u201cprimary\u201d and \u201csecondary\u201d that we can reuse throughout the code. This makes it easier to adjust values in the future, and to add themes down the line if we ever need to.<\/p>\n\n\n
Pass 4: Structural ideas<\/h4>\n\n\n
This is where we might actually name the regions of the page in ways that make sense to us, and identify the hierarchy of the content. We can start to understand the accessibility needs of our implementation by documenting in plain language what we see as the nature<\/strong> and structure<\/strong> of the content in the page. As always, going outside-in, top-to bottom, left-to-right as we make our evaluations.<\/p>\n\n\n\n
Focusing on structure helps us figure out the underlying patterns that eventually become our components, and also helps us understand the way we want people who use assistive technology to perceive the content. In turn, that guides us as far as what HTML elements we need to use to write semantic HTML<\/strong>. Semantic HTML speaks to the nature and structure of the content so that it can be perceived correctly by browsers. Browsers use our HTML to create the accessibility tree<\/a> that assistive tech, like screen readers, uses to present the page. They need a strong outline for that to succeed and semantic HTML provides that solid structure.<\/p>\n\n\n\n
This means we need to understand the nature of what\u2019s on the page well enough that we could explain it verbally with no visual support if we had to. From that understanding, we can work backwards to figure out the correct HTML that expresses this understanding via the accessibility tree, which can be inspected in you browser\u2019s developer tools.<\/p>\n\n\n\n
Here\u2019s a quick example of the accessibility tree in Chrome if everything on the page is a
div<\/code>, and if elements are correctly chosen to match the nature of the content. Determining the best element choice in a given situation is outside the scope of this post, but suffice it to say that the expressive, non-\u201dgeneric generic generic\u201d accessibility tree below is entirely created with HTML elements and attributes, and makes the content and its organization much easier for somebody to perceive using assistive technology.<\/p>\n\n\n\n![\"Three](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/07\/s_F0B5AD641171C319D4646FE40F7489ABC260F6D7541A0726504CBC69E4AAAB1D_1624837500297_divsoup.png?resize=2220%2C1530&ssl=1\")
<\/figure>\n\n\n\nSo, in this fourth pass, here are notes we might make:<\/p>\n\n\n\n
- Top-level structure:
- Header<\/li>
- Main Content<\/li>
- Footer<\/li><\/ul><\/li><\/ul>\n\n\n\n
Not so bad for the first top-to-bottom pass. Let\u2019s go a level deeper. We\u2019re still unconcerned with the child inside elements of the sections themselves yet\u2014we want just enough info to label the top level items inside each sections.<\/p>\n\n\n\n
- Within Header<\/strong> there is:
- Home link<\/li>
- Navigation section<\/li><\/ul><\/li>
- Within Main Content<\/strong> there is:
- Hero section<\/li>
- Short explainer about the disease itself<\/li>
- Explainer about the treatment<\/li>
- Intro to the trial<\/li>
- Explainer with more details about the trial<\/li>
- Statement about who can join the study<\/li>
- Call-to-action to participate<\/li>
- Short explainer about the company<\/li><\/ul><\/li>
- Within Footer<\/strong> there is:
- Logo<\/li>
- Summary Sentence<\/li>
- Some lists of links with titles<\/li>
- Divider<\/li>
- Copyright notice<\/li><\/ul><\/li><\/ul>\n\n\n\n
This pass reveals a few things. First, the Header and Footer sections are pretty shallow and are already revealing raw elements like links and text. Second, the Main section has eight distinct subsections, each with its own topic.<\/p>\n\n\n\n
We\u2019re going to do one more pass here and get at some of the deeper details in those sections.<\/p>\n\n\n\n
- Header home link\u2014<\/strong>Woohoo, it\u2019s just a link and we\u2019re done.<\/li>
- Header nav\u2014<\/strong>This is an expanding hover nav that needs JavaScript to work correctly. There are probably lots of accessible examples to follow, but still will take more time to develop and test than if we were working with raw links.<\/li>
- Hero<\/strong>
- Title<\/li>
- Column 1
- Subtitle (we missed this in the first element-level pass)<\/li>
- Paragraph<\/li>
- Primary button link<\/li>
- Secondary button link<\/li><\/ul><\/li>
- Column 2
- Hero image<\/li><\/ul><\/li><\/ul><\/li>
- Disease Explainer<\/strong>
- Title<\/li>
- Paragraph<\/li>
- Unordered list<\/li>
- Large text<\/li>
- Unordered list<\/li>
- Image and caption (figure and figcaption)<\/li>
- List of links<\/li><\/ul><\/li>
- Treatment Explainer<\/strong>
- Title<\/li>
- Column 1
- Paragraphs<\/li><\/ul><\/li>
- Column 2
- Image and caption (figure and figcaption)<\/li><\/ul><\/li><\/ul><\/li>
- Trial\u2014Intro<\/strong>
- Title<\/li>
- Column 1
- YouTube Video Player<\/li><\/ul><\/li>
- Column 2
- Paragraphs<\/li><\/ul><\/li><\/ul><\/li>
- Trial\u2014More Details<\/strong>
- Title<\/li>
- Subtitle<\/li>
- Cards (with Icon, Title, and List)<\/li><\/ul><\/li>
- \u201cWho Can Join\u201d statement<\/strong>
- Title<\/li>
- Column 1
- Paragraph<\/li>
- Unordered list<\/li><\/ul><\/li>
- Column 2
- Paragraph<\/li>
- Unordered list<\/li><\/ul><\/li><\/ul><\/li>
- Call-to-Action<\/strong>
- Title<\/li>
- Paragraph<\/li>
- Secondary button link<\/li><\/ul><\/li>
- About the Company<\/strong>
- Title<\/li>
- Paragraph<\/li><\/ul><\/li><\/ul>\n\n\n\n
Yowza, that got long fast! But now we understand pretty well the kinds of things we need to build, and what parts might be tricky. We also see that there may be some helper components to be built that aren\u2019t quite represented by any one of these sections, for example, a two-column layout component that stacks to one column on mobile and has a title on top, or a generic \u201csection container\u201d component that takes a background and foreground color and provides the right styles plus standardized internal padding.<\/p>\n\n\n\n
Incidentally, with this breakdown we\u2019ve done a pretty good job expressing the final accessibility tree we want our HTML to create, so we are well on our way to having the implementation be a smooth experience without a lot of re-work to get accessibility right.<\/p>\n\n\n
Pass 5: Everything else<\/h4>\n\n\n
What are some other ideas contained in this design, things that stick out, or challenges we notice? Maybe not much, but this is kind of the other side of the \u201cfirst impressions\u201d notes. Now our heads are filled with context for what it is in the design.<\/p>\n\n\n\n
If something stands out now, especially if it\u2019s a question about how something works, capture it. An example is, \u201cHmm, what is the \u2018Learn More\u2019 link in the nav supposed to do?\u201d The answer might be: \u201cIt\u2019s a list of links to each section that open when you hover there.\u201d Every now and then, a designer expects that this kind of thing is already implied in the design, even if it is not explicitly documented, and it only comes up at the design review stage after<\/em> that thing is developed\u2014which is often too late to correct without affecting dates and deadlines.<\/p>\n\n\n\n
We should also now look deeply and identify any hidden \u201cglue work\u201d\u2014 things like getting our styles in order, handling mobile, configuring the CMS, adding and testing authoring options and arrangements for our building blocks, and adding automated tests. Stuff like that.<\/p>\n\n\n\n
At this point, we are ready to nail down exactly what components can be created in the CMS. Maybe we already have some of the basic setup done in the current system from past work. Whatever the case, we have enough to draw on to offer a decent estimate of the work needed, grouped into categories. For example, we might categorize components that:<\/p>\n\n\n\n
- are already 100% ready (no dev time needed),<\/li>
- exist but need tweaks for this new purpose (predictable<\/strong> dev time needed),<\/li>
- are totally new, but the path is obvious and safe (predictable<\/strong> dev time needed),<\/li>
- are totally new and need some research to implement. Or the design is unclear, or something about it gives you the heebie-jeebies and you need to have discussions with stakeholders. The earlier you can spot this, the better. Talk it over with whoever is running the project.<\/li><\/ul>\n\n\n\n
Now we have enough information to make a reasonable estimate. And more to the point, we\u2019ve reduced the total time the project will take, and limited the trouble we might have along the way, because we\u2019ve gained several advantages from planning it out.<\/p>\n\n\n
The advantages of having a process<\/h3>\n\n\n
The exact steps we take and what order they are completed in is not the main point. What matters most is understanding the kind of information you need to gather when starting on a project. You might have your own ideas about how the work is done and in what order, whatever works for you is great.<\/p>\n\n\n\n
Here are the advantages I\u2019ve realized when assessing a design with a process in mind, compared to just kinda diving in, \u201cgetting stuff working,\u201d and handling things as they come up.<\/p>\n\n\n
You do a little extra discovery<\/h4>\n\n\n
As much as we\u2019d like every project to arrive fully formed and perfectly ready to start, in reality, designs often contain assumptions that might be impractical to implement, or contradict something else we care about, like accessibility. In that case, you can assess the whole thing up front and get the conversations started with people who can resolve those issues early in the process. This can happen while you dive into the pieces that are ready to code, and will stop you from bumping into these roadblocks later when you are about to build that part of it. Flagging concerns early is definitely appreciated by the people who need to solve them.<\/p>\n\n\n
You can be helped by others<\/h4>\n\n\n
Without a plan, it can be difficult to understand how far along you are in completing the project, as well as knowing if you need help meeting a deadline. Even if you do need help and are able to ask for it, it\u2019s tough to use extra helping hands effectively without the work being broken out in to separate little chunks that be easily divided. When you have a plan that makes sense, you can quickly delegate certain tickets, knowing that the jigsaw pieces will fit together in the end.<\/p>\n\n\n\n
It\u2019s easy (and common) for a new developer to think think that huge workloads and working around the clock is a good thing. But as you mature in the role, you\u2019ll see that having a deep understanding of the whole picture of a project, or even a single ticket, is more valuable, while creating a better impression that you are \u201con top of things.\u201d Recognizing early that a timeline doesn\u2019t look right gives you options about how to address it in ways other than trying to be a hero and throwing some weekends at it.<\/p>\n\n\n
Component architecture flows better<\/h4>\n\n\n
Architectural decisions are the worst<\/em> for me. Naming components, figuring out where stuff should live, which components need to talk to each other, where to break stuff up into smaller components. A lot of those choices only make sense when we look at the bigger picture and think about all various ways that certain elements might be used by visitors and content creators. And a lot<\/em> of these choices are marginal\u2014choosing the \u201cbest\u201d option between two acceptable solutions can be a huge time suck or completely subjective.<\/p>\n\n\n\n
Have a process helps with that because you are going to get all, or most, of the information you need about the designs before digging deeply into the development work. For me, figuring out what pieces I need to make, and figuring out the best possible code to make those pieces, are two different things. Sometimes what I need is not the thing that comes most naturally from the code. And sometimes, after learning a bit about what is needed, I can avoid time spent bikeshedding marginal decisions because it\u2019s more clear which decisions truly don\u2019t matter.<\/p>\n\n\n\n
You still learn new things as you write the code, of course, but you\u2019re now better prepared to handle those things when they pop up. You even have a good idea about the kinds of that might present themselves.<\/p>\n\n\n
Styles make more sense<\/h4>\n\n\n
As you plan the work, you can truly figure out which styles are global, which are section-specific, which are or component-specific, and which are one-off exceptions. If you don\u2019t already have a system you like for this, Andy Bell\u2019s Cube CSS<\/a> pairs very well with the kind of breakdown I\u2019m talking about. Here\u2019s a video<\/a> of Andy working through an example with Chris Coyier that you can check out for more about this approach.<\/p>\n\n\n
Accessibility starts early in the process<\/h4>\n\n\n
- are totally new, but the path is obvious and safe (predictable<\/strong> dev time needed),<\/li>
- Header nav\u2014<\/strong>This is an expanding hover nav that needs JavaScript to work correctly. There are probably lots of accessible examples to follow, but still will take more time to develop and test than if we were working with raw links.<\/li>
- Header home link\u2014<\/strong>Woohoo, it\u2019s just a link and we\u2019re done.<\/li>
- Within Header<\/strong> there is:
- Top-level structure:
- Element-level patterns<\/strong>\u2014headings, text sizes, fonts, spacing, icons, button sizes<\/li>
- Layout-level patterns<\/strong>\u2014repeating layout ideas and the overall grid<\/li>