Our human minds love to put things into boxes. We strive to categorize, organize and streamline. In the development process, we have attempted to break the steps of creating software into “logical” parts as though the dev team where musicians in an orchestra that could be arranged in an ideal manner to best suit the conductor. Having been part of many teams where this categorization occurs, I can say safely that this approach is destined for disaster.
Why am I cynical about an approach that has thousands of books, articles, and manifestos touting its glory? I am cynical because in my own experience, categorizing people is a limiting approach to empowering creativity. I think as developers, there is an expectation that harkens back to the days of the mainframe computer that we are not interested in how things look nor should we have much by way of opinions about the matter. That is total hogwash. I am not alone, even if I may be unique, in being extremely aesthetically driven and opinionated as an engineer. Separating design from the front end development process is like separating taste from cooking or textiles from fashion. You just cannot do it and still have a cohesive product. At best you have introduced a layer of unnecessary bureaucracy.
This is not to say that we should not have flows which will determine the user experience or low fidelity mock ups which allow stake holders to grok what the product team is suggesting for a solution. What I am against, is the predetermining of every visual aspect of a feature by UX designers and then handing said blueprints off to the UI dev. What we have just done, is add a layer of complexity. A great, or even good, UI developer can take low rez. mock ups and given a set of UX patterns (already decided upon by the company or product team) rapidly build a working prototype that then can be handed back to the stakeholders for sign-off.
Why would you not do this? In our new process, we have now two steps to iterate upon rather than one. Here is how it goes in our divided system… HiFi mocks are iterated upon with product, UX designer, and stakeholders. Everyone is happy, UX designer hands mocks to UI developer. UI developer goes and churns out the feature to spec. hopefully everything makes sense from a programmatic standpoint. If it doesn’t make sense, UI dev has to reach out to UX designer who then reaches out to stakeholder/product for confirmation of change, UX designer iterates on their own design and hands it back to UI dev again. UI dev continues and when finished presents to stakeholders for walkthrough. Stakeholders find an issue or something that isn’t quite right now there is real data in the application. And…. rinse and repeat, the process starts over again.
The thing is, creativity is seen as something that stands on its own and is not in the realm of the analytical. This is a societal issue, not just a corporate one. We are more comfortable with the idea that one type of person is good at x while another is good at y. It creates a sense of security for us when every part of product development can be labeled, assigned and allocated in a safe little bite-size piece. That way if anything ever goes wrong, we can point to the piece and fix it just there! NO! Silly nonsense. Process is amazing, I love process and order. But like in nature, order and process must evolve out of necessity. They cannot be overlain like a scaffolding that will solve all of your problems. The problems must themselves be addressed and then the process will follow. At the end of the day, the dissection of the development process makes the work a lot less engaging and a lot less fun. Ironically, by trying to eliminate ambiguity and surprise, we have introduced complexity and redundancy.