Navigation<\/strong><\/h1>\nWhen I started working on the product it was separated into categorical navigation groups.<\/p>\n
This separation into categories meant that navigation from one object to a related element first required a user to select the navigation category that the destination belonged to, then a sub-category by element type, and finally the target itself.<\/p>\n
\u00a0<\/p>\n<\/div>\n<\/div>\n
![\"\"](\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" "\\"\\"")
<\/a><\/p>\n\n\n\n\n\n\n\u00a0<\/p>\n
I streamlined movement and made navigation between related components simple and intuitive.<\/p>\n
\u00a0<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
<\/a><\/p>\n<\/div>\n<\/div>\n\n\n\n\n\u00a0<\/p>\n
Information<\/h1>\n
With navigation streamlined, the user was able to simply transition between components. A major design flaw was ingestion of information.<\/p>\n
Each component has a complex relationship to other components.
In the old design users were forced to reference 3+ properties windows to understand relationships.<\/p>\n
\u00a0<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n\n\n\n<\/a><\/p>\n<\/a><\/p>\nMultiple properties windows required to understand all information<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\u00a0<\/p>\n
\n\n\n\nI expedited the laborious chore of retrieving information about the complex relationships between components by creating a Details Panel that provides a tabbed page for each component type related to the target object.<\/p>\n
\u00a0<\/p>\n
\n\n\n\n<\/a><\/p>\nInformation easily accessible via tabs\u00a0
(note: visual design not completed)<\/p>\n
\u00a0<\/p>\n
Each tab shows information relevant to the components or concepts of that type which relate to the selected object.<\/p>\n
Tab names are hyperlinks which navigate the user to the selected relationship.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n\n\n\n\n\u00a0<\/p>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nProposed tab content prior to visual design finalization
(note: visual design not completed)<\/p>\n
\u00a0<\/p>\n
\u00a0Clarifying Installation<\/h1>\n\n\n\n\nPart of the abandoned design work included a half-finished installation wizard. After conferring with the product’s technical architects and stakeholders, I identified that the user\u2019s main goals during the installation are:<\/p>\n
\n- Add Servers<\/li>\n
- Designate Server Roles<\/li>\n<\/ol>\n
The designs that were provided for me to overhaul were confusing and difficult to use. Adding servers involved a cumbersome mix of an accordion navigation between 3 methods:<\/p>\n
\u00a0<\/p>\n<\/div>\n<\/div>\n
\n<\/a><\/p>\n<\/div>\n<\/div>\nExisting designs as provided to me involved an accordion<\/p>\n
\u00a0<\/p>\n
<\/a><\/p>\n\n\n\n\n\nKeeping track of your servers across the sections was difficult<\/p>\n
\u00a0<\/p>\n
\n<\/a><\/p>\n<\/div>\nAdding as a range section expanded beneath individual server addition<\/p>\n
\u00a0<\/p>\n
\nAfter meeting with the product\u2019s engineers and familiarizing myself with the use-cases for adding servers I spoke directly to customers to verify that 3 separate methods of server addition were necessary and served distinct purposes.<\/p>\n
My updated designs simplified the interaction without compromising any methods of addition.<\/p>\n
\u00a0<\/p>\n<\/div>\n<\/div>\n
\n\n\n\n<\/a><\/p>\n<\/div>\n<\/div>\nMy updated design enabling users to add with any method<\/p>\n
\n\n\u00a0<\/p>\n
The original design for Designating Server Roles assumed the user had knowledge of specialized terms, relegating the explanation of these terms to a help document link.<\/p>\n
The user was forced to make many nuanced decisions about their environment in one screen with little help or context.<\/p>\n
\u00a0<\/p>\n<\/div>\n<\/div>\n
\n\n\n\n<\/a><\/p>\n<\/div>\nOriginal bulk assignment method with no context regarding what these choices mean<\/p>\n
\nI re-imagined the complex and cumbersome mine field of checkboxes to achieve the same result with a series of simple, straightforward questions that progressively show the structure of the user\u2019s environment.<\/p>\n
\n\n\n\u200b<\/div>\n<\/a><\/p>\n
![\"\"](\"https:\/\/corythorpe.com\/site\/wp-content\/uploads\/2018\/02\/scale-navigation.png\" "\\"\\"")
<\/a><\/p>\n\u00a0<\/p>\n
I streamlined movement and made navigation between related components simple and intuitive.<\/p>\n
\u00a0<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\u00a0<\/p>\n With navigation streamlined, the user was able to simply transition between components. A major design flaw was ingestion of information.<\/p>\n Each component has a complex relationship to other components. \u00a0<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n Multiple properties windows required to understand all information<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n \u00a0<\/p>\n I expedited the laborious chore of retrieving information about the complex relationships between components by creating a Details Panel that provides a tabbed page for each component type related to the target object.<\/p>\n \u00a0<\/p>\n Information easily accessible via tabs\u00a0 \u00a0<\/p>\n Each tab shows information relevant to the components or concepts of that type which relate to the selected object.<\/p>\n Tab names are hyperlinks which navigate the user to the selected relationship.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n \u00a0<\/p>\n Proposed tab content prior to visual design finalization \u00a0<\/p>\n Part of the abandoned design work included a half-finished installation wizard. After conferring with the product’s technical architects and stakeholders, I identified that the user\u2019s main goals during the installation are:<\/p>\n The designs that were provided for me to overhaul were confusing and difficult to use. Adding servers involved a cumbersome mix of an accordion navigation between 3 methods:<\/p>\n \u00a0<\/p>\n<\/div>\n<\/div>\n Existing designs as provided to me involved an accordion<\/p>\n \u00a0<\/p>\n Keeping track of your servers across the sections was difficult<\/p>\n \u00a0<\/p>\n Adding as a range section expanded beneath individual server addition<\/p>\n \u00a0<\/p>\n After meeting with the product\u2019s engineers and familiarizing myself with the use-cases for adding servers I spoke directly to customers to verify that 3 separate methods of server addition were necessary and served distinct purposes.<\/p>\n My updated designs simplified the interaction without compromising any methods of addition.<\/p>\n \u00a0<\/p>\n<\/div>\n<\/div>\n My updated design enabling users to add with any method<\/p>\n \u00a0<\/p>\n The original design for Designating Server Roles assumed the user had knowledge of specialized terms, relegating the explanation of these terms to a help document link.<\/p>\n The user was forced to make many nuanced decisions about their environment in one screen with little help or context.<\/p>\n \u00a0<\/p>\n<\/div>\n<\/div>\n Original bulk assignment method with no context regarding what these choices mean<\/p>\n I re-imagined the complex and cumbersome mine field of checkboxes to achieve the same result with a series of simple, straightforward questions that progressively show the structure of the user\u2019s environment.<\/p>\n<\/a><\/p>\n<\/div>\n<\/div>\nInformation<\/h1>\n
In the old design users were forced to reference 3+ properties windows to understand relationships.<\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n
(note: visual design not completed)<\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n
(note: visual design not completed)<\/p>\n\u00a0Clarifying Installation<\/h1>\n
\n
<\/a><\/p>\n<\/div>\n<\/div>\n<\/a><\/p>\n<\/a><\/p>\n<\/div>\n<\/a><\/p>\n<\/div>\n<\/div>\n<\/a><\/p>\n<\/div>\n<\/a><\/p>\n