UX is not UI. The world agrees but thinks and does otherwise. UI gets cluttered as more and more features are added, or the product has too many options to play around with. <\/p>\n\n\n\n

Bug trackers and Project Management (PM) tools are like cockpit controls in a modern airplane. The only difference is that most bug trackers aren’t designed for skilled, busy engineers to operate. They put every button in a cluttered fashion that causes engineers\u2019 productivity to fall.<\/p>\n\n\n\n

Comparison of cockpit controls<\/strong><\/h3>\n\n\n\n

The visual complexity of tools that are meant to improve productivity can, paradoxically, reduce productivity. Let\u2019s understand how with an analogy between the complexity of contemporary bug trackers and cockpit controls on modern aircraft<\/p>\n\n\n\n

Cockpit automation<\/strong> <\/h3>\n\n\n\n

The introduction of automation on the flight deck of modern airliners helped usher in superior performance and enhanced safety. It helped reduce the physical workload of the pilot. However, it also increased the pilot\u2019s cognitive workload. <\/p>\n\n\n\n

The airline industry undertook in-depth analyses of modern flight-deck operations. The analyses revealed an increase in difficulty in learning and using automated cockpit systems. Pilots took 12 to 18 months of hands-on training to acquire the required level of proficiency to use the system. They have described the experience of learning to use flight-deck automation as \u201cdrinking from a fire hose\u201d. <\/p>\n\n\n\n

The analyses showed that the pilot-automation interaction was designed by engineers without taking into account the limits of human cognition. As a corrective measure, the design of cockpit automation has been progressively improved.<\/p>\n\n\n\n

Now, cockpit systems are designed with pilots in mind. They provide the latest weather data, alert pilots to potential hazards, and offer synthetic vision in low-visibility conditions. <\/p>\n\n\n\n

The evolution of cockpit controls<\/strong> <\/h3>\n\n\n\n

Cockpit instrumentation has moved from dials to windows to 3D views, and from buttons to mouse clicks. Continuous innovation has reduced complexity for the pilots and made it easier to fly safely and efficiently.<\/p>\n\n\n\n

Cockpit design has focused on human-machine interaction. Designers studied how pilots use the systems rather than focusing on the technology powering the avionics. The focus shifted to pilot tasks \u2013 to transform the user experience, enhance efficiency, and reduce errors.<\/p>\n\n\n\n

System designers undertook usability research, which has led to the development of many helpful features. These include on-demand mapping tools, synthetic vision, and predictive insights. As a result, pilots can handle all manner of operational scenarios.<\/p>\n\n\n\n

But user-friendly systems design was not limited to the cockpit alone. Automated checklists, predictive maintenance alerts, and diagnostic tools enabled maintenance crews to handle maintenance tasks efficiently.<\/p>\n\n\n\n

Overall, cockpit systems design has moved towards providing pilots with more information – while also reducing complexity, workload, and fatigue.<\/p>\n\n\n\n

Reducing cognitive load<\/strong> <\/h3>\n\n\n\n

Some measures to reduce cockpit complexity include:<\/p>\n\n\n\n

• Placement of critical information where it can be most easily viewed.<\/li>
• Auto-sensing features that indicate when tasks are completed.<\/li>
• Graphical elements to easily understand the scenarios that the pilot may be facing.<\/li>
• Verbal directions and assurances.<\/li>
• Terrain awareness and 3D displays for a synthetic representation of known obstacles.<\/li>
• Enhanced weather understanding through cockpit displays that displayed current and likely weather to help pilots make decisions across the flight route. <\/li><\/ul>\n\n\n\n

  Bug trackers – the cockpit parallel<\/strong><\/h3>\n\n\n\n

  Design of systems, without adequate consideration of the user, is not limited to cockpit automation alone. Most product creators tend to focus on the technology and forget the people who will use the technology. <\/p>\n\n\n\n

  In the world of software development, finding bugs early is a much sought-after goal. However, the process generates irksome overheads, reducing the productivity of the testers and developers.<\/p>\n\n\n\n

  Tracker complexity and productivity<\/strong><\/h3>\n\n\n\n

  The overheads in defect tracking are more to do with the design of the processes and tools rather than with the idea of defect tracking itself. <\/p>\n\n\n\n

  Organizations use multiple tools to track the different types of defects. Often, these tools do not integrate with one another. Thus, the same defect is documented multiple times, with slightly varied descriptions. One description could be from a user\u2019s perspective, and another, a more technical perspective.<\/p>\n\n\n\n

  The confusion over descriptions causes complications. Overly cumbersome trackers require the filling of several mandatory fields and duplicated information. Therefore, reporting becomes challenging.<\/p>\n\n\n\n

  This increases bug tracking overheads and reduces productivity. Often, the overheads of the bug tracking process are greater than the effort required to fix the bug. <\/p>\n\n\n\n

  Typically, defect reports document many defects. Many of the low-priority defects are never fixed. This is because fixing them does not provide sufficient RoI. <\/p>\n\n\n\n

  At the same time, retaining these defects in the report as \u2018open\u2019 causes them to be reanalyzed again and again. This lowers productivity. <\/p>\n\n\n\n

  Due to such difficulties, developers use the cliched line \u2018works on my machine,\u2019 followed by the closure of the bug. <\/p>\n\n\n\n

  The presence of multiple \u2018open\u2019 defects causes developers to be careless when writing code or fixing bugs. This is a case of the well-known \u2018broken windows\u2019 theory. The theory was first proposed in the context of urban policing and later featured in the book, \u2018The Pragmatic Programmer\u2019.<\/p>\n\n\n\n

  When tracking tools are reduced to merely being a means for storing documentation, they distract from actual communication and collaboration within the team. The bugs end up being passed back and forth between the testers and developers. Expectedly, such closing and re-opening of bugs can degrade productivity. <\/p>\n\n\n\n

  The \u2018usability\u2019 of the bug tracker is key to efficiency. The team rarely has a say in the choice of the tool or the set governance mechanisms. The tracker needs to be made user-friendly by adding templates and canned reports and the design optimized for efficient communication and smooth workflow.<\/p>\n\n\n\n

  Closing thoughts<\/strong><\/h3>\n\n\n\n

  The incidence of human error in flight crash investigations is hyped. As such, engineers have reinvented the cockpit design to prevent pilots from making mistakes and incorrect decisions. <\/p>\n\n\n\n

  Similarly, a bug tracker is a time sucker for many engineers on a project. But it has never been remade as clutter-free for them to act on it.<\/p>\n","protected":false},"excerpt":{"rendered":"

  <\/span> 4<\/span> minute read<\/span><\/span> UX is not UI. The world agrees but thinks and does otherwise. UI gets cluttered as more and more features are added, or the product has too many options to play around with.  Bug trackers and Project Management (PM) tools are like cockpit controls in a modern airplane. The only difference is that most bug trackers aren’t designed for skilled, busy engineers to operate. They put every button in a cluttered fashion that causes engineers\u2019 productivity to fall. Comparison of cockpit controls The visual complexity of tools that are meant to improve productivity can, paradoxically, reduce productivity. Let\u2019s understand how […]<\/p>\n","protected":false},"author":4,"featured_media":2325,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[137],"tags":[124,115,126,125,123],"yoast_head":"\n