I want to talk about the process of ideating solutions by speculating on possibilities and exploring the realm of what could be done without checking too much what can be done. When you create beautiful presentations of imagined artifacts and objects, you have the power of persuasion. You can persuade interested people to buy it, to be convinced that is a good solution because it is beautiful. And through the simulation of how it works, you can even have a high fidelity simulation of how to interact with it.
So you can show what would happen if that solution would be implemented in the field of your problem.
It is exciting, encouraging, and it can be used to sell the further development and creation of it. When you finally convince the investor or the client to buy it, then you have to do it. And when you pass from the visionary, the presenter, the salesman, and the designer who conceived such a wonderful and aesthetically pleasing solution, then it’s time to do it. You’re going to the business, the resources, accounting, the financing and the development. So you need to talk with the the builders.
That is the time when you have to be really humble as a designer, you need to establish fair and honest and straightforward relationship with the builders. Because if you have had the chance of talking very little with them about the solutions you have been selling, you need to be respectful of the constraints that my might emerge when building it. There’s actually another iteration of designing. That’s real co-design that finally you can do because that’s the proof of the building. So what about all of the features imagined, the workflows and the stories you’ve been telling about the interactions of this product?
Can they be done for real and with what limitations?
Are they actually working as intended? Have you covered all the possible ramifications and implications when thinking about the beautiful presentation told in a nice conference room in 30 minutes?
This is a very delicate part of the project in which you have to carefully reconsider the initial design choices because there was no time for growing bottom-up the solutions together with the client. This is reality. And so sometimes, if not most of the time, it’s not possible to do proper user research, create user stories, ideating, creating prototypes, and iterating them.
This is the first real prototype you are building. That is not a mock-up but a functional prototype where the real features. You’ve been creating, an inventory of specs and requirements you’ve been compiling are finally coming into reality.
You need to be very patient as a design leader, as a manager, when you are sharing finally what was a demo presentation and now became a spec for developers. In that case, developers have the right and the chance of becoming designers because they have the right of critiquing and reviewing the initial user interface decisions made to adapt to the real development of algorithms and interface widgets, and library components. So that’s the more grounded and down to earth collaborative design that’s happening during the execution of the project, the development.
The project now changes shape according to this more present forces that are not just business, accounting, leadership, management, and design, there’s now also development. That’s the reason why developers should be always present during requirements gathering but even during the synthesis of user interviews and user stories and epics because they need to have a say before architectural and decisions are made.
So you have a chance of integrating and enriching and adapting to this new context by adding more frequent and deeper interactions between designers, developers, and the end users. By doing that, you have a higher chance of creating a successful product for all the stakeholders.