NEXTVR CMS
NextVR's Content Management System handled all the pre-recorded virtual reality video and live stream data, metadata, client UI thumbnails, geofencing restrictions, published status, you name it.
NextVR's Content Management System handled all the pre-recorded virtual reality video and live stream data, metadata, client UI thumbnails, geofencing restrictions, published status, you name it.
NextVR had a functional back end, but it had grown reactively, and had accumulated UX debt. The interface had been designed by engineers, and it felt like one long page of form data that mirrored the underlying database structure. Employees were finding it difficult to use, and eventually the company wanted people externally to be able to use it without training.
Discovery
I started by interviewing engineers, managers, and team members that used it regularly--particularly the ones that had different goals and used different features. There was a lot of complexity to understand, so some of these in-depth sessions took hours. I requested access to the system in a test environment where I couldn't inadvertently do any harm, and got more familiar hands-on.
Diving In
Diving In
Armed with its features, I hierarchically organized use cases from most popular to least, and sorted the system's capabilities into intuitive groups. I checked in with my interviewees around this time to sanity check these conclusions, and to investigate their wish lists. Having used it myself, I could more easily translate their more abstract desires into something more concrete.
I started researching existing patterns by looking at existing systems that did similar things, such as YouTube's content creator area and WordPress. I documented my analysis.
I started a design document to track my conclusions and questions. This eventually became home to my low-fidelity solutions, with usability and feature notes for engineers to reference. The document began with a concise description of the goals, technical context, and UX challenges, followed by an overview of my conclusions. I created design tenets, such as the desire to minimize information density in view on each page, and to include hover help consistently. I suggested a menu arrangement, page grid, consistent display of buttons and links, and grouped form elements. I proposed a color coding system to focus attention on critical readouts and interactive elements. I standardized area headings and nomenclature. I included flow charts to illustrate the primary use cases. I broke out areas that could just be redesigned immediately, and things that needed to be re-engineered at a deeper level; there was an obvious multi-phase plan developing. I ran all this past my stakeholders for a thumbs-up.
The Wireframes
The Wireframes
Now, it was straightforward to dig into wireframes, revise and re-revise until I had all the main pages worked out somewhat, and reusable widgets and design patterns presented themselves. These went into the design document, I presented them for another greenlight, and did a couple rounds of revisions.
Eureka!
Eureka!
Some interesting things had come up. For instance, I proposed a whole new way of defining and editing geo-fencing rules (content broadcast was usually restricted geographically) that people really liked, but which required fundamental database changes. This went into the backlog. People were thinking about usability now in a way that allowed it to define the underlying structure more.
Polish
As the product hit future milestones in development, I audited the UX and produced review documents that were converted to bugs or user stories by QA and Project Management. I always like the polish this part of the process can impart.
