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?

  • "developers" can cover such a wide range of skills
    – obelia
    Jan 25 '13 at 21:26
  • The term "developers" can cover such a wide range of abilities the amount of flexibility or influence allowed should vary with the specific group. IMO a formal "handoff" from design to development only works for simple things. More complicated things require more interaction between all specialties throughout and multiple design/development iterations to get right.
    – obelia
    Jan 25 '13 at 21:37

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:

  1. Developers should be given flexibility to change/improve anything that ultimate benefits the user experience.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.