Ahmed Ali

There are common accessibility practices and tools that detect accessibility issues today more than ever. Especially for web applications where you can find browsers extensions to test your app for accessibility. Generally speaking for cognitive impairment, you need to focus on: 1. Reducing cognitive load: not stuffing too much functionality in a small place. Prioritize the critical and core functions with the least amount of clicks, navigation and UI elements. Simpler is better here. 2. Provide clear labels, text, aria labels for screen readers follow 3. Keyboard navigation flow must be correct. It’s easier to navigate with keyboard + screen readers in this context 4. Prioritize text over color coding or icons to perform actions

Modules breakdown is the essence of why we have design decisions. They are the parts about which both the product and the team work in parallel. A good architectures identifies the integration point and tackle them first so that teams can further break down their individual pieces in parallel and work on them independently. Software architecture doesn’t need to solve every single detail ahead of time. It just needs to set the high level blueprint, direction and the module breakdown. It sets the standard for testing, non functional requirements that guide the teams. It considers evolution of individual modules to happen independently and assumes continuous change in requirements, modules and minimizes the friction points accordingly.

A good software design is based on understanding, tradeoffs and justification across multiple moving factors like 1. Functional requirements (features that address customer asks) 2. Non functional requirements (Security, scalability, availability, etc…) 3. Budget: Not every customer needs a top tier software, especially at the beginning. They may prefer faster market penetration with expectations to change and adapt the software further down the road 4. Team skills: While software design is expected to be technology agnostic, architects preferably have some technology choices in mind while building the design. These choices better align with what the team is familiar with unless there is a strong reason not to take that into consideration

Since developers are going to eventually implement these requirements. The requirements clarification phase needs to close the gap between what the customer needs and what the developer expects to implement. This is an iterative phase of: 1. Speaking with stakeholders, and domain experts 2. Gaining domain knowledge and being able to speak the same domain language 3. Focusing on the customer pain point and what is the problem before jumping into solutions 4. Researching competitor products and compare how they solve that problem 5. Have a quick prototype to showcase whether there are gaps or more questions to be answered