Drawing the line where your project starts and stops
A quick thought on project process from a designer’s point of view. Please add your thoughts and comments.
We set a kick-off date and deadline as the public release date when we plan a sprint, following on with middle and long term strategies. When we see the sprint planning through a telescope, there are two parties inside. One side is a group of people who build the product, and the other side is the stakeholders or clients. The builders have agreed to the plan and what they have to work on for the next two weeks. However, the other party often realises around the middle of the sprint that they want to change requests which likely includes re-working or re-prioritising the different tasks.
We are all familiar with the development cycle (discover — design — build — test) which should be flexible and adaptable for requests, however, the team is reluctant to change because the proposals may affect the entire project from coding to the customer experiences.
For example, you are looking at a map, you know where you want to go, and we decided how we get there from here. We have to consider things like when we want to get there, on what obstacles we have to overcome to get there. The strategy may change along the way depending on the circumstances. As long as we have that vision, professional team members can guide and find ways to get “here”.
The same things apply to the product process. Ideally, the project process should be flexible enough to adapt the changes, however, we draw the line; small tasks needs a start and an end of the process. The additional requests can be listed later (continuous iteration). However, we review why the additional request has arisen and what impact it will have on the rest of the project. We may have missed things when we planed.
Continuous iteration has a start and end that good enough moment, but we want to keep the level of “good enough” should be near perfect. We learn and experiences when to draw the line and improve the level of “good enough” as a team. So we tend to take short cuts, which will carry risks for later on.
As a designer, if the client wants to change a part of the content, even some additional text, it may cause significant issues. That is why we provide a prototype with the expected outcomes to avoid last-minute changes. Drawing the line periodically that can inform the client of customer insights with numbers. Designers would be able to know the causes of what went well and didn’t go well.
We must know where to go at the end of the journey. How to get there is the key to the project.
Plan well.
