Role of an Architect in Software Usability Engineering
- 1. Role of an Architect in Software Usability Engineering Thina Kesavan Senior Software Architect
- 2. The world is littered (or cluttered, I should say) with articles and essays written about various aspect of software usability. What I have tried here is to give a comprehensive coverage of all aspects that a software architect should look at when designing software. My goal is to reassure that software usability is an integral part of any software development program in organizations that develop products for users and that software usability can never be an after thought. In fact there are businesses thrive today just by beating the competition with just a better usability in their software. Organizations that does take usability seriously and establish dedicated programs with usability experts, sometime fails to realize the goals for various reasons. This essay focuses on one such a reason. Hence the title: Designing for usability. Organizations fails because, there isn’t a dedicated bridge that crosses the usability and software development departments. A software architect who is dedicated to software usability could be that bridge. They must know the users, domain, usability tactics, and know the technologies required to achieve the usability goals. They should be able to architect, design and code. That should be their only focus fulltime. This essay can be treated as guidance document for those who play the role of that bridge. What is the usability? Lets see what we get from some sources: “Usability is a measure of how easy to use a product to perform prescribed task” -‐ Microsoft. “The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use” – ISO 9241 “In order for the software to be useful, the software must satisfy the following: Efficient, Effective, Engaging, Error Tolerant and Easy to Learn. (Whitney Quesenbery)” There are two kinds of users: The internal users and end users. The internal user includes the User Experience Researchers, Information Designers, Usability Testers, Software Developers, Architects, Business analysts and Software Testers. There are other internal users who typically do not take part in how the product is being built, for example, product service technicians. However, organizations should include them in the process and make them as well responsible for the product outcome. At the end there can be only two kinds of users: The end users who pay for your product and the internal users who gets paid to develop the product.
- 3. From the end user’s perspective, it is all about how usable the software is. It is about how easy for the end user to exercise its features, how intuitive to work through and how easy it is to learn. What is your responsibility? It is how the internal user approach the usability will influence what the external users get at the end. It is how the requirements are developed, its how the software is designed, its how the software is developed and tested will impact the usability of the software. You are the one who play an important role in gluing together all these discipline in achieving usable software. You play a key role in making sure that the software is usable to the target customer. After all, if the software is not usable, then all the effort went into development of the software would be useless. Usability of the software is a broad term in software development and several quality attributes contributes to the overall software usability. For example, if the software doesn’t meet the performance quality attribute then will most likely not usable. If the software is not reliable, then the user may not use it. If software is not flexible, then it may not be usable and so on. Overall the usability of the software can be achieved by making sure that the software is easily understandable, learnable, operable, and attractive. Understandable: The software must be relevant to the customer domain and speak the language of the customer. The workflow of the software should be simple and straightforward. Learnable: The software should be easy to use and intuitive. User should be able to learn the feature easily and quickly. Operable: The user should be able to operate the software under all uses cases of the system. The software must be responsive and the software must give feedback appropriately through textual or visual cues. The user should be able to access all desired functionalities with ease. Attractive: The user should enjoy working with the software. The look and feel of the software, the usage of the colors and the size of text should complement each other and give pleasant experience. What are the usability activities that you must be part of? Before involving in any usability activities, you must understand the user and the usability requirements. This understanding will enable the architect to be
- 4. part of usability testing, usability assessment and usability interviews. Involving in each of this activity will help you translate the findings into the software architecture and design. Understanding the user and usability requirements: To understand the user and the usability requirement for the product, you must, Know the user: To understand the usability requirements, the architect must first know who the end users are, including their demographics, gender division, and the cultural distribution. Unless you are developing software for mass consumers or in social media, you probably targeting a specific user in a specific domain and you should know them well. Know the environment: To create better user experience, you must first know where the software will be used. For example, developing software that will be used in a dark lab is different than developing software for the kiosks in the shopping malls. Similarly, you must also take the users location, culture and language into account. Know the domain: To develop software, you must know the domain well. For example, developing an office productivity tool is different than developing an aerospace application. Understand the user requirement: Understand the customer requirement. In certain domain, you can’t create software that is so generic. For example, we can’t use software developed for ocean transport industry in ground transportation industry even though they both are transportation. Sometime implementation of business software such as SAP fails in organizations because users are no longer tolerating poor usability. Know the competitive advantage: This is very important as sometime the only reason customer may buy your software is the differentiating usability features that you provide beyond the core business features. Architect’s involvement in Usability testing: Usability testing typically involves letting the users use the system in a working state and gather their feedback. You must participate in the usability testing and/or review the usability testing outcomes. The following are the typical activities when working with a usability analyst. Help decide what to test: While the usability analyst is more focused on the easy of the use, you must focus on non-‐functional requirements of the system such as performance and responsiveness. You must guide the team to test certain quality of the system.
- 5. Help prepare for testing: With the help of development team, you should help prepare for the usability testing. You should help the usability engineer to decide what data to include in the system, what test cases to execute, what are the critical tasks and what are the specific problem areas. Help conduct the testing: You should help the usability engineer to define what data to capture, how to capture such a way that the data can be used is designing the software or evolve the design. You can also help in defining the workflow for the testing. Participate in usability testing: Participating in usability studies and getting first hand impression is very important. It will be useful to know what is difficult to use in the software, what is liked and what is disliked in the software. Architect’s involvement in Usability interviews: Usability interviews will not be useful if wrong questions are asked to the users. Help with user interviews/Surveys: You must help the usability analyst ask the right questions to the user. Sometime users do not know what they want, however, when they hear it, when they see it, they would be able to decide. You can help the usability expert by letting them know upfront what more you can provide in the software. The main goal for an architect is to get the feedback that can be translated into architecture tactic. Help with proactive field study: You must think how to build the user’s feedback mechanism into the software itself. The software then can collect the feedbacks proactively which can help in evolving the architecture and improve software for future releases. Architect’s involvement in the Usability assessment: When it is time to analyze the result of the usability study, your involvement is key in translating the result to implementable tasks. Find key takeaways from the testing: There may be a lot of takeaways from the feedback from the users. Since the usability means different things to different users, it is very important to filter out the noises and take away the important feedback. Prioritize the issues from the findings: You must assess the issues and prioritize them based on the severity for implementation. There may be a very significant usability issue that requires changes to the architecture that must be addressed quickly and effectively.
- 6. Derive architecturally significant usability requirements: Based on the assessment, you must derive design tactics that are strategic as well as tactics in nature. Deliverables: The following deliverable are required to make sure that the product meets the end users usability requirement. These deliverable are primary responsibility of usability engineering team. As an architect, you must take input from these artifacts. Usability Requirements: The product must have an explicitly identifiable usability requirement. This will help determine what the user value most and how this will help the user get the job done in the most efficient manner. End user case study: This will give a picture on who the user is, how the user use the software, what is the typical background of the users, their skill levels and so on. This will help in designing simple and usable system. High-‐level work flow and story boards: This is often the first glimpse that the stakeholders see how the software product is shaping up. The storyboard helps visualize the workflow and helps in reviews and gets early feedback. User experience style guide: User experience guide defines the user interface and workflow paradigm of the software that must be followed when designing and developing the system to provide consistent user experience. Usability test report: Usability test report will help to give a picture of what kind of issue that end user facing and how to mitigate such issues. User profile report: A set of user profile, summarizing the key properties of the user group. This will allow determining the different levels of user workflows and varying complexities that can be introduced in the system. For example, this will help in designing various user login levels such as beginner level to advanced user level. There are several other deliverables including information architecture, interaction design, visual design and prototyping that can help assure that you are meeting end users usability requirements.
- 7. Design guidelines: Designing for usability is one of the most challenging aspects of the software development. Having a good usability may be better than having less functionality but having more functionalities and a bad usability can result in failures. It is the responsibility of the architect to consider all the facts involved in end user acceptance of the system and prepare from the beginning. Usability is one of the quality attribute that architecture should address, however, there are several other quality attributes need to be addressed to meet the usability quality. In the traditional approach to software development, one of the primary concerns typically is that ‘Architecture restricts the usability’. This is because, the usability issues are discovered only towards the end of the project due to unavailability of a working system at the beginning and not all the requirements are finalized and evolved throughout the project. The traditional software architectural response to repeated and expected modifications to the user interface is to use separation and encapsulation. Following are the overall design guidelines that will help meet the end users acceptance of the software. To safeguard the software architecture from continuously changing usability needs, or to make architecture flexible to accept late breaking change, the architecture and the designs followed by it must meet the quality attributes: Flexibility, Modifiability, and Extendibility. Following are some of the design guidelines that will help ensure the acceptance of the software by the end user. 1. Separate the UI from the rest of the system. The UI workflow and visual changes should not impact the rest of the system. MVC (or one of the extension such as MVVM) would be a typical pattern. 2. Layered architecture – separate the UI layer from the rest of the components in the system. The UI layer can change all the time that should not affect the entire system. This will also help with prototyping with dummy data for the user experience study. 3. Configurable / customizable: Make sure that the software is customizable and configurable. User should be able to customize the software for their need to get the work done faster and most efficient
- 8. manner. Ability to add and remove features using Plug-‐in pattern is one of the examples for such architecture. 4. Responsive user interface – Make user interface highly responsive. User action should have immediate feedback regardless how long the total task will take to complete. Asynchronous calls, background threads, delayed or lazy loading are some of the design tactics to employ that provides responsive user interface. 5. Error prevention and handling – Design in such a way that the user can’t make mistake. In case error, system should recover from it. Handling right exceptions and graceful recovery are some of the examples. 6. Performance: Present the data quickly with immediate feedback for the user action. Fetching only minimum necessary data and upon user request loading further data is a potential design approach. 7. Use industry standard design patterns and user style guidelines for usability as much as possible. 8. Establish certain visibility of the architecture to the end user: Making certain aspect of the architecture visible to the end user helps them understand the product little better. This is especially helpful in the medical equipment products where there are several layers of end users such as systems engineers, service engineers, lab managers and the operators. The service engineers often need to know certain architecture elements to successfully install the system at the customer’s site. 9. Select right technology: Choice of technology plays a major role in the end use acceptance. The choice of UI framework, communication protocols, database capabilities and operating systems are all major contributors towards the end user acceptance of the system. End user acceptance and the software architecture: For the most case, the software architecture has to play a key role in the end user acceptance of the software. Well-‐architected software is flexible, modifiable and extendable to the users need. Instead of conducting usability testing at the end of the software development, the architecture must be evaluated against the usability requirement and revised multiple times during the development of the software. End user should be involved as much as possible from the very beginning of product development and the user input should shape the architectural development.
- 9. Platform software consideration: All the aspects discussed in the above sections are all applicable for platform software development. In addition to those aspect, the platform software has additional requirements such as common user experience across several products in the product line, additional concerns related to meeting more than one type and demographics of the customer and additional efforts involved in considering potentially different workflows between multiple products in the product line. The usability studies may involve customers of different products and deliverables are tailored for each product in the product line.