Human beings judge products based on their left brains' logical and right brains' emotional capabilities. And most of the time, emotion is the main criterion in their judgments to buy a product. In alignment with their emotions, users first create a mental model of the products they use. This model guides them throughout their whole experience with the product. Therefore, user interface designs should be based on the mental model of users rather than of designers. Personas, which are representative imaginary characters, are the best way to define the mental models of diverse user profiles and predict their expected interaction with the product and behavior on user interfaces. This can be achieved by a good interaction design. During interaction design, boxes on the branches of the flow chart are grouped within containers. Or several containers combine and form a single user interface. Links between flow chart containers become navigation elements, such as links. This method, which is mainly based on the grouping of requirements, mitigates the risk of missing any functionality on user interfaces of the product. It also prevents mismatch between the flow of use case scenarios and the flow of user interfaces, and ensures usability. The main objective of information architecture design is to identify content requirements, define content categories, and finalize the navigation structures of a product's user interfaces by using techniques such as card sorting and wireframes. User interfaces should speak the language of users, not the technical teams. Persona representatives should feel that the content on the product's user interfaces is created especially for them. This is a common type of usability defect. It is used to categorize content. Even the most experienced designers can't produce the optimum design at the first trial. Good design is a result of several iterations. Iteration is a cycle of doing something, testing it, improving it, and retesting it. Making iterations on the final product is a very costly approach. Because for every iteration, the technical components of the product have to be changed and retested, whereas changing the prototype is much easier and faster compared to changing the final product. In the lean approach, the project team and customers should frequently come together and evaluate the functionality and usability of the product early on prototypes. Recent prototyping tools allow mocking up the products and simulating them in an interactive way. They allow user actions, such as navigating between interfaces, selecting options, and getting notifications by error messages. To achieve simplicity, the mobile application's user interfaces included everything users needed and nothing they didn't. Do We Need Prototypes in Agile Projects? Instead working parts of the mobile application corresponding to user stories were used for functional and usability testing. For agile projects, if user stories have the right level of granularity and are atomic, working parts of the product can be developed quickly and used for functional and usability testing instead of spending extra time for prototyping. Until the Renaissance, the majority of architects designed their artifacts with a craftsman approach. Aesthetics were still important for architects, but their main concern was designing buildings, bridges, and fountains that best met the needs of the public. After the freedom and creativity impact of the Renaissance, architects started to behave more like artists and focused on designing more aesthetic pieces. They should focus on meeting the functional needs of customers in the most usable way, leaving aesthetic concerns to visual designers. These frequent refactoring efforts necessitate excellent architecture design and development skills within the technical team. Whether the selected methodology is agile or waterfall, architects should formulate a highly flexible technical architecture design. Otherwise the architecture will be more like spaghetti with additions and updates at following iterations. This will result in a fragile product with performance, security, predictability, and reliability problems. To build a highly flexible technical architecture, the data model of the product should be parametric and flexible. This way excessive data migration and conversion needs, due to new transactional and reporting requirements, can be prevented. An elegant product is one that proposes maximum value for its customers with the highest level of reliability and performance. The major factor that makes a product fragile is its technical complexity. This is usually a result of embedding an excessive number of features into a product that has limited hardware capacity. One of the solutions for this problem is to build an open technical architecture that allows the product to communicate with other products by transmitting data between them and sharing their complementary features. This way, a single product does not have to include all those features within it. This kind of open technical architecture is the main driver behind wearable technologies' capabilities that are beyond their own capacity. For instance, users of a simple, wearable step counter can also manage their diet and personal training programs via its mobile interfaces by connecting to other products such as electronic scales and fitness devices.