Table of content
- Look for similar solutions
- Mobile-first
- Happy path, alternate paths, and exception paths
- Loading states and animations
- Different Browsers / Devices
- Logs and tracking
- SEO and accessibility
- UX validation or QA validation
- Linter
- Unit tests
- Audits
- Documentation
- Conclusion
I’ve heard too many times “It’s done”, “That’s easy”, “I can do it fast”, “It doesn’t take long”. Most of the user stories are bigger than we think and I think if you want to be a good developer it’s important to do code maintainable, legible, testable, usable, traceable, and so on.
So, I want to make a list but I’m not going to dive too much into every point because every one of them could be a whole book. Anyway, I think it’s important to have a general vision and there it goes the list of the most important things that I do during the process of developing a user story as a front end developer:
Look for similar solutions
First of all, think about the solution and try to not start coding at the first moment. Ask your teammates, Google or Stackoverflow for a solution to your problem, share and debate that solution until it seems the final one. Do not reinvent the wheel!
Mobile-first
I’m a huge defensor of developing using a mobile-first approach, but this depends on the project you are or the type of website you are making up. Here the Chrome DevTools is your ally.
Happy path, alternate paths, and exception paths
I always focus on the happy path, because that’s what 90% of the users will see and it’s important to have it well tested. But you should keep in mind different approaches that the user may take. Also, you should be prepared for every request to fail and give the user the most accurate answer to the problem it may occur. I think this depends mostly on the developer’s way of think which indeed should think like the machine (just for this case^^).
Loading states and animations
One thing that gives very usability and a better user experience is the loading states. When something is loading or the app is doing anything, it should inform the user with a loading status. When you have developed the whole functionality of the user story, give this a try and see if you need to add loading states somewhere. Don’t forget about animations which can be awesome for the user experience.
Different Browsers / Devices
Always test your website or application in different browsers and give support to the three or four most used. We all know there is a chaos of having different browsers or devices and multiple versions of them. Here you can use some tools like Browserstack or Browserling that can help a lot. I’ve searched for the most used browsers and here is the answer:
Also, check your analytics to see what are the most used in your case.
Logs and tracking
It’s very important to track the user with Analytics or other data tools, pixels, etc… But you should be using Sentry, Datadog or a similar tool to know what is happening exactly in your application in real-time. Every error that may occur should be logged and then tracked until it’s solved. Don’t forget to think if you need to implement a new event or log for something. For example, you may need to log if the user filters an important list and there are no results available.
SEO and accessibility
One of the most important parts of a website it’s related to its accessibility and how crawlers understand your markup and content. Always remember to apply SEO and accessibility concepts in every part of the website/app that you are creating or modifying.
UX validation or QA validation
One thing that I like to do when I think the user story is ready, is to check everything with my designer in case we have one, or ask for a QA tester who give us feedback. Always be receptive and self-critical. For me, it’s impossible to do everything perfectly for the first time, and you will need to correct some things, that’s completely normal!
Perfection is impossible; just strive to do your best.
The next points are part of the continuous integration cycle. I would like to list here some things that we do at my current work and I think they are important:
Linter
Always use a linter. It’s important all the code to look the same and the whole team to have the same rules.
Unit tests
Tests, tests, tests. If you want to be a senior developer or at least try to be so, please, test everything you can. We all know that documentation and tests are the last thing, but for me, it’s a must. Check the coverage and try to reach at least 80%. There are two types of tests that you can do, unit tests or e2e tests and both are important. Here, you can use a tool like Sonar, Codacy, etc.
Audits
I would like to mention Google Lighthouse and the tab Audits in the Chrome DevTools.
I know there are more tools over there, but this used with Google PageInsights is a really good combination. Check your new code against it and see if some adjustments are needed.
Documentation
This is the most difficult one, but do it!
Reserve some time to write an article or page in Confluence, Nuclino, MediaWiki or whatever you are using. Focus on things that would be helpful to know if a new developer arrives at your team. Most of us can read and understand code, but workarounds and complex functions or architectures are not as easy as you may think.
Conclusion
Not all of these checks are mandatory for every user story, maybe some of them do not apply but keep in mind all of this when you have to estimate!
In order to not forget some of them, you can create a checklist for every user story with the ones that have to be in or put them in the definition of done of the user story.
Also, be careful saying YES all the time to a product owner because we all know they always want more and it will eventually turn against you. Evaluate what are the new requirements and ask other teammates for their point of view.
I hope you have learned something new. If you think this might help other people, please hit the like button so that others can read it. ❤️
If you have any thoughts or questions, feel free to leave a comment!
Top comments (6)
Good post. I want to add a 13th:
Read the documentation
I don't know how much time I have lost because I skimmed the documentation when I had to read it. Even if I only wanted a small thing initially. Later, I Googled what I wanted, only to find it in the middle 5th paragraph of the docs.
+1 on this. A lot of newer devs seem to want to be spoon fed😀
Hah, if only was "newer devs"...😀
I really stress on Do not reinvent the wheel!
Because web is a terrible application platform so you start to need modal, native like sidebar, drop downs, carousel sometimes, formik (if you use react), grid system in every single project.
The post is great, I like the way you have expressed it and the ease in explaining the procedures, in addition to mentioning several tools that can help anyone start and investigate.
I would emphasize the part of making not only a good code but a useful application for users who are going to use it and I think you've made that clear, it is not about going to throw lines and drink a few coffees, but to do the work with passion and knowledge thinking of others, from your peers to users.
Congratulations! and thank you for sharing it.
To the testing, I would add Integration tests using API mocking tools.