How do you evaluate system design options for specific domains?

1. Elicit requirements from stakeholders, utilizing a proven method, E.g. INCOSE RE guidance per SEBoK, IREB fundamentals. 2. Negotiate & agree with customer on requirements and their verification and validation of end product. Signatures from both customer and supplier. 3. Propose design, multiple designs if requested by customer and within budget/scope constraints. 4. Design reviews will consider performance, “-ilities” (E.g., affordability, producibility, sustainability), SME advice. 5. Effectively manage your requirements and design model, utilizing tools that support your process. Low end = spreadsheets and/or word processor for requirements, drawings and schematics for modeling form, fit, and function; high end = DOORS and Cameo.

In my experience, to start to work on a System Design is usefull understand the main pain points from multiple perspectives. You should take into account how cohesive the general experience is across all the apps, how your design team develop new features and how developers implement those designs. I think once you have a deep understanding of all those elements, is easier to start to develop a new System Design.

In my experience, when evaluating system designs for specific domains, start by deeply understanding the domain's unique requirements. For instance, when designing a healthcare data management system, I immersed myself in healthcare data intricacies, regulations, and security. Collaborating with domain experts and stakeholders is essential. Using decision matrices, we evaluated design alternatives based on data security, compliance, and scalability. We selected a design balancing domain-specific needs and technology capabilities while staying within budget. This experience reinforced the importance of domain expertise and structured evaluations, leading to successful outcomes in my projects.

Identifying the domain or application for system design involves several important steps that are crucial for building a good project, such as: define requirements, research, user analysis, scope definition, technical considerations, stakeholder input, prototyping and validation, and documentation. By following these steps you'll have a more accurate view of the domain or application.

A good idea is to understand the state of the art of System Designs. Once you identified all the pain points and what you want to accomplish, it is a good idea to see what other does. Here, there are a lot of elements to check, but the most important is the design language itself. This particular topic depends significantly on the product or company you work for. Some brands are expected to have a continuously evolving design, but some others are more established ones, and the work is more about having a unified experience across all the apps. Another critical topic is the platform (Web, Mobile apps, etc) and technology to be used to implement this System Design. In this regard, it is a good idea to include Devs early in the process.

Once you have a good idea about what you will use in terms of design language, the next step is to start to work on design. I found it helpful to start with meetings with all your stakeholders to begin to see patterns and topics to include in the definitions of your designs. Also, as I said before, it is a good idea to validate from the beginning if those designs work from the implementation side, including developers on this process. Adding developers to the workflow will add another point of view on the process and probably have a better outcome.

Another critical step in communicating your decisions to the different actors is to document what you did. This documentation should include the rationale behind your decisions as well as guidelines to use these elements in design and the expected behavior when the implementation is ready.