Good product first, refactor JS after
A self reminder on the complexity of user interfaces.
User interaction is hard to predict (as of now). In many cases, the frontend engineer is the very first person that sees how humans interact with the product. There is a good chance an issue like the one above does not get caught during the design phase of a product. Issues such as this can come in many shapes and sizes.
Users can trigger unaccounted interactions. Scrolling the body when a dropdown is open is a simple example. Resolution for this type of issue is not trivial. One could think to block the scroll on the body, however, that can result in hiding the scroll bar and causing the entire page to shift to the right, which can be a bit unpleasant (there are ways of blocking scroll without hiding the scrollbar, however, those can result in tricky side effects).
Data can differ from what was expected at the design stage. Designing whilst considering worst case scenarios (for example, many timeseries in the graph above) and variance in the data is key, however, that might not replace working prototypes. These type of problems can show themselves as simple ‘divs’ overflowing, or can become harder to solve as the data becomes more complex. For example, when working with data visualizations.
Although the frontend engineer does not usually spend a lot of time wireframing and thinking about user flows, designers might need to tweak interactions as they see room for improvement, eg. ‘we need to make this feature more discoverable’.
Embracing dead ends
The cost of changing strategy and code is directly proportional to the investment that was made into it. Forget React. Forget Angular. Forget jQuery. Don’t spend > 60% of time devising code architecture until you know you know your solution is going to work with people.
A better approach is moving fast until a working solution has been found. It’s okay to have a bit of subpar code for a while, as long as the code will be refactored before release.
Refactoring and delivery
When a good approach has been verified to work, dedicate time to code consolidation to avoid tech debt. Clearly ‘the product looks good right now, why do we need more coding’ type of fallacies have to be avoided, product should not be delivered until proper coding work has been completed.
Conclusions
In the future, prototyping tools will have the capability of emulating more complex behavior, until then, it’s the frontend developer’s job to adventure themselves to the maze of ‘this dropdown here might work’.
As a frontend developer, always assume the original plan might not work as expected, you will hit dead ends. Don’t invest up front, don’t plan the perfect architecture and code without making sure your solution has a high chance of success. Prototyping is key.
Humans and data are hard to predict. Embrace it, account for it. Happy hacking.