Massimo Curatella

Tag: design leadership

  • How to prepare and run a software demo: prompts

    In this post no. 344 I am publishing my notes on Software Presentation.

    Presenting a piece of software is a [[presentation]] so anything applicable to the art and craft of presenting can be applied to software as well.

    [[Presentation]] is a [[communication]] activity so the basics are to be found in this wider field.

    What are the most important things to do and to know to create and deliver an effective and efficient software presentation?

    1. Define who your audience is

    2. Define your audience’s background and their goal. What’s the most important thing they need to get from your presentation?

    3. Define the delivery context: where, when and how is your presentation going to be delivered?

    4. Define the presenters: is it you or a group of presenters? What’s their relationship? How are they sharing tasks and responsibilities?

    5. How much time do you have available for the presentation? Is there going to be a Q&A session?

    6. What media are suitable, accepted, required, requested for the presentation?

    7. What’s the presentation outline?

    8. What’s your final goal you want to achieve with this presentation?

    The software to be presented

    1. What’s the nature of the software to be presented?

    2. What’s the design and development level?

    3. If there are data-based features to demonstrate, what’s the nature of the data? What’s the data model? Is there a database involved? What about the data: is it fake, real or custom made for this presentation?

    Real data vs fake data.

    1. If the data is real, do you have permission to show it outside the scope of the inner workings of the software?

    2. Is there any sensitive information included in the data?

    3. What’s the best data configuration to support the storytelling in the presentation?

    4. Do you have a local backup of the data in case the live server is not working?

    Simulating a user flow vs doing it for real in the software.

    1. Do you have a clearly defined set of stories to show?

    2. Are you using real or test users?

    3. Can you show a prototype, a mockup or a simulation instead of the real software? What are the implications of choosing a development version versus a live one?

    4. Is it required to give access to the software for the attendees? Is there a dedicated and set-up environment for this controlled audience? Is there a developer following the operations and able to intervene in case of urgent needs?

    Covering for features not yet implemented.

    1. Can you show a mocked up user story instead of a prototype?

    2. Do you have clearly identified the prerequisites, the running context, and the outcome of the stories related to the feature you are presenting?

    3. Are you ready to collect feedback by accurately recording all suggestions and critiques?

    4. Do you need to show multiple versions to pick one? How have you organized the sequence and the comparison? Do you need to give handouts or material illustrating complex scenarios or minute details?

  • Showing The Design Process vs The Final Product

    What’s the difference between showing the end product of your work versus showing all of the stages of your design process?

    In the first case, you might want to have an impact, to present it and to impress. Maybe you cannot talk it thru, you cannot present it as product so it must be polished and perfect. There should be storytelling elements, showing the strengths of your solution.

    The problem with that : you are not able to tell the difficulties, the discoveries, the problems you have faced. So is less personal is more constructed. You can try to control the instantaneous impression, but it’s more difficult to convey your creativity, your thinking process and your design personality.

    On the other hand when you show the backstage of how you evolved the solution of how you researched possible ideas and how you faced the problems, the obstacles, and the constraints that you met during the ideation process, it shows more your personality as a designer or as a developer, as somebody who is been thinking about the problem and researching it and finding different ways: branching prototypes, iterating versions.

    And this is also a way to show the value of your work. So if you want to give depth to your work and be appreciated for your efforts as a designer, showing the evolution of your designs is the best way of doing that, compared to giving flat screens, beautiful rendered without a background history.

  • Co-Designing Solutions with Developers

    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.