RISK ASSESSMENT WEB APP
The client name and other details like mockups and prototypes are sensitive. Please contact me to schedule time to go over them in person.
CHALLENGE
The client, a top 20 national tax, audit and consulting firm, was working on the development of a very complex custom internal risk assessment tool that would replace their current off-the-shelf solution. The bespoke application needed to incorporate a variety of complicated workflows while managing information from a variety of data sources and users would span the spectrum of employees in the organization.
TOOLS
Sketch
ROLE(S)
UX Designer
GOAL
I was responsible for developing two key aspects of the application: search (of client engagements) and the core risk assessment questionnaire. Search needed to facilitate the discovery of any engagement using a variety of filters and display a large volume of information both in aggregated and individual results. The questionnaire needed to accommodate complex notation processes and maintain and display a history of interaction with individual components in the process.
PROCESS
This project was well underway when I was brought on to design these pieces. As such, I wasn't in a position to inform the process from the start but I adopted an incremental process of iteration, confirming design direction with stakeholders through daily interaction. Prototype development wa regarded as out of scope so I would walk stakeholders through static designs of the site and get/give feedback.
RESEARCH
User research had been completed so I was armed with some knowledge of how to approach these tasks. A small number of personas had been developed along with a variety of journey maps centered on roles-based tasks.
DESIGN
For the search, there was a requirement that client engagements could be searched using multiple pieces of identifying information, and the results of those searches needed to show a large volume of information both before and after selecting an entry. The client, coming from a table-heavy accounting background, was committed to a column-and-row based search style that, when combined with a large volume of columns, meant information easily scrolled off the page.
Because of the client constraints in place, I placed the results table within a container, added a scroll bar and explored options for displaying the expanded details for each search result. Populating a dedicated area on the screen for this information was one option, as was a modal overlay, but these were cluttered solutions that only complicated an already too busy function. Eventually, I placed the detailed information for each result in an expander control, or “drawer,” that was revealed below a particular search result as desire by the user. This satisfied all of their needs – the large volume of information they required in each row was available and, when they wanted it, the expander would show them the rest.
Next, I redesigned their client questionnaire process, which was more involved than it might sound at first blush. More than just a series of questions, the questionnaire was a living document that would pass back and forth between groups at __________. Each question could have notes applied by various employees, or could be open or closed to notation, with the ability to do so based on the user’s role. Each question also needed to retain historical data about how it had been interacted with (who made what change and when and for what reason, for example).
After sketching some ideas and approaches, I settled on my strategy. I isolated each section, comprised of potentially multiple questions, to a single page in the process, giving it full focus, which would provide me with less-crowded real estate to accommodate the volume of potential data that would need to be displayed. Then, I borrowed the “drawer” expander pattern from above which not only contributed to the cohesiveness of the site as a whole by reinforcing design patterns but served as the perfect solution for this particular process. The “drawer,” activated by various icons to the right of each question that referenced a specific aspect of the question, would be presented when requested by the user.
In the absence of user testing (not budgeted for this phase of the project), though, this approach was dismissed in favor of using modals to display an overlay of each aspect of a question. Since this application would not be available for mobile, it was less of a concern to rely so heavily on modals. After mocking up the various action types that could possibly be associated with each question, along with accompanying workflows, the client was pleased.
Because of the client constraints in place, I placed the results table within a container, added a scroll bar and explored options for displaying the expanded details for each search result. Populating a dedicated area on the screen for this information was one option, as was a modal overlay, but these were cluttered solutions that only complicated an already too busy function. Eventually, I placed the detailed information for each result in an expander control, or “drawer,” that was revealed below a particular search result as desire by the user. This satisfied all of their needs – the large volume of information they required in each row was available and, when they wanted it, the expander would show them the rest.
Next, I redesigned their client questionnaire process, which was more involved than it might sound at first blush. More than just a series of questions, the questionnaire was a living document that would pass back and forth between groups at __________. Each question could have notes applied by various employees, or could be open or closed to notation, with the ability to do so based on the user’s role. Each question also needed to retain historical data about how it had been interacted with (who made what change and when and for what reason, for example).
After sketching some ideas and approaches, I settled on my strategy. I isolated each section, comprised of potentially multiple questions, to a single page in the process, giving it full focus, which would provide me with less-crowded real estate to accommodate the volume of potential data that would need to be displayed. Then, I borrowed the “drawer” expander pattern from above which not only contributed to the cohesiveness of the site as a whole by reinforcing design patterns but served as the perfect solution for this particular process. The “drawer,” activated by various icons to the right of each question that referenced a specific aspect of the question, would be presented when requested by the user.
In the absence of user testing (not budgeted for this phase of the project), though, this approach was dismissed in favor of using modals to display an overlay of each aspect of a question. Since this application would not be available for mobile, it was less of a concern to rely so heavily on modals. After mocking up the various action types that could possibly be associated with each question, along with accompanying workflows, the client was pleased.
RESULT
Both feature designs were completed in less than a month and met all of the client's requirements, dramatically increasing the staff's ability to process new engagements efficiently and clearly.