Non-fiction books can be insightful, but I have noticed that I’d expect those insights to come back to me right when they would be helpful –– like when there’s an obstacle in a project, I will have an “a-ha” moment and remember that great idea I have read about years ago. In reality, not so much.
So I’m trying something new. After reading a book, I’ll try to write down the most important stuff that could be useful some day in my digital notepad.
I did this with the book Digital Transformation Book by David L. Rogers as well, a book I’ve written about before (for an introduction of the book, start there). My notes quickly got annotated with my own experiences, and as I thought that would be valuable to share, I started to write this post.
Rogers discusses in his book the digital transformation that requires pre-internet companies to rethink their business and way of doing things. Two themes are repeated throughout, and are obviously connected: Be agile and adapt; and have a company culture that is acceptable of change. Although primarily aimed at (C-level) managers, there is definitely some good stuff in it for designers and developers regarding those themes.
In this digital age the network of customers and stakeholders has grown and become more complex. Customers are no longer passive consumers that are just at the receiving end; they now interact with the brand, the market and each other. This also means that the number of touch points in the customer journey is growing, turning marketing into a company-wide activity.
For the customer there is only one experience with the company: Using the product, visiting the company’s Twitter page or asking for support by email, it is all the same brand to the customer. All that should be in sync to such a degree that the customer will have consistent experience of the brand (and preferably a positive one).
In traditional companies where different departments take care of specific parts of the brand, it will be hard to achieve this. Those walls needs to be taken down, the silos dismantled.
What can you do regarding this one brand perspective? To be more sensitive to the outside world and more customer-centric? Quite easily actually: Work together within your team beyond your own expertise to create a great product or service. We call this product thinking and my fellow designer Ivo Domburg wrote about this earlier in Dutch.
On top of that, you can talk to people of other departments, outside of your team. Ask the people at customer service what kind of issues customers are experiencing with the product. Get to know what content is created for the website and social media accounts. There is no excuse here, you can literally walk over to the next room or floor to find these insights.
Let us zoom in on the development process. Concepts like working agile and having a culture that is acceptable of change should make sense to us as developers and designers. However, some companies or clients are less familiar with this mindset.
There are some ways to do your part to help your company or client improve on this, even within a project. Rogers describes in his book experimental processes and principles based on what he observed at successful companies, which I have remixed using my own experience into the following five principles that can guide you in that process.
Question The Assumptions
In the beginning of a project, assumptions are made and new ideas are born founded on hunches, not data. That is a good thing, because you want that outside of the box creativity. But accepting these assumptions as the truth without verifying them is just gambling the whole project on a brainwave. These assumptions sometimes become a dogma within the company –– never questioned but also never proven to be right.
Test those assumptions and various ideas early in the project and learn from them. Even if ideas are proven worthless, it could still lead to other insights and new ideas. Innovation means you wonder into unknown territories, so all you know could be worth being challenged. And this is not only true for new products but works evenly well if you are working on a new feature or improving an existing product.
Iterate From The Start, And Get Consumer Feedback Quickly
It happens quite often that weeks are spent on requirements and scoping of a project, resulting in a hefty backlog. Everything is pretty much set in stone, and it is hard to change direction if the first consumer response is timid.
Therefore it is better to bring the concept as quickly as possible to real customers to get feedback and iterate on that. And work on the main concept here, don’t linger on the details –– if the concept doesn’t stick, it probably won’t be due to a detail!
When doing this, speak to real or potential customers to get that feedback. Present your concept preferably in a form that is realistic enough for a consumer, even if it is still in the early stages. The person you show it to needs to get a pretty good sense of what the product or service is, how it could work and what the benefits for him or her would be. Not everyone can interpret abstract storyboards or wireframes the right way.
Kick-off With An Intensive
To kickstart a project without loads of requirements, we at Luminis do, as we call it, an Intensive with our client. It is short: It all happens in one day. With around five people (some designers and engineers from us and a few experts from the client, and perhaps even a end-user) we have a small and productive team. In the morning we start with the domain and marketplace, and the client discusses the potential he or she sees. In the afternoon we challenge assumptions, generate ideas and finish with some concepts or a first prototype at the end of the day. The Intensive not only helps to get us quickly into the context, it helps the client to get an outside perspective and some solutions that might work. And all within a day, making it fast and cheap. The results then can be shown to customers to get the first feedback.
Fall In Love With The Problem, And Not The Solution
Maybe the biggest reason the Intensive works is because it helps us and the client to understand the problem better – that is also why you should start with the marketplace and customer (and not that new technology everyone’s talking about). The result of the Intensive itself is used to learn more about the problem. If the project continues after this kick-off session, we “throw” away the solution and continue with the problem.
Falling in love with the problem helps you to have the right focus. It makes you consider what customers really want or are struggling with; that is where you should start. Do you already have feedback on existing products? Great, start from there. Can you observe the customer in the specific context you are interested in, even better. This helps you to see the bigger picture and it could even unexpectedly provide a solution.
Falling in love with the solution is a trap. It limits the number of solutions you consider (because why look further if the team’s really happy with the solution on the table?), so it risks leaving a potentially better solution to be undiscovered. Loving a solution prevents you also from letting go of it when the response on it is too moderate or a better solution comes along.
If an idea get’s the team really excited, it is worth putting it aside for a few days before jumping on it. Keep looking for other, maybe better, possibilities. The rush you get from that great idea could very well be worn off when you have another look at it two days later.
Solving the right problem right is the goal to create truly great products.
Finding the right solution and developing a great product won’t happen all the time. Some things may not work, and you and your team fail. It is important for all to expect this as a possible outcome and it shouldn’t be regarded as a negative event per se. When it happens, it does require a moment of reflection: Why did it go wrong, and did it happen as early and as cheaply as possible? And with answers to these questions, it is possible to improve the process.
Keep in mind that you now only know what doesn’t work. Reflection is good but don’t let the failure limit the creativity or turn into a bureaucratic rule that becomes an obstacle in this or the next project. And reconsider sharing it with your colleagues and other teams. The next time the context could differ so much that it renders the learnings of the failure useless in that case. Process failures are more relevant to share than product failures.
Whether if you work at a company that existed before the internet or work at a startup, the lessons described above could help you equally well. The concepts, processes and principles are valuable for all those involved in the development of digital products and services. A lot is about being open-minded, breaking through dogmas, and understanding the real issue the consumer has that requires a solution. Focussing on the problem, loving it, understanding it, and than solving it with a great product, that should keep you going and innovating.
Luminis onderscheidt zich van andere aanbieders in de ICT door een waarde- en klantgedreven aanpak. Wij willen vooruitgang zien, zowel bij onze klanten als bij onze medewerkers. Graag komen we met je in contact om te ontdekken hoe we die kunnen realiseren.Contact