Avoiding shortcuts in product process
A quick thought on project process from a designer’s point of view. Please add your thoughts and comments.
Product process
I have been involved with many digital application projects for over the years. Whatever the design process you have taken, it is imperative for working with developers — the people who inject blood into the product that connects to the system and respond to actions return reactions.
Relationship with developers
I believe I always create a good relationship with developers as a designer colleague. As you may have experienced, some are not happy working with designers; those people become back-end developers from my experiences. Anyway, the relationship is essential between designers and developers during the project, or after the launch, because we keep working for BAU and incremental product improvements. The more we communicate, the fewer last minutes surprises occur.
UX designers interpret being in between the systems and customers. End customers don’t need to know how the system works in the black box. We coordinate the system with consideration for things that are “customer-centered”, “customer-needs.” We wish we could provide everything to our customers wants and needs all at once, but that doesn’t happen in real life. Designers and developers need to work together to deliver these.
It happens.
We have all experienced a project with a tight budget, tight deadline, and fewer resources. It gets even worse when the client wants to change their brief, or some of the development work takes longer than planned. In this situation, we tend to solve the problem of “now” to get through the initial launch.
The suggestion of a temporary idea sounds like it is from heaven. We all agreed to do it, and we all promised to do it correctly after the launch. Someone starts calling it Phase 2; even if no one believes there will be Phase 2 plans for it.
The temporary idea got through the first phase and is forgotten. We need to get back to fix it properly, because, after the initial launch, it gets even busier than before for bug reports and feedback.
One day, our fate brings us to the spot we implemented the temporary solution, and we barely remember why we did it or left company who made the decision. Our temporary solution has been sitting for a while because it was working. However, not any more, we need to do it correctly. By the time we realize that situation, it devours more time and resources and is costly to fix.
Not taking a shortcut in product design or development will pay off multiple times than the initial effort for sorting everything. Designers, developers, BA, PM, need to plan well. Temporary ideas or shortcuts will come back to you with more significant problems and involves more people to get the product on the track correctly.
Plan well.
