How do you communicate with others in solution design?

Navigating the intricate dance of solution design communication is an art, and at its heart lies the sage advice: know your audience. Imagine your words as keys to unlock understanding. Tailor your discourse, not with jargon, but with a shared language that resonates. As a solution designer, I've learned that decoding complexities begins with connecting, not complicating. Picture your audience as curious voyagers; guide them with clarity. It's not just about conveying information; it's about fostering comprehension. So, speak in a symphony that resonates with each ear, and watch your designs flourish in the fertile soil of collective understanding.

Communication in large programs that involve high level executives needs to start by aligning design frameworks, terminologies and visions about business, people, process and technology. Common metrics, checks and balances must also be established to insure consistent and effective design and delivery, as most large projects with agile implementations need to check their progress consistently while designing and implementing new features and capabilities. Ideally, data-driven insights and modelling should be used as well to create a real time mirror image of the solution for better understanding of the progress and alignment with design requirements issued by the customer. This model should be available for feedback from the customer, too.

Effective communication in solution design entails gathering requirements through stakeholder interviews, producing thorough documentation, and delivering updates via meetings and collaborative platforms. While translating technical language improves clarity for non-technical team members, prototyping and feedback loops assist stakeholders in visualizing and providing input. As a solution architect, it is crucial to address risks, create change management strategies, be open to criticism, and iterate on ideas to ensure alignment with business requirements and maintain communication with all stakeholders.

The single most important aspect in a solution development. ‘Know your audience’, as a Solution or Enterprise Architect you are addressing a technical or business challenge of an Enterprise/Business or even Individual. Only if you know what you are trying address can an effective solution be developed. In simple words ‘Knowing your audience’ is the end destination and overall ‘solution development’ is the route/vehicle chosen. This also helps to deliver the final message in the same wavelength as what the customer wants.

Base your communication on your audience. Regardless of your audience’s technical aptitude, there’s no need for jargon and acronyms. Create a more inclusive environment.

For technology audience, established patterns are key, also make this information available to all, democratize it so can make the process and related ecosystem efficient. For non-technical audience, get with delivery lead or the PO, create a reference Information diagram write down in the form of faq so that all involved can use the same language, increase understanding and avoid any confusion.

It is an Art. When we need to prepare solution design and get the buy-in/approval from stakeholders. I will try to put together as points 1) Capture Business Requirement, extract the functional and non-functional requirement and document it with the area (as per prescribed template) 2) Articulate the scope and out-scope using building blocks/context diagram 3) Create the usecase diagram using the tools, this will help us to list down the various scenarios 4) Develop the Architecture Diagram one for component level and another for 30000 feet level for Business and C-level stakeholders 5) Provide the walkthrough for each usecase and how it will be fulfilled 6) Develop the low-level design with the implementation plan 7) provide the milestone

Make sure you understand the audience and same goes for audience it’s for effectiveness and reliability the tool for the target audience

Before going into the details of your design, think about your message. What it is you want your audience to understand the most? What is your takeaway? Then, think about what is the best way to convey that message. Would a technical diagram explain it better? Or a slide deck with emojis? Or a simple 5-minute video walking them through the experience? Choose your weapon carefully. You can't use a blade to cut down a tree. Same in here, you can't use a 3-page case study paper to give the audience the experience of value. Or a technical diagram may not be the best explanation for a business audience. Finally, choose the right tool for the job. Visio is great for diagrams, but Miro tells a story better.

Use appropriate tools to leverage the strengths of collaboration make sure you highly makes the plans for communication effectively leverage

I would use different graphs and presentations to facilitate my communications to my stakeholders. Some of the tools I used are Unified Modeling Language, Excalidraw, PlantUML, Mermaid, and Lucidchart

We need communication and collaboration tools, Code and version controls, prototyping tools, chart and diagrams tools (draw.io the best for me) and the project management tools.

Visual presentation through tools should be worked upon to larger extent. Visio is one of the good tools in producing flowchart diagrams and giving a visual impact.

For Early-Stage Conceptualization I normally use Whiteboards or Digital Sketching Tools. At this stage, ideas are in flux. A whiteboard allows for easy changes and can be a collaborative tool for brainstorming sessions. For Wireframing and Mockups I use Balsamiq or Sketch. These tools provide a low-fidelity way to visualize the user interface and experience, which is crucial for stakeholder buy-in and for avoiding misunderstandings later in the project. For System Diagrams and Flowcharts I use Lucidchart. Master UML notations. The scripting for Sequence diagrams is way easier than visually creating the diagram. The scripting is faster and a whole lot of fun.

To solicit feedback in solution design, I create opportunities for open discussions, presenting design aspects clearly and encouraging questions. I share design documents and prototypes early in the process, fostering an environment where constructive criticism is valued. Utilizing collaborative platforms and conducting regular design reviews allow team members and stakeholders to provide feedback at different stages. I actively seek diverse perspectives and opinions, ensuring a well-rounded evaluation of the solution. Additionally, I use feedback as a catalyst for iterative improvements, demonstrating responsiveness to input and enhancing the overall quality of the solution.

Lucid chart, flow manager, google docs, wireframe, jamming ., quip , sheets as they all can be collaboratively typed. Make them as detailed and shared between stakeholders. AI powered tools like visual source safe , ant scripts and automation to create framework out of design. The automation and ai codegen saves hack of a time and meets coding design pattern across the system . Generate help docs out of code for better readability and maintenance.

They say human is the only animal that uses tools and it of course has given us excellent results. Having the right tools to express the design is a very important recipe for success for any solution designer. It would help if you spent considerable energy learning new tools and practicing them to enrich your expertise in their usage.

When communicating, it is always a best practice to speak in simple, direct terms. I like to communicate as if I'm talking to my non-technical mother. Even when talking with technical stakeholders, it's better to communicate in simple terms. Don't try to prove how smart you are by using overly complex terms and strategies when a more direct method is available.

Make sure you won't confuse the audience by using the incorrect terminology. Know your ground, know your terms. A "resource" in a cloud solution is not the same as a "resource" in project planning. Use the correct words, and look it up if in doubt. There are established templates and examples in the industry, adopt them. TOGAF and Zachman are great, and they can take you a long way in certain scenarios. If you feel that they are too big for your purposes, don't worry, you're not alone. Trim them down, but keep your message consistent.

The logical format of the message to be conveyed as per stakeholder requirement is key to deliver effective communication. Eg - if EDI team is presented with Electronic data interchange format communication is a language to accepted globally.

If you want to become a great communicator then read, read, and read. If you read more then you would know what is normally in practice and if you know that then you can follow the same norms. Following the norms increases readers' comfort as they don't need to learn your style but just the real content for which the material has been created.

It is good to use the frameworks wherever necessary. e.g. medimum to complex solutions. They help in getting acceptance from the stakeholders as it will be a well known framework and references by other clients/competetors can be shown. Also it will reduce unnecessary noises on approach and opinions.

In solution design, I emphasize clear communication, active collaboration, and adherence to best practices. I value feedback, stay updated on industry standards, and manage risks transparently. Timely updates and meticulous documentation keep everyone informed, and I use structured problem-solving and effective presentation techniques. I respect constraints and prioritize testing and validation. Together, these principles drive successful outcomes in solution design. Let's connect to create impactful solutions! #SolutionDesign #Collaboration #BestPractice

My favorite way to solicit solution feedback is to show a demo/diagram of the solution Then say something like "Poke holes in this design. Tell me what won't work. I promise I won't get offended" Inviting critical feedback to your solutions are crucial to identifying mistakes and technical limitations early in the process. No SA can know everything about everything. Simply asking other experts to tell you what's wrong with a design can go a long way. I will often times take a screenshot of a design and post it in a Slack channel a bunch of experts hang out... if there's something wrong, they will tell you!!

Early feedback is more important then perfect design. There's a reason why agile methods were invented: What you understood as requirements might differ magnificiently from what your client has explained. None of us are infallible. To make mistakes is human, but avoidable. Don't assume, always check in. You have a bright idea? Amazing. Confirm it with your stakeholders. Do you have doubts? Even better. Ask and check. Make sure you go iterative and ask for feedback. You'll find that it's mostly appreciated.

Seeking feedback and input from stakeholders is a pivotal step in the solution design process. By encouraging questions, comments, and suggestions, we foster collaboration and innovation. Active listening and respect for diverse perspectives are key. Addressing communication gaps and using tools like Slack, Teams, Google Docs, or SharePoint to facilitate discussions and revisions ensures a well-rounded approach. Together, we create more robust solutions.

Development of a good system is an iterative process. What is required by the client is often quite different from the stated requirements. On the other hand, what the solution developer proposes may be a good solution but may not be workable. Both of these factors lead to the failure of a project. With feedback process in place, the requirements get defined better, and solution becomes more relevant to the end users. The feedback has to be followed by an evaluate and improve process (see the last item). The feedback has no meaning if it is not evaluated and appropriately used to improve the solution.

Brainstorming the design with peers and seeking feedbacks in Architecture review meetings are key to provide solution to a problem. Having a birds eye view on the solution from an architect external to project internal to an organization helps us think from various point of views , thus enhancing the design to ensure the architecture principles are considered while solutioning.

I find it is always good to ask the question directly: "Does this make sense? Is it clear? Do you have any questions?" Don't wait until the end, validate along the way, and then you will be able to adjust or explain as needed.

In the intricate dance of solution design, the fourth step is to embrace the rhythm of feedback and stakeholder input. Cultivate an environment where questions, comments, and suggestions flow freely, where opinions and concerns are not just heard but respected. When communication stumbles, mend it with acknowledgment and action. Tools like Slack or Teams build channels for collaboration, while Google Docs or SharePoint foster commentary and refinement.

Post meeting feedback is vital in understanding customer way of presenting and delivering the solution to them. Also the presenter needs to understand ways to simplify the presentation and avoid unnecessary complexity in process of making understanding the solution.

Ask for feedback explicitly and ask it more often. Keep in mind that any feedback from the audience is a contribution from them to your work so value it accordingly. Evaluate the received feedback keeping yourself in their position and try to improve what you have designed. One proven way to improve your design is that you try to incorporate all feedback even if that doesn't seem fully right. If the feedback is honest then it at least has one more perspective which enriches your work.

The fifth step is to be flexible. In this current century nobody expects you to know everything humans are evolving as adaptive learners. Be a quick study, willing to learn new skills, tools, and adopt best practices. The landscape evolves, so don't be set in your ways. Conflicts happen when working with diverse teams. Flex to navigate choppy waters through open discussion, give-and-take, prioritization. Switch gears, use different analogies to bridge gaps. Ultimately, flexibility lets you go with the flow, effectively communicating and collaborating as situations shift, continuously improving methods.

If you've been receiving constant feedback as suggested, you must've picked up that requirements change. All the time. Even whatever was taken for granted, it would change. When confronted with the force of change. stay fluid. Be like water: Adopt it, surround it, make it a part of yourself. There are many tools and skills that can be employed, expand your arsenal. Learn about communication styles, cultural differences, value of questions. Investigate different tools available to you, and know which is strongest where. Don't be a fanboy and don't be the person who knows everything a little. Learn enough, and use the right tool for the right job.

Communication mechanism through different tools helps to deliver the solution quickly in a simplified way and gives a way to present same content in different ways depending on the situation. An open mindset to learn and unlearn the different tools in market helps one to experiment the analytical and presentation capabilities to end user.

Be Flexible (or Embrace the Unexpected) No matter how carefully you plan, adventures rarely go exactly as expected. When unexpected obstacles or changes in direction arise, be prepared to adapt your communication approach on the fly. A little creativity and a willingness to roll with the punches can go a long way.

Flexibility and adaptability are crucial traits for solution architects, as projects often evolve and change over time. Being open to learning new tools and practices, as well as adjusting to new requirements and technologies, can greatly enhance the effectiveness of a solution architect. Tools like Trello, Jira, Zoom, and Skype are excellent examples of technologies that can aid in managing change and facilitating collaboration in dynamic project environments.

One valuable practice I've found in effective communication during solution design is the continuous seeking of feedback from stakeholders. By actively encouraging questions, comments, and suggestions, we create a collaborative environment where concerns are addressed promptly, misunderstandings are clarified, and solutions are refined iteratively. This not only improves the overall quality of the solution but also foster a sense of ownership and shared responsibility among the team. This approach not only enhances the design but also strengthens team cohesion and ensures that the final solution aligns closely with the stakeholders' expectations and needs.

Throughout my career, I have learned the importance of understanding the core business problem and key stakeholders when architecting solutions. I always start by taking time to actively listen and probe to uncover the true pain points or opportunities before jumping into a technical design. When communicating with both business and technical audiences, I simplify complex topics using clear, straightforward language rather than industry jargon. I've found this direct approach resonates across levels, especially when paired with visuals like architecture diagrams.

Evaluate and Improve (or Debrief Around the Campfire) Once your adventure is complete, take some time to reflect on what worked well and what could be improved. Share stories of successful communication strategies or harrowing miscommunications, and use those lessons to fuel your next expedition.

Follow presentation edict and keep it short and sweet. No audience likes "death by slides" or a book to read while you are presenting. It doesn't matter the level of expertise here. It is important to get the important facts out and allow questions to drive you deeper during discussion.

Tell the story In your communication try to always tell the story that will take your audience through your designs. Some of the Solution Designs are complex and understanding it all in one view might be an overkill. Instead you should start from something that your Audience is familiar with and build up from there adding more complexity. Approaching the communication this way - will help in terms of smooth understanding and increase chances the message you want to pass to your Audience will be understood and followed. The story should address individual needs and concerns of the Audience.

Create “Solution stories” - Similar to user stories in agile development. These narratives will describe the problem, the proposed solution, and its impact in a relatable, storytelling format.

I have always found it beneficial to understand the business case and exact nature of requirements before delving into architectural patterns i.e. spending more time on the problem than the solution

In my experience I have found it best that while designing a solution and presenting the solution, Tell a story, take the audience on a journey. Speak to the problem while presenting, demonstrate how the solution betters the journey for the client or customer. Solution Design is an art of story telling using technology to answer a business need. (I should trademark this line.)

Solution Architect should frame their solution design as a captivating story to effectively communicate its value proposition to both technical and non-technical audiences, fostering understanding, buy-in, and excitement. Technical vs. Non-technical: For technical audiences, delve into specifics whereas for non-technical audiences, focus on the solution's benefits and how it addresses their needs. Business stakeholders vs. Developers: Highlight the solution's business value for stakeholders and for developers, focus on the technical details and implementation approach.

Maintain clear documentation of design decisions, requirements, and changes. Share documents through collaboration tools or version control systems to keep everyone updated. If possible, showcase demonstrations or proofs of concept related to the topic. Practical examples can help in illustrating how the concept works in real-world scenarios.

Communication during solution design should be consistent and continuous - meaning, keep the communication going throughout the solution implementation. Communication should also be collaborative and involve every relevant stakeholder from the customer team as well as from the solution design team itself. Communication should be open, but crisp and stick to the agenda, avoiding digressing out of context as much as possible. Getting inputs from architects and designers who have implemented similar solutions or complex solutions can be a key value-add in avoiding re-inventing the wheel. Also, an architect is required to communicate with different categories of stakeholders, hence the communication should be tailored to suit the audience.

Verbal and non-verbal both kind of communications are crucial, hence it is an unsaid rule to keep the video on during the online sessions. Another pivotal point is to document the solution design, agreements and share it with all the stakeholders, so that everyone is on the same page. Also, for successfully communicating the solution design is to present it with visually appealing diagrams rather than just text. Human beings imbibe designs better when represented in a pictorial format. Using them in tandem with concise texts, help in communicating the message appropriately and easily to all the stakeholders.