A Designer who specifies every detail of the UI to such a fine level of specification that there is no leeway for developers to choose alternative implementations that can reduce development time.
- Can mutate into: “The Disenfranchised” Designer
- Dangerous when coupled with: “The Patent Author” Product Manager
- Likelihood of fixing: High
- Danger to project: None
Problem
Detailed requirements are important for knowing what to build before you build it. However, a huge amount of efficiency can be gained through collaborating with the development team as to alternative user interfaces that are easier to implement, or can be implemented using preexisting or third party implementations. The Blueprinter has shut down this collaboration by giving the developers no leeway in choosing alternate UI solutions that would save development time.
At the heart of Waterfall methodologies are detailed documentation of requirements. The thought is that with every detail thought out well in advance, there will be little wasted effort, as once a solution is implemented, it is implemented to specifications and therefore completed. This repeatable and predictable process is coveted in large organizations.
However, allowing developers to implement UIs different than those specified can lead to a massive savings in terms of cost and time line. There are a multitude of UI components and libraries that are easy to drop-in and configure, saving both development and testing time, as well as effectively outsourcing maintenance and upgrades.
The Blueprinter often does not appreciate the difficulty of creating non-trivial UI components from scratch. When there is truly a need for a novel UI, as there is when creating competitive differentiation, then this work is unavoidable. However, in many instances, compromises can be made to line up the requirements up with preexisting components. If The Blueprinter refuses to compromise on their requirements, the project has potential to be many times more expensive to develop than it has to be.
Solution
Thanks to the detail of requirements coming from The Blueprinter, the project is perfectly predictable; resulting in them being no risk to the project’s success provided adequate budget is allocated to implement the entirety of the UI requirements. Most Project Managers would love to have The Blueprinter designer on staff for the predictability they can provide when coupled with developers who are able to deliver features within the estimated time and budget.
While The Blueprinter does not pose a risk to an adequately funded project, they do have the potential effect of needlessly driving up the cost of the project. The difference between the cost of assembling a UI from pre-made components, and writing the components from scratch to meet detailed requirements can be staggering. Additionally, writing the components from scratch can significantly delay time-to-market, thereby incurring an opportunity cost.
If one wishes to fix The Blueprinter, one only has to ask them to compromise on their requirements for the sake of the project’s time line and budget. It is unlikely that they will refuse to do so, but can at times happen (see “The Professor” designer).