After 4 months creating an app of my own, I learned a lot on using React to build both web and native app products. I took the experience seriously and went through all the processes a developer might go through when creating and maintaining an app. The most crucial lessons weren't on using the framework I’d chosen, but coding in general.
I took away five key insights, which I believe are worth sharing:
Insight 1: Even though something can be done... doesn't mean it should be done
There's more to coding than getting something to work as intended. Developers also need to ensure the code can be efficiently maintained. Even though a complicated design might be feasible, it could also make maintenance much harder, resulting in more errors, higher costs, and a worse customer experience in the long run.
Insight 2: Developers don't know everything there is to know about coding, and that's alright
Expecting a developer to know everything there is to know about the codebase they work on is like expecting a native English speaker to know every English word. If you need a developer to give accurate information, you need to provide them with time to explore the code. You shouldn't expect them to hold all the answers in their head, then hold them accountable when they turn out to be inaccurate.
Insight 3: Regardless how well code is written, at some point it will fail
Insight 4: Code isn't reusable by default so if it needs to be, plan ahead
Even if a component already exists somewhere else in your app or website, this doesn't mean it can be easily replicated where you want it next. For that to be the case, it needs to be created as a reusable component which tends to be more complex than creating it for a single occasion. This means a developer is unlikely to create reusable components without good reason, so let them know if that's what you need.
Insight 5: Last-minute design changes, no matter how small, are hard to manage
Updating code doesn't only mean changing code that's already written. It also means re-testing to ensure a change doesn't break something else, and getting the code re-reviewed by peers. Without this, we run the risk a small change may lead to significant issues once a product is released.
Why you should bother with all of this
As designers, we naturally focus on catering for our end-users. However, we should also bear in mind that the first people who actually use the designs we propose are developers. Building more empathy and understanding for their work helps us create the best solutions for the customer and make our developer colleague’s lives that little bit better.