Information Architecture - Breaking down surveys, pipes, and batches to improve flexibility
The Importance of Information Architecture in Software Development
Information architecture is the art and science of organising and structuring information to facilitate effective retrieval and navigation. It serves as the foundation for organising content, data, and user interactions within a software system. In essence, IA aims to create logical, intuitive, and user-centred structures that make content and data accessible and understandable.
User Experience (UX):
One of the primary purposes of information architecture is to enhance the user experience. When users interact with software, they expect it to be intuitive and user-friendly. A well-structured IA ensures that users can easily find what they are looking for, understand the relationships between different pieces of information, and navigate the software seamlessly. This leads to higher user satisfaction and engagement, ultimately benefiting the software's success.
Scalability:
Software often evolves and grows over time. Without proper information architecture, software can become convoluted and difficult to manage as more features and content are added. An effective IA allows for the seamless integration of new components and features, making the software more adaptable and scalable.
foundation for the software. By doing so, they can create software that is efficient, user-centric, and poised for long-term success.
40Seven IA and Nomenclature
In a recent discovery project for 40Seven ltd we were asked to help redesign the gas department's main web application to allow them to expand into new areas of business.
The problem was that the current application was hindering their ability to collect and manage information for anything more than data associated with Gas pipes.
On further analysis of both the system and current process we found that several terms were used to refer to the same thing interchangeably, namely jobs and pipes.
The existing data model was essentially a single table called jobs, this table contained all information for the pipe and survey in a single table. This causes problems as all the fields in the table were created to store specific information about gas pipes.
Not only is this inflexible it doesn’t actually describe what’s happening in the real world. In the real world the business process can be described as something like. “We need to maintain survey information about pipes” To abstract this further we could say that “We need to maintain survey information for clients assets”. This gives a clue about what the data structure might look like and how we can make it more flexible by splitting the survey table into surveys and assets.
Our solution now records assets separately in the database from the survey information itself so that further asset types can be added in the future. As well as the technical changes to the databases we created a data dictionary with definitions so that the internal process could be better understood within the business.