Engineers and developers from a space department of CGI requested design strategy to improve their Geographic Information System(GIS) platform. The GIS platform they were developing at the moment was a proof of concept prototype that basically proves that the core functionality is feasible. Since they were on a development phase, the prototype was intended only for internal use within the team. The challenge of the Space team was they were not clear about the design strategy as to their userbase was vague at the moment. Their plan was to design and develop a generic product and then adapt it for individual clients.
My design goal was to streamline the main user flow and enhance the UI surrounding it.
I created and optimized the UI in an agile way using Information Architecture (IA), wireframe, and user testing the prototypes. I also established a design system with documentation for the maintenance of the consistent design language.
From the competitor analysis, I learned that there are two categories of GIS platforms: request-based platforms and independently operable platforms. CGI EnvironmentMonitor360 belongs to the request-based platform category with following characteristics.
Conversely, independently operable platforms allow users direct access to a pre-existing data library without needing to submit specific requests. The data is already processed and stored in a readily usable format, making it easy to access.
The findings revealed that CGI EnvironmentMonitor360’s strengths are in its customization and availability to provide unique data sets according to the client's needs. For instance, the platform can offer targeted topics, customizations, and specific data on areas of interest and tailor the data accordingly.
The challenge I faced was not knowing who the users would be. Whom should I design for? I searched other case studies about designing GIS platforms. Fortunately, an excellent source I found gave me a clue: regardless of the specificity of users, their core needs wouldn’t differ much. Therefore, it is crucial to define the main user flow and streamline its accessibility.
To address this, I defined the main user scenario and user flow by analyzing the current prototype and researching features of other competitors
I sketched the Information Architecture around the main user flow. Then, I created paper wireframes, tested them with users, and iteratively improved the wireframes. The wireframe was optimized to become the final UI.
I user tested the prototype with four participants without experience with remote sensing data or platforms other than Google Maps. I used the paper prototype and gave them tasks to explore the main features. In the following section, I will explain how I solved challenges through user test insights and iterations in the following section.
One of the challenges was to let the user intuitively select the area. For this, in the original prototype, the user needs to search for a specific location by inputting geographic coordinates and deciding the distance from the location. Instead, I proposed using a place name and selecting the area on the map by creating a new interaction with a responsive circle to a mouse movement. The circle gets bigger and smaller as the mouse moves right and left. Also, throughout iterations, I simplified the steps needed for area selection.
Another challenge was designing two similar main user flows: searching for present (or recent) data and past data. The detailed steps for each are as follows:
While the two user flows are similar, the "past data search" includes additional sub-tasks, such as selecting the date range and choosing the data from the available lists. This is because the platform has limited past data stored.
My challenge was to differentiate two user flows in the UI and ensure that users could grasp two flows depending on their use case. In my first iteration, I used the same screen to enable both user flows, using the wording "Real-time" and "Time-lapse." However, user testing revealed that the users couldn't tell the meaning of these terms. As a result, I suggested new names such as "Present Images" and "Historic Images. " Also, in the latest iterations, I separated the two user flows into disparate screens by differing them via tabs to convey that these flows serve different purposes.
Beyond crafting the UI, I established a design system with comprehensive documentation.
I aimed to ensure that the design was not just a one-time, pixel-based effort but a sustainable system that other contributors could understand and continue to develop. This approach was intended to maintain a high level of design quality for a relatively young product.
Additionally, I ensured developers could easily understand and implement my design intentions. For the design hand-off, I used Zeplin, a tool that optimizes the final design for the coding process. the Zeplin file included changing units from pixels to rems and outlining each screen step by step. I delivered the design system, links to design outcomes, and videos explaining the final design to facilitate the developers' understanding.
If there were more time, I would like to improve the following points in the project.
Though this experience I became passionate about design system and creating UX and UI of a online software. I learned how to collaborate with developers. Recognizing the importance of active listening and uncovering unspoken needs became a critical takeaway.
