In the early 2000s, information architectures were used to describe the structure of websites. But today's focus is less on content-rich websites and more on functional, complex tools. For this reason, in our work Conceptual Structures, we investigated new forms of representation for the structural description of digital products.
At the beginning of our work, we concentrated on identifying existing forms of representation for the structural description of digital products.
This is just a really brief overview – If you are interested in more details of our research, please message me.
In order to gain a broader understanding of existing industry standards and an insight into their workflow, we interviewed experts from various disciplines in the field of digital product development. These included product designers, information architects, an agile consultant, software architects and backend developers.
In the first part of the interview, we wanted to find out more about the interviewee's conception and design process in general. Without naming specific methods, we wanted to gain an unbiased insight into their work processes. In the second part, we looked at communication within transdisciplinary teams. We investigated how the parties involved communicate and which tools are used for this. Finally, we asked the interviewees about their understanding of information architectures and other structural methods and whether they use them. At the same time, advantages and difficulties were discussed.
The aim is to develop a tool-supported methodology that supports designers in building a function-based structure in the early phases of digital product development. A collaborative desktop tool should dynamically integrate the structure of the software into the design process.
Based on the previously formulated challenges, we finally embarked on a first ideation. The Crazy 8's method and the resulting density of ideas provided us with a variety of creative solutions in a short period. We generated ideas independently of each other and then tried to identify similarities and differences in the solutions. We then created possible combinations in the form of initial sketchy concepts.
The next task was to develop concrete ideas for the structural representation of software. We, therefore, used reverse engineering to trace existing software products back to their basic conceptual structure.
At the beginning of our work, we had already established that the functionality and n-dimensionality of software can hardly be represented in a 2D environment. Typically, software has a large number of interactive control elements. For this reason, states and dependencies can only be depicted in interactive representations. With this in mind, we decided to use the advantages of digital click dummies in this ideation round.
In contrast to reverse engineering, we now attempted to describe the structure of software that did not yet exist. To do this, we came up with an idea for a new mobile application: A social app focusing on bringing users with similar musical tastes together. We formulated a core objective and various features this app should have. Based on this, we designed a structure that we revised and adapted step by step.
After developing the structural representation for this mobile application, we tested the same principle on a desktop application and added further improvements to our method. Furthermore, we also tried our method on an already existing application.
After multiple iterations, our method was eventually finalized.
The core of the method consists of a number of elements, which differ in their type. These are described in more detail below, using the structure of a whiteboard tool as an example.
Conceptual Structures is a solution approach in two substeps. Firstly, the focus was on developing a representation method (described above) for the structural description of software products. Integrating this method in the desktop application "splice" enables an efficient and resource-saving setup.
Splice is intended to serve the interdisciplinary product teams in the development and conception of end-user applications. The canvas-based software can be divided primarily into the two workspaces "Structure" and "Wireframe". The app is designed so that switching between the two workspaces is possible and even desired at any time. This way, the product team members can flexibly jump between the process steps. In doing so, individual ways of working are supported.
The aim was to develop a method that can be adapted to the design process of the product teams. The method can be divided into individual steps, which can be separated if desired.
At the beginning, all stakeholders of a product team, such as product owners, designers and programmers, jointly write a requirements text. This text should briefly describe the main features of the planned software and serve as a common consensus that can be referred to at any time. In this way, ambiguities and differing ideas are prevented right at the beginning of the project.
Individual words from this text, which are important for the software, can be converted into unlabeled elements and subsequently sorted. Gradually, this should result in a structure of different objects, which can be supplemented by further elements.
No. 01 + 02: Formulate requirements & create elements
The created elements can be nested, and links between them can be created.
In addition, elements can be combined into new areas or menus. Areas include all the elements that will be displayed on a later wireframe/screen. A local menu is a control element that usually contains one or more functions and can be accessed at any time within this area.
No. 04: Create a local menu
The created elements can be nested, and links between them can be created.
In addition, elements can be combined into new areas or menus. Areas include all the elements that will be displayed on a later wireframe/screen. A local menu is a control element that usually contains one or more functions and can be accessed at any time within this area.
Designers also have the option of creating sketches for individual UI elements as well as entire areas. These can then be linked to the structure.
No. 05: IPad app to create sketches
Task flows can also be optionally created before the creation of wireframes. These are intended to help keep an eye on the core requirements when designing wireframes step by step.
No. 06: Create a task flow
Task flows can also be optionally created before the creation of wireframes. These are intended to help keep an eye on the core requirements when designing wireframes step by step.
In a later phase, the wireframes can be linked to the structure. In this way, the structure also adapts to changes in the wireframes and continues to develop dynamically. Conversely, the elements created in the wireframes can also be easily transferred to the structure.
No. 07: Linking elements to a wireframe
Once UI elements have been linked to the structure, they are automatically accessible in a UI library and can be dragged and dropped from the sidebar onto individual frames.
In order to document design decisions for team members in a comprehensible way, the designers can record their motives for the creation of an area. Tags and assignments can also be added.
In order to document design decisions for team members in a comprehensible way, the designers can record their motives for the creation of an area. Tags and assignments can also be added.
To make it easier to find individual elements on the canvas, it is possible for teams to filter the element map according to the tags and assignments they have previously created.
For better coordination within the team, comments can be set in the structure as well as in the wireframe environment.
For better coordination within the team, comments can be set in the structure as well as in the wireframe environment.