Future Flood Forecasting System
Current UI of the system
The system’s UI was rather basic; resembling an old Windows 94 look and feel about it. Information was everywhere and the screens would very quickly become overcrowded and cluttered with info that could lead to further mistakes if not presented in an orderly manner.
The research had been done when I joined the project so my role was to work with the stakeholders in understanding their primary needs as forecasters and aleviate the potential errors due to a less than ideal system at the time.
The business opted to use Power BI as their BI tool for reporting and visualising data. This was a further issue as the graphs in particular were very difficult to customise as metric elements were presented in blocks of code as opposed granular X or Y metric data code when viewing graphs in particular.
Redesigning the Content space
Introducing navigational search
This prototype showcases the layout for multiple search results returned when it pre-populates whilst your typing.
The example shows an instance where a location had two entries returned from the search.
The search results are designed to show the Site name in black with the Site ID below that in a grey colour.
This would be the default search results dropdown layout for the Site name & ID search moving forward.
Building a model
There was a complex issue where forecasters were able to build models they’d like to run on the system.
There were eight types of models that could be built and they were all pretty laborious.
My idea was to quicken the process in combining many elements together in making the process more automated and intuitive.
This was an example where I was able to utilise the different content screen widths depending on the choices available per screen; thus making use of the content space.
Icon designs
Threshold icon iteration testing
First iteration
Second iteration
Final designs
Graph redesigns
Redesigning the forecast player
The video player which was introduced by a third party was not very intuitive in determining the days nor speeds for example, but the most obvious error was incorporating the play control buttons as part of the map toolbar menu on the far right of the screen away from the frame rates and date details as well as the slider.
Forecast player redesign iterations
The player console was positioned at the base of the screen by default. The playing controls are on the far LH side with the player slider centered together with the option of changing the date. This would be the default calendar/date picker. The frame rate per second selectors were clickable blocks at the top right of the slider, whilst the colour ramp was on the far RH side and horizontal with the measurement readings clearly visible inside the coloured blocks.
There was an additional option of minimising the player console controls, as well as being able to undock the player toolbar.
