The business value of elegant design

The business value of elegant design | MS Tech News

The business value of elegant design | MS Tech News — Mon, 03 Nov 2008 11:47:07 GMT

PingBack from http://mstechnews.info/2008/11/the-business-value-of-elegant-design/

re: The business value of elegant design

Ali Sanaei — Wed, 05 Nov 2008 23:31:07 GMT

Great points. Had to check what IMHO is.

Would be good if you give few practical SharePoint examples as well (for beginners like me!).

re: The business value of elegant design

Steve Rose — Mon, 10 Nov 2008 10:51:58 GMT

My experience differs: I do not see demand for a new version as based on discontent. What I have seen is almost the opposite: the better the application (especailly in feel) the more users actually the application, and the more requests for change we get.

I see requests for change as a sign of life!

I agree with your initial proposal: use of creativity brings us to better applications which have more value - but I would measure the value in increased takeup, and requests for change.

In the requirements space one of the categorisations I use is between "conscious" requirements, "unconsious" requirements, and "undreamt of" requirements.

- conscious ones stakeholders can tell you about

- unconscious ones a good analyst will eventually ferret out

- undreamt of requirements are the magic sauce: things stakeholders would never ask for, but which really good people can come up with.

I tell BAs that designers (you might call them solution architects) are the possibility thinkers of the process, and will come up with lots of "what-if" ideas for the project that the BAs need to help them evaluate. That's where my teams handle this creative process: not purely inside the design team.

re: The business value of elegant design

NickMalik — Tue, 11 Nov 2008 10:37:38 GMT

Hi Steve,

Some time soon, I'll blog about the difference between a business requirement and a specification item.

Until then, suffice it to say that I would not be surprised to hear about an analyst that was creating candidate designs and envisioning specification items implied by that design. The difference is important but subtle.

I do not know if that is what your team are doing, but it fits the pattern. Regardless, it is a distinction that may not have a negative consequence, especially if you have a good rapport with your customer. Agile dev teams avoid many problems caused by failing to manage the distinction between a business requirement and a specification item.

Iterative dev teams using traditional methods often mess up, especially in user acceptance testing, if this distinction is lost. Major cause of problems.

I'll blog about the distinction soon.

--- N