We often see that requirements talk about fine nitty-gritty details that takes away the flexibility from developers from doing things the right way [keeping User Experience / Usability].
Like for example, placement of buttons, white-space in tables etc.
If I were to provide a list and say this is what developers should be given flexibility to do, what would that list be?
If I were to provide a list and say this is what developers should be given flexibility to do, what would that list be?
My extensive, exhaustive, comprehensive list would be:
The problem is the requirements, as you hint at. Requirements, IMHO, should never specify anything other than BUSINESS or USER tasks/objectives. Once requirements start labelling buttons, or positioning icons, or specifying particular UI elements, they break the entire design process.
As such, I really prefer how Agile tries to encourage 'user stories' over requirements. Ultimately, the design process (be it via UX wireframes or dev code) is where a lot of requirements come to light.
Developers shouldn't be expected to make UX decisions, just as UX designers shouldn't be tasked with writing code. And QAs shouldn't be expected to just 'guess' at the acceptance criteria - as a former tester, I can't tell you enough how important it is to have well-defined requirements.
Requirements need to be specific and unambiguous, but they need to be readable also. The easiest way to serve these two goals is to provide visual mockups, and employ re-usable widgets throughout your UI that can be referred to with shorthand, meaning you don't have to describe the exact look and behaviour of page components from scratch time and time again.
