How I build out a feature on the Frontend
By day I work in a company as a Senior Frontend Developer. My responsibilities include the following:
- Acting Product Owner for one Flagship Application
- Designer of Frontend UI
- Gathering requirements for new features or improvements
- Implementing features or improvements in the codebase
- Bug fixing
- Deployment
- Keeping documentation up to date
I’ll be honest, it’s a lot but I really enjoy the variety of my work and it hasn’t got to the point where it’s unmanageable. Yet. Once one has a system to help organise the work day and priorities can be clearly stated from the business side then things tend to run pretty smoothly.
The added bonus of being on the Frontend is that you actually get to visibly see the fruits or your labour.
One of my favourite parts of the job is building out new features. This is one of the main reasons why I became a developer because you get to create, design, and build things. The added bonus of being on the Frontend is that you actually get to visibly see the fruits or your labour. When you design and release a feature that makes your users’ lives better it really is a fantastic feeling.
I will write today about how I go about implementing a new feature — All the way from the moment the idea is born into existence, up until the final release of the feature.
The Birth of the Idea
All new features that make their way to your application first start off as an idea. This idea can come from a developer, a user, business or even from some random place like your girlfriend making some offhand remark.
However the idea comes about, once that idea takes hold in the imaginations of those involved in the app and it is deemed worthy to be implemented, then at that point things need to be written down.
Everyone will have a slightly different version of this idea in their heads. This is why gathering concrete requirements is so crucial if a feature is to be successful.
Gathering Requirements
Once this idea is out there you have to realise that everyone will have a slightly different version of this idea in their heads. This is why gathering concrete requirements is so crucial if a feature is to be successful.
From my experience it first requires discussions with a smaller group of people who are more closely tied to the specific idea in question. I like to listen to these people describe their interpretation of the idea out loud as I take notes. At this stage it’s just about getting something down on paper. The main gist of the idea, the essential ‘words’ and anything that is deemed important to come out of this feature.
The earlier you are in the process of implementing this feature, the easier it is to make large changes
You must be continually asking yourself ‘Why is this feature being implemented?’. If it’s ultimately to gather data then the implementation must take that in mind. If it’s to save the user’s time, then what specific parts of this idea will save time? This feature isn’t being built for fun, it’s to serve some larger purpose.
This is the time for questions. Lots of questions as the earlier you are in the process of implementing this feature, the easier it is to make small or even large changes. Write lots of notes and don’t worry about the structure at that point.
Bringing some Structure
Once you have gathered enough of this information on paper it’s time to take a minute and organise it into some logical structure. Ideally the sooner you can do this after the initial session of writing everything down the better. Not only does this give you an opportunity to go through what you have written down in your own time, it also gives you the opportunity to see if you really understand what is being requested and if you can start visualising how it could potentially look.
Be of the mindset that you may suddenly be pulled into another project for a month — when you come back, will these structured notes still be clear to you?
At this point you may be still unclear what is actually required. If so, that’s fine. Go back and have another meeting but make sure you have specific questions ready about the parts of the new feature you don’t understand.
If you are clear on what is being required, great! Make sure you structure the notes and ideas as clearly as possible. Be of the mindset that you may suddenly be pulled into another project for a month — when you come back, will these structured notes still be clear to you?
Present the Idea as You See It
One last step before the mockups start happening — have a final meeting with the people involved and present the feature as you understand it. This is more of a sanity check to make sure everyone is on the same page. This can potentially save you a tonne of time before doing any mockups or coding.
Humans are visual creatures so being able to see an idea in reality really helps people understand what will happen.
Design Realistic Mockups in Figma
Once you have these structured notes of the feature and everyone agrees with what you presented, it’s time to generate some mockups. I would definitely NOT miss this stage. The reason being is a theoretical idea spoken in words versus a visual representation of that idea can be very different.
Humans are visual creatures so being able to see an idea in reality really helps people understand what will happen. Personally I use Figma and try to make the mockups as realistic as possible. It takes a bit of time but much less time than code implementation.
I usually do mockups for the same UI through different events that can happen — e.g.
- What the UI looks like when a user presses a button
- What the UI looks like when there is a successful response from the API
- What the UI looks like when there is an error from the API
Figma is a very intuitive tool in my opinion and spending a bit of time learning the basics, structuring your Figma projects well and then showing these to users can save you a whole bunch of time in the long run and also help you implement a better feature.
Quickly Iterate
Once you present the mockups, take down feedback and make changes quickly. Present the mockups again and repeat until you get agreement on how this feature will look. Momentum is hugely important in projects so you want to keep that momentum going where you can.
Plan out the Implementation
Next up is setting expectations. Expectations are crucial in any project. You want to make them realistic but also not too comfortable. There needs to be a bit of uncertainty here to help focus the mind of everyone involved.
Business will be pushing for as soon as possible and the development team will be pushing for as much time as possible. It’s a fine line to tread. If you estimate a timeline that’s too long, then business will give you grief. If you make an impossibly short timeline the development team will berate you.
Break Down Tasks
Once the plan is in place it’s time to start the execution. This begins with breaking down the whole feature into manageable tasks for the development team. In our team we are using Gitlab issues but this can be done in any software you and your team deem suitable.
The main purpose here is to make sure the whole implementation is clear and everyone involved is aware of responsibilities for each part of the implementation.
Code the Thing
Now the fun part! Implementation. After all the planning and preparation it’s finally time to roll up your sleeves and start coding the feature. By this point it should be clear to the developers what is required. Each developer involved should be clear on their responsibility and who is responsible for other parts.
Be prepared that the user will have comments and they will probably be requesting some changes. This can be very frustrating given all the work and planning that has gone into this feature so far.
Deploy to Staging and Gather Feedback
In an ideal world you want to have a staging environment or something similar where this feature can be deployed for testing. This is a great opportunity to show your end users and gain valuable feedback.
Be prepared that the user will have comments and they will probably be requesting some changes. This can be very frustrating given all the work and planning that has gone into this feature so far. However, if you accept its just part of the process and you are expecting it then it won’t seem so bad. Trust me.
Hopefully at this point, the feedback given won’t require too many changes. If they are then I would strongly encourage you to take a good hard look at your planning process. Something must have gone seriously wrong along the way and you want to do your upmost to avoid this in the future.
Iterate
Take the feedback given and iterate. Like I have said, hopefully the changes requested will be relatively minor so you want to implement these as soon as possible. Keep the momentum high and keep the excitement of this new feature fresh in your users’ minds.
Release
You’ve done all the hard work. The gathering of requirements, the planning, the coding and the iterating. Now it’s time to release your feature to your production environment.
Depending on the usage of your application the timing of the release may well be important. There is also the question of whether to release this to a selection of your users at first and gather various data.
There are many strategies about releases and I won’t get into that here. The main thing is the feature is released, an annoucement is given to the users and it’s closely monitored upon release.
Conclusion
Building out a new feature on an existing application of size is a difficult process and there is a whole host of things that go into it other than the actual coding.
The scope of this process will vary depending on the size of the company you work for. Responsibilities will also vary depending on the type of team you are a part of.
The main elements of this process are to document requirements thoroughly, plan properly and implement quickly. If you follow these steps I’ve written above I can guarantee the feature you release will be successful.
About me
I am a Frontend Developer working mainly with React and Typescript in my day to day professional life. I love exploring new tools and libraries and love the Javascript Ecosystem.
I like to write blog posts that share exciting new tools I’ve discovered, how-to articles and also the occasional opinion piece.
I live in Prague in the Czech Republic with my family.
Check out the original blog post on my blog.
