It Is How It Is
I have always thought of my role as a front-end developer as a support role. The applications I have developed were used internally by staff and clients. If our users encountered friction that caused disruption then it was my responsibility to address it. I found that the majority of people just accept the software issues as reality and continue to be frustrated.
I had a new coworker tell me about an issue with losing input values when a modal closed by accidentally clicking the backdrop. This happened frequently but their team had put up with it for years. Fortunately, it was a simple fix and I was able to add prop to the component and it would disabled the "feature". Within an hour, the fix was completed and ready for deployment. Pain point eliminated.
So Why The Suffering and How Can We Stop It?
Oftentimes people are too busy and unaware of how difficult the issue is to fix or if it is fixable, other tasks are just a higher priority, or worse there is no process and things don't get fixed in a timely manner when asked. We can fix this mentality by creating opportunities for feedback and demonstrate that they are heard by following through with changes.
- Whenever a new feature or workflow is released, follow up by sending out a short survey for feedback.
- Check in after a couple of months on how the feature or workflow has panned out. This can be another short survey or questionnaire.
- Ask a coworker/user about what they are working on and how they do it. Pay attention to how they talk about the app.
Creating a Process
If you want anything to stick you must create a good process that makes it easy for others to adapt and apply to their needs.
- Create documentation that covers the dos and don'ts of creating UX/UI surveys.
- Google Form templates with standard questions to set a common baseline.
- Use automation to create a follow up story when a new page, feature, or change to a workflow was deployed.
Reception
The response was amazing, it created a new way for our users to express issues, bugs, or features that would improve their workflow. The best part was that once they saw that the development team actually fixed or released a requested feature they became more invested and were more open to asking for improvements.