Information Architecture to the Rescue

Digital Properties Inventory


The phone sales group sold space on many websites and needed to consolidate the information to allow for cross-selling opportunities. Because they are on the phone they need to info to be easily organized and quickly findable.

  • Problems & Constraints
    The application had been created as a proof of concept in a developer’s spare time, without any design input. The developer had shown it to a VP and they wanted to release it the next week. I was brought in to do a quick UX review before it was rolled out to the entire company.
  • Personas
    Admin care about the ability to add, edit, and remove properties as the are bought or closed.
    Salesperson care about quickly navigating through the structure to find correlations between different digital properties.
    Marketing Employee care about tracking and promoting digital properties internally to other company groups.
  • Team Dynamics – 1 Month
    Project Owner-1, Researchers-1, Visual Designer-1 Software Engineers-1


  • The application went from 0% success rate for task completion to 80% success rate.
  • With only a one month delay the application was turned from a failure into an demo app of the software team could produce.

Initial Review

  • Navigation Testing (photos below) Tracked users as they attempted to complete needed tasks
  • Heuristic Recommendations Based on best practices I reviewed the designs since there had not been any design involvement unto this point.


Based on the 100% failure rate I recommended to halt release and return into development mode.
Since I was brought in, more for rubber stamping the current version, rather than making recommendations based on bad news; the report included:

  • A defined list of things that need to be done to fix the problems.
  • A defined time-frame of how long each step will take and which can be overlayed to speed things up.(The ability to present a cohesive package of project needs to the product owners allowed for a way to side step office politics or placing the blame)
  • The report centered on what the data was found and is showing as far as project impact (instead of assigning blame to people). This allows everyone to save face.


I quickly did user testing to get to the bottom of why there was 100% failure rate and I was able to confirm that the calls to action for navigation were not seen easily. Interviews brought up the other two themes:

  • The sales group had their own vocabulary and names for all the systems.
  • There were some old systems used by the salespeople that organized the information in their own admission a non-logical way.

I collected vocabulary and expected hierarchy using a card sorting and naming activity with users. Then working directly with the developer I was able to:

  • Change the vocabulary
  • change the application hierarchy
  • Include some navigation cues to make it faster to transverse the application while on the phone.

Iterative Research

I met with the developer at the end of day three times a week to discuss possible solutions and which were possible within the framework the application were written in. Because the system already existed I used the live system for user testing on the other days.

Based on user testing, Changes made:

  • Navigation affordance needed to be as large as possible.
  • The system need to usable using one hand since it was used while on the phone.


The main goal of the reports at the end of the irregular development cycle was to keep the product sponsor coming back to the for future projects at the beginning of the development cycle. To do this the report centered mainly on requested features from the user testing and the amount of time comparison of adding them after development.