Massimo Curatella

Tag: design

  • How to receive brutally honest feedback

    Call anybody you can reach to, even a family member is fine. Prepare on the screen the prototype, the mock-up, the demo of the visual artifact you’ve just created and you want to have feedback on.

    Do not make any introduction, do not give any explanation: call the chosen tester and ask a direct and straightforward question: “What do you see?”.

    As the first thing you want to have the first reaction, you want to listen to their thinking process. When they start to describe what they see, do not make any reaction, do not judge, do not answer. Keep on asking “and then?” or “why?” or “what does it make you think of?”. Ask only open questions to elaborate on what they are seeing and feeling.

    Only when you are satisfied and their patience hold, if you feel like, ask them more specific questions like: “Do you like it?”, “What do you like?”, “What don’t you like?”.

    And only at the end try to give context, application, and audience: “How do you see this ‘thing’ in the context of conveying this ‘message’ to these ‘people with the objective of achieving this ‘communication goal’”?

    Congratulations, you had the chance of receiving brutally honest feedback.

  • How to decide if to rebuild or adapt a new system

    Before considering rebuilding a solution because old, it’s wise to evaluate the differences between the existing system and the new version to be designed. Even if there are many components with several interdependencies it might be convenient to evaluate a piece-by-piece update rather than scratching everything and starting back from zero.

    How shall we decide if we should redo it from scratch or adapt the existing one?

    Plan to invest a limited amount of time to map the most connected and relevant part of the system to the one to be and see if it is relatively straightforward to translate between the old and the new or if there are too many differences or new pieces or a lot of old pieces to be completely removed.

    If you discover that there is a high ratio of unchanged parts or slightly adapted components versus the novelties you might consider updating and upgrading the old rather than starting from scratch.

    In very complicated systems, if you discover that the update is more convenient than the rebuild you might save a lot of time and resources.

    This is my daily post no. 347.

  • 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?

  • Knowing the Pieces Before the Assembly

    When looking to create a new solution starting from premade pieces you need to have a precise and exhaustive inventory of all the pieces and how they can connect with each other.

    Design is about finding new and useful connections. New, compared to the solutions found until now, otherwise you would have already solved the problem. Useful because they are satisfying the needs, wants and desires of the final users.

    It’s not wise to try to arrange the pieces without having a clear and shared understanding of their functions and their potential for connection, it could be inefficient or, worst, harmful.

  • Coherence in Data-Gathering

    You can define the rules for the internal consistency of data by seeing how different pieces are related together. By deduction, you can gather enough samples to support the definition of a rule. If you are so brave and lucky to come up with the internal consistency of the data you have gathered, then you need to apply those rules to the whole data inventory. Without knowing the rules at the source of that data you can increase its quality by applying the deduction you can make.

  • Notes on Hierarchy

    • Hieararchy:
      • is a way to organize information
        • useful when relationships between items of different depth levels is clear and straightforward
        • which can be easily divided in chunks
      • has different depth levels
        • the deeper you go the higher the detail
      • summarizes complex concepts
        • if well done, allows to understand the essence of a text by reading only the higher level
        • when created, forces the author to systematize their communication
      • improves thoght
        • by showing key concepts first
          • and detailed consideration below
          • with the possibility of linking to other sections
      • facilitates multiple accesses to information
        • by breaking down a topic into sections
        • by providing a structured approach
        • by promoting an inventory of concepts
        • by categorizing content

  • Beauty is in How it Works

    If Munari said:

    > If the form of an object turns out to be ‘beautiful’ it will be thanks to the logic of its construction and to the precision of the solutions found for its various components.

     —Design as Art, Bruno Munari

    And Steve Jobs stated:

    > “The design is not just what it looks like and feels like. The design is how it works”

    — Steve Jobs, Entrepreneur

    We can say that a beautifully designed object is something that works well, for the purpose it has been created for, providing a solution that is effective, efficient, pleasurable, and sustainable.

  • 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.

  • What We Talk About When We Talk About Design and Business Consultancy

    A partial list of the topics I’ve touched while doing a design consultancy.

    • Business coaching.
    • Business strategy
    • Content strategy, content design, online writing, research, knowledge management, ideation, article writing, social media management, online promotion. Copywriting, UX writing and microcopy editing.
    • User research
    • User testing
    • Design discovery
    • Webinar design and hosting, online event facilitation, interviewing.
    • Design synthesis. Design review and critique. Design presentation.
    • Communication design, and critical thinking.
    • Systems thinking, sustainability, management and leadership.
    • Business Innovation, product design, product development, software design, software development.
    • UX design, usability testing, design thinking, user interface design, design principles creation, usability heuristics identification and application.
    • Visual design, graphic design, typography, color design and accessibility testing.
    • Facilitation, mentoring, advising, coaching, training, education and teaching.
    • Instructional design, training design, learning experience design.
    • Collaboration, participatory methods, decision-making and sensemaking.