The research process is the primary one among the most critical processes of product design. Especially when it comes to the design of a product from scratch, the research process enables the identification of the data to be taken as the basis for creating the product. Benchmarking, identification of scope and product design for the relevant closed system add further value to each and every data.
An Example of a Closed System Product
Admin panels working in the background of listing sites can be given as an example of products in closed systems. It is sometimes very challenging to design those systems which are not accessible by end users.
For the sake of better describing the product, an admin panel that is incorporated into a listing site and is generally used for managing moderation processes can set an example in this respect. In an admin panel, processes such as user management, post management, moderation management, communication channels management, etc. are conducted in an authority-based and closed manner.
To briefly (not exhaustively) mention positive aspects of product design for those systems:
- The platforms used are definite,
- User personas (post moderation team, quality/communication channel team, admin, etc.) are precise and accessible,
- Usability tests can be easily performed with personas for extended times.
In designing products for systems like admin panels, creating the information architecture is one of the most critical processes. One may suggest that it is quite ideal as the first step to create the category tree as well simultaneously with the information architecture based upon the initial requirements.
On the basis of such information architecture, a map for use which would enable the first meeting of the personas with the system and indicate the general hierarchical order (even if in draft form) may be prepared. Such a map may provide an 80% common use even though it does not cover all personas.
The processes up to this point are actually applicable both for products to be designed from scratch and for products the design of which will be improved. The forthcoming processes can be addressed in two aspects, one being product design from scratch and the other being an improvement of the design of an existing product.
The Process of Product Design from Scratch:
When you first start the process, you may think that you have no data in hand for design, particularly in terms of benchmarking in the research process as mentioned in the first paragraph. Eventually, since they are closed systems, they require a certain level of authorization. Finding product examples on the internet -even if in the form of screenshots- can of course help in this respect. However, reviewing products by getting their demo/free versions would be more valuable.
In the process of product design from scratch, the performance of frequent user tests may be more helpful when compared to the process of improving the design of an existing product. Thanks to the advantage of being close to users, frequent performance of user tests may result in the progress of designs parallel to users’ needs to a wider extent.
In the course of developing designs, creating role-based prototypes for personas and conducting availability tests may step by step take you to the last stage in the design.
As for UI design, ready-to-use libraries are usually preferred for cost-effectiveness in the design of these types of products. You may download the inventories in those libraries either yourselves or with the support of the developer, and use them in your designs. When there is a need for a new component, icon, etc., designs available in the library may be a guiding point in terms of style.
The Process of Improving the Design of an Existing Product:
In the design improvement process, the best advantage when compared to the product design process is the presence of existing information architecture, category structure, and personas with identified authorizations. No matter how precise the requirements, the design of which is planned to be improved, may appear, it would be absolutely useful to conduct user interviews. In user interviews, you may take those requirements as your primary guide. In those interviews, considering that user authorizations and tasks are different, putting some requirements directly into practice may give rise to various challenges in shared screens. In such cases, especially in authorization-based designs, it may be useful to proceed with shared screens as few as possible. Additionally, in conducting user interviews, you may ask personas to record their screens while working in order to look into existing uses and examine those records as well.
You may group feedback from user interviews by identifying critical levels for the product. For instance, when you make a 2-level grouping, you may group those pain spots that you hear from almost all personas as level 1. You may group as level 2 those pain spots on individual screens used by the user on an authorization basis rather than the general structure. You may add your suggestions to the solutions you generate for the identified pain spots, and start running the user tests.
As in the previous process, you may advance the designs parallel to user tests.
The Features that a Product does not Contain are as Important as the Features it Contains.
A product, the design of which will somehow be improved, may have been improved/extended in time with new functions and features due to certain requirements and needs. At this point, by taking current uses of the product as a reference, you may remove from the new design the unused features by discussing it with all authorization units. This would both enable achieving a plainer design and open new areas for new design moves.
The Impact of Software Criteria on Design
Finally, we can address software criteria. Software capabilities of libraries in the existing system or to be newly used can generally be limited. On the other hand, since they are not platforms developed for end users, it may not be desired to allocate a high budget/effort. Within the bounds of these possibilities, it would be better to proceed according to the capabilities of the structure/library to be used. If you proceed by disregarding this point, some requests you have forwarded may remain uncovered in design or may require additional development costs. This of course does not mean that you should proceed entirely on the basis of software criteria. For example, if a solution you have created for a pain point that you identified to be in level 1, such moves can be made since the reason behind it is also a strong one.
