Task: Continuous App development
Refining the the app can be broken down into the key journeys. Each of the these journeys carry a number of key performance indicators for the business and areas of focus and interaction for the customer. Balancing these two areas is paramount to fulfil the journey for the customer witht he least friction as possible but at the same time remaining atractive to the business.
Key Focus: Accessibility / Scalability
How might we refine the processes down further using all of the infirmation we have from our analytics, talking to the our customers and understanding where there pain points are. And further to that, how might we build it so we can then push into other markets and countries with the same plan (Agnostic product) but suppliment it with regional know-how?
Pre-sprint: Fill the toolbox
Before we get going we look at what we have already to use as a basis for our research and understanding. This includes essentials like:
Journey mapping
How do we do it now and why did we do it like that in the first place? along with user research, finding out why things have been created in a certain way is also as important. Technical restrictions and understanding how a platform interacts with all of its components will have massive impact on what can e considered in the further solution. It can also influence change in wider infrastructure which has greater knock-on costs.
Discovery: Understanding
Prior to the 5 day sprint, we decided to break the project down into the app keys components. These are Buying, Selling, Viewings, Customer account and Contact/Help. Being able to 'Sprint' on all of these seporately enabled us to focus on key areas more thouroughly and not miss any details. It also allowed us to bring the right people in at the right time which helps to spread the impact of pulling people from departments to work with us in the workshop. Nothing is off the table at this point as the base app is an iteration but with the option to factor in scalable elements that could 'change the game' going forward.
As Selling properties makes the most revenew for the company, that is the first sprint and first focus of efforts. Other factors such as customer pain are considered as part of the initial strategy so other factors are as included.
Who's involved?
Design, Developers, Key Stakeholders and directly affected teams are represented.
PO for reference
Define: Planning our direction
Having built out our understanding of the best way to tackle the process and developing an idea of what good looks like we can begin to plan how to attack what we currently have and turn it into something better. Benchmarking, comparisons and the culmination of ideas are all used to explain viewpoints and understand directions. Early stage rough design can be wireframed to explain concepts and give us a better idea of information architecture.
Who's involved?
Design, Developers, Key Stakeholders and directly affected teams are represented. Same as day 1
Development: Refinement and voting
The real fun begins. We can now work up our best and brightest and vote on them before they get put infront of a customer or user. These can actually be an amalgamation of all of the previous session from crazy 8 designs through to just absorbing something better from the group. Either way this is the time to bit a finer point on the product and vote on the best course of action moving forward. Doesn;t have to be one either, we can multi variant test the rest!
Who's involved?
Design, Developers, Key Stakeholders and directly affected teams are represented. Same as day 1&2
Deliver: Test and learn
Design would take the lead in the development of a prototype(s) of the flows we would like to do along with the our floating team of specialist to keep us honets and review the product as we go along. This way there confidence can grow as our product becomes real. We can then test it and share the results and analysis!
Who's involved?
Design, PO, Key Stakeholders and directly affected teams are represented (to review only)
Review: Synthesis of feedback and off we go!
We have our buy in from our teams, we have feedback from our customers to help shape what we are doing and we have the design. So what next? We begin developing the super hifi designs with all spec documents and accurate Ui in preparation for the build and assimilation into the product.
So what happens if the customer research comes back negative?
We have the sprint format for a reason. Up until now we have only spend a couple of weeks exploring the research, analytics and planning our direction, we can look more closely at the areas of failure and go back to discovery to hammer the problem out. It could point to the direction being wrong or even the possibility that we have to look elsewhere for the 'win', but atleast we have found this out now and not while the product was in flight.
Will we learn it all at the test and learn stage?
Short answer NO. This is the first step to allow us to launch a product and begin to learn from it in its natural habitat. Failing fast to allow us to build on this solid understanding is part of our process so we aren;t affraid to be proved wrong as it pushes us closer to the right answer.
Who's involved?
Developer, Design, Key Stakeholders and directly affected teams are represented (to review only)