Definition of Done for front-end tasks

You’ve got a task. You know how to implement it and where to start, but when can you tell that it’s finished?

As usual for the front-end, the answer depends on each team and each task. For me, I’ve created a list of questions and recommendations for each positive response. In this article, I will share those questions with you.

Photo by Glenn Carstens-Peters on Unsplash

Do you have any markup in your task, or do you need to do some redesign?

You need to change the HTML (or JSX) or CSS of the page, component, module.

• [accuracy] Your markup needs to match design — colors, fonts, vertical and horizontal rhythms, images — everything needs to match.
• [responsiveness] It doesn’t matter if you use a mobile-first or desktop-first approach — try your markup on different screen sizes; it should not break.
• [semantic] Your HTML should be semantically correct, and it means you should use buttons when there is some click action and links if there is a redirect to another page, etc.
• [dynamic] You need to style hover effect, highlight focus, or active state of elements, set font fallback to make your design alive and intuitive.

Do you have any internationalization or localization?

You need to support more than one language. You have locale-specific components. Or simply — you have text.

• [translation] All text should be translated; if you have right-to-left (like Hebrew or Arabic) and left-to-right (like English or Russian) languages, you need to check the layout with both cases.
• [formatting] You need to transform data that is not readable for a user, for example, dates (timestamp 1582644492199 or UTC “Tue, 25 Feb 2020 15:28:12 GMT”) or big numbers (2500100000).
• [locale-specific-data] Locale-specific data should be readable for each user, for example, money (15 is it $ or UAH?), weight (50 is it kg or lb?), decimals (is it 2.5 or 2,5).
• [plurals] You need to use correct plural forms. For example, “2 day” sounds weird.
• [spelling] You should check if the text is correct.

Do you have a process that takes time to handle?

You need to interact with the API. You need to load some heavy resources — scripts, styles, or images. You have a process that takes some time and can block UI.

• [loader] You should indicate the process of loading or long calculation so the user knows what’s going on. Usually, the loader is a good choice to show that.
• [placeholder] If you want to minimize content jumping, instead of the loader, you can use dummy placeholders, for example, for images.
• [submitting] When you need to save data, you need to indicate the process and disable anything that can break that process. For example, show loader and disable submit button. Then, after it’s saved, enable the button and hide the loader.

Do you need to load resources?

You have images, fonts, styles, scripts, or some third-party services.

• [images] You should compress images: JPG, PNG, SVG, or you can use npm packages for that. Consider different screen resolutions and use corresponding image sizes.
• [fonts] You need to choose a font loading strategy, reduce font file size, and load only needed font families.
• [scripts/styles] Clean your code — remove dead code and comments in the production bundle, use chunking for big bundles, split and load only needed code, for example, only desktop or only mobile files, minify your source code.
• [optimization] Use lazy loading, prefetch/preload, defer/async for resources loading. But be wise, always check if it really helps, don’t do optimizations if you don’t have problems.

Do you have a user’s typed data?

You have a form or a single field where the user should enter data, for example, date-picker, text field, or file uploader.

• [validation] You need to validate the user’s data before sending it to the back-end. If there are any invalid data, you should show an error message and highlight the exact field where that error happened (or according to your design).
• [mask] You should add masks for fields that need formatted data (for example, phone number or email).

Do you have back-end integration?

You work with any kind of API, it could be your back-end service or any third-party service, for example, analytics or advertisement.

• [error] You always need to show if something goes wrong. Any service can respond with errors, and the user should know the result of their actions and know the reason for an error.
• [validation] You should show and highlight back-end validation errors as you do it with the front-end validation, show the message and highlight the field.
• [placeholders] If the result of your request should be displayed, but the server responded with the error, sometimes it’s better to show a placeholder instead of just hiding everything. For example, on a search page, instead of content, it’s better to show the message “The server responded with an error, try again later” instead of the empty page and popup with the error message.
• [details] A readable error message will help you to fix the problem, so try to be clear and don’t use “Something went wrong“ messages a lot.
• [requests] Try to minimize the count of your requests. Sometimes it’s better to speak to the back-end team and change API instead of sending a bunch of requests. Don’t send unnecessary data, and try to reduce the size of your requests.

Do you have some data you don’t want to lose after reloading the page?

You have pages, tabs, modals, important forms, countdowns, or any kind of blockers, for example, “Send SMS” button.

• [location] It’s better to use URL params to save the user’s location, so after the page reload, they get the same page, open modal dialog, or the last open tab. You can save such data either to the localStorage, the sessionStorage, or the URL (query parameters or hash).
• [data] You need to save important data — authorization token or big important form user started to fill. You can save such data either to the localStorage, the sessionStorage, Cookies, IndexedDB. But be careful with sensitive data — always have in mind the security of your users.
• [blockers] You need to save any data that block UI, so the user can’t break the app, for example, can’t send SMS too often, or can’t write comments if they were banned. Always have in mind the security of your app. It’s better to use a URL for such data, so if the user tries to open the page in another browser, it won’t break your blocking.

Do you have a big bunch of data?

You have lists, tables, or any sequences.

• [pagination] If you need to show a lot of information, it’s better to add pagination or infinite loader.
• [filtering] It’s a good practice to add filtering or sorting to manage a big bunch of data.

Do you have different pages or different states of application that the user would share?

You have a search page, pagination or filtering, CRUD pages for any entity or any other state of an app your user will share.

• [routing] You need to create convenient routing. It’s great to use the RESTful API convention to have consistent routes.
• [state] You need to save the state in URL, for example, search=abc, page=4, #loginModal In such an implementation, users can share an application state, not only the page.

Does your team write tests?

• [unit] If you have some tricky logic, it’s better to cover edge cases with unit tests.
• [snapshot] If you have dynamic UI, it’s better to cover such cases with snapshot tests or screenshot tests (which are more complicated and less fault-tolerant). For example, your form has different fields for different users.
• [e2e] It’s best to cover the main functionality with E2E tests, for example, CRUD of some entities.

Does your team write documentation?

It’s great when you have self-documenting code, but it’s not always enough in the real world.

• [UI] For components, it’s better to use some services like storybook or styleguidist.
• [feature] Feature/page documentation may include links to User Story related to the task, design mockups, and API endpoints documentation. Alongside with description of complex parts of logic, strange unintuitive decisions, and unusual behavior. Examples: “Login page,” “Settings Widget.”
• [tricky-logic] Some decisions which you made during the development are not always clear, and those decisions need some explanations. Examples: “Localization in the app,” “The render of salary diagram.”
• [how-to] The most helpful documentation answers your questions. That’s why documenting answers to common questions is an excellent choice to do. Examples: “How to perform a release?”, “How to test the app?”, “How to connect API?”.
• [infrastructure] Documents about the structure of your project, your team, and your working process is a great starting point for new developers. It can contain valuable links, schemas, and checklists. Examples: “Repositories,” “Branching strategy and naming,” “Onboarding.”

Conclusions

This list isn’t mandatory or even 100% complete because only you can decide what is best for your team or your projects. But I hope it can be a good starting point for your own “definition of done.”

I’ve probably missed something, so if you have something to add, please, leave a comment.

Thanks for reading so far!
See you next time! 🤹🏻‍♀️

Солов’їною:

Definition of Done для фронтенд задач