Agility In Design
The overall design and user experience have a much greater precedence in web development than they do in traditional software engineering. In this era of “Web 2.0”, agility in design is essential to the success of any web application. As much as it pains me to stake this, as a developer, but we all know that visual effect amount to going on for 100% of initial impression.
It Human Nature, we just can’t help aesthetic judgement.
When leading projects, this poses an additional consideration in planning for the development lifecycle.
At what stage does the design kick in?
Typically, development can be driven by design. If all of the designs are produced up front, it can lead to lost time from the development team in fixing issues caused during development. However, if the designs aren’t produced until the end of the cycle, it can lead to scope creep, additional features expected by designers that have not been created by developers as they were not part of the initial scope definition.
As an alternate, design can become a part of the sprint process, if you are being agile about it. Though this can lead to a combination of the above issues, but with a much smaller feedback cycle. This is ideal as it can lead to hidden, un-scoped features being made transparent, though can still eat up a lot of development time when the functionality calls for a change in design, or vice versa.
Agility In Design is an essential part of web development, if working to a set design. But the Agility must come from all of those concerned. The development team can’t expect the design team to change everything for them, and the design team cat expect that of the development team. Everything must work well together and compromise must be given, where warranted.
There is a third approach, which is one being used on the current project I am working on. Design and Development are running simultaneously, with a development team and a separate design team. The design’s scope creep is rejected, with only agreed on features and functionality being delivered, and the development team don’t have to tread carefully around the implemented design.
This is made possible through a template design approach. The systems templates will change over time, through any number of implementations, and we are reacting t this early by ensuring we develop without a UI, so it can instead be supplanted into the finished project, in multiple forms over multiple instantiations.
To me, this is a better defined Agility In Design. The system does not care about or rely on it’s aesthetics, which can be easily adapted around the functionality.
New functionality required by new designs goes where it belongs, into a prioritised backlog of work, and scope creep ends up where it belongs, in one of the many office bins.
Whilst this approach is, to date, working brilliantly within our team, It may not necessarily be the best approach for all projects. Every project is different, as is every team, and it will always remain that the best option is to play to your strengths, making the decisions around what resources you have available, for how long, and the skillset encompassed within.
I will consider this approach in future projects, but as for it’s success, only time will tell.