Instead, I’d like to tell you what can happen when you combine a good idea, curiosity, trust, a healthy culture of error-tolerance, and a motivated team, and stir them together in one pot. To do this, let’s look at how this recently worked with a concrete project. I’m not telling you this as a business evangelist, a top-level manager, or a theorist with raised index finger, but as an operative digital aficionado – a Ray Sono UX consultant who has already been involved in so many agile projects that I wouldn’t want to work any other way. I’ll also give you concrete examples of what I’ve learned – and how this might help you.
The project
It’s about nothing less than a web app that wants to turn the automobile-driving behaviour of users on its head: the eMobility Coach from E.ON. And it’s in Danish Elbilguiden, because this web application was first developed for the Danish market.
The web app shows each user how switching to electromobility can affect their daily lives, their finances, and the environment – with concrete, manufacturer-independent vehicles and recommended actions. In addition, it lets the user set up a free, non-binding test drive with the vehicle of their choice.
The briefing: a dream! It consisted of an idea, the vision behind it, a first scribble and a few relevant insights. The mission was as clear as motivating:
Let’s work together on this idea for 100 days and see what comes of it!
These are the best prerequisites, as seen in the examples of a “How-To-Agile” guide. But a good start does not always lead to the right goal. Why were the following 100 days so radically efficient, massively inspiring, and in the end, incredibly successful? Here’s the answer:
Five things that made the eMobility Coach project a success:
1. Teamwork – now!
Teamwork is THE prerequisite for agile work. Everyone works on the same thing at the same time. This means they must always know what the other team members are doing.
This applies to all the company divisions and in all directions. Hierarchical client-contractor relationships and competition among many service providers are the death of a project. Functioning team play with all available soft skills must be learned – but it also brings a lot of returns.
2. Good ideas develop from diversity
I’m reluctant to use the term “innovation”. But when teamwork goes really smoothly in agile processes, the result is what the prophets of Design Thinking preach even more than strict Catholics say the rosary: diversity! Diverse perspectives and diverse ideas. And the path it takes to get there can be quite varied. Agile frameworks, after all, are also a great playground for applying methodological practices. That’s why every stock photo on the subject is packed with maps, canvas, and post-its.
At this point, I want to make a confession: In joint settings, I have always achieved far better results than I could ever have gotten alone as a concept consultant. In addition, this process has always gone faster and without subsequent presentation and discussion among colleagues and clients. Because everyone was involved from the outset! This makes things go even faster. It’s a win-win-win!
In addition to a huge number of ideas, optimisations, and proposals, without the swarm creativity, our E.on project would have never resulted in this integrated mathematical model which is now used to calculate the individual scores and provides users with really relevant results.
3. We are all UX designers
The rules of the game are simple: Everyone can throw their ideas into the ring, every opinion is equal, we develop the product together. And we are jointly responsible for making the whole thing work.
UX is therefore not only the task of the “official” UX designer. From the user’s point of view (around whom everything revolves), the experience with the product is the sum of everything that even remotely has to do with it: added value, usability, content, implementation, connection to other touchpoints... etc. etc. etc. To achieve this, the entire project team must be aware that all these factors function. Product ownership must be a collective mindset.
This does not mean that there is no longer any need for an UX expert. Detailed concepts of really complex issues – those that require the highest concentration – must still be created. But as far as exploration and development of basic interfaces, user flows and ideas are concerned, the principle of diversity applies.
4. Testing is not an option
Testing is mandatory! When it comes to tight timing or budget, testing is often the first item that people want to leave out. Favourite question: “Why does it need testing? You’re the experts!”
The problem: Even when we’ve used established mechanisms, this is far from a guarantee that they will lead to success for every product. Every target group is different – just like expectations on the product – and the clock is ticking – because of technical progress, because of rising demand, and because the ever-alert competition is also constantly on its toes! This is why existing approaches must be challenged over and over again. In addition to making certain we are on the right path (or not), the target group during testing usually dictates helpful optimisation suggestions directly into the backlog.
Within the 100 days of the eMobility Coach development, we tested it three times.
At every development stage, we obtained valuable findings from this – because “real” users see the whole thing with different, and above all, with fresh eyes.
Well-organised testing does not have a major impact on speed and dynamics – quite the opposite. The findings from testing sharpen our focus and make our work more precise.
In the end, testing led to the fact that we could release our product in good conscience – even with the knowledge that it could still be improved.
Testing is an elementary development component if a product is not only to be finished, but also to be truly meaningful and fulfilling.
Speaking of finished:
5. Just do it!
The product is never ready! Giving it to the target group is just the beginning. Insights, performance, research, new ideas, changing requirements, competitors who are quickly catching up, new technologies, security gaps … there are many reasons for changes.
Especially during initial development, it may be that the backlog fills up faster than it can be processed.
The danger of this is that the go-live is shifted further and further back, the highly ambitious team goes over and above the target and therefore never finishes. Honest failure.
The solution: don’t surrender to your own perfectionism – think more about the joy you’ll be giving your target group. Just start an MVP – minimum viable product – and successively expand upon it. As soon as the product adds value, is easy to use, has no more significant bugs, and of course fulfils all security needs, just let it go! Perfection is definitely a laudable ambition – but it sometimes just gets in the way.
In this case, transparency is the alpha and omega. If you openly communicate what is still missing and planned for future releases, users will be gracious.
Even better is the integration of a feedback option. These are not used excessively, but when they are, someone has really put some thought into it and is providing you with valuable input.
By the way, releases in short intervals also open a good space for experiments. Optimisations, new features, or A/B testing for additional insight can be easily switched on and off.
Last but not least
I could give you many more arguments. But the most important one can only be conveyed in practice anyway – working in agile teams is a lot of fun! This is not only great, but also the best condition for the best results.
Sascha Köhn is a Senior UX Consultant at Ray Sono and as such is only satisfied when there is a purpose behind everything.
You want to learn more about Ray Sono? Get in touch!
_v01.png)
