Developers often presented with the problem followed by complete UI design or specification, which, beside the original problem, often covers additions which might improve overall user experience regardless the level of importance.

Taking entire design as a “hard” requirements leads to the big upfront design (longer planning meetings, breakdowns, etc.), and it is not a secret, that big upfront design leads to the design (OOD) complexities, misleadings and delays.

The problem is that it is quite easy to take design as a “hard” requirements.

So, here is simple steps which could increase efficiency and reduce time and complexity when applied iteratively:

• Identify which part solves the problem and IGNORE the rest, for example: for blog it is ability to create new page and NOT settings;
• Deliver solution ASAP (something to show each week would be best);
• Repeat the process for what left from original request.

Developer? “Ignore” means “Ignore”, i.e. focus on the problem you solving this week and don’t even try to make design decision based on anything else you saw in the specs or UI design. For example: “I’ll create this table because it will be required for …” or “I’ll make further normalization because there will be association with …” or “I’ll move this function to the Post class/model, because it will be also used in …”, and so on. Just don’t! :)

Benefits:

• For developers: better understanding of the problem
• For business: confidence
• For users: proper solution

P.S.

It doesn’t mean that feature won’t be implemented as designed or described in specification, but by following incremental steps we’ll continuously proof that implementation not only fits the requirements, but also solves the problem.

P.P.S

Incremental, short step, process is easier to control and even do some analysis, for example to learn how far we’re from the goal.