Heady Information Technology System (HITS)

Mission: Create a management application to meet the needs of Smoke Cartel's information technology department

UX DesignDevelopmentPHP


The Heady Information Technology System was designed for Smoke Cartel, Inc. as a centralized management application and documentation resource for the company’s information technology department.


As the company’s principal information technology systems designer and administrator, a common problem was managing all the devices and other technical assets, support needs, documentation, and custom applets written for the company.

How might we create an application which allows for central access to asset management, technical support, living documentation, and applet administration that can scale with company needs.

Users and audience

Smoke Cartel had a small group of people who had their hands in the IT operations. I was the principal IT systems designer and admin, but there were also company executives who needed information on IT systems as well as future developers who would need access to information gathered by internal applications. Employees of the company also needed a way to get quick IT support, which needed to be kept organized and associated with devices for better tracking.

Roles and responsibilities

This team consisted of myself as the sole UX/UI designer and developer, along with the CEO for testing and direction.

Scope and constraints

Due to the rapidly growing nature of the company, the project needed to be designed and brought to production quickly.


There were a lot of different things that were needed from this application, and scope creep became a concern. First, we looked into all the needs we had in the company. This included conducting 1:1 interviews with multiple staff members from all departments to see how we could make their work lives easier when it came to the company’s IT systems and also to gain insight into how we could stop problems before they happened.

Needs of the IT staff

  • Ability to track IT assets such as computers, printers, order fulfillment equipment (barcode scanners, scales, label printers), network equipment, and peripherals
  • Ability to retrieve detailed IT support requests
  • Ability to associate notes and support requests with specific IT assets to track ongoing issues
    • Smoke Cartel started small and grew rapidly and thus had a variety of different equipment. Some equipment was unreliable and it was critical to be able to track issues on specific devices to know when it was time to replace them and to understand bigger issues.
  • Living documentation on the entire IT system that was easily editable and secure
  • A dashboard for custom build applets for information and control
    • A big issue for Smoke Cartel at the time was network connectivity issues. An applet had been developed to test if devices were online and then alert the IT staff if there was a device offline. We needed a way to manage that app and see its data. But this was not the only custom applet written. We wanted a way to control and see the data of all the applets in our system.

Revised how might we question

How might we design a scalable application that tracks all IT assets and support requests, documentation, and custom applet data?

Needs from the employees

  • Ability to quickly and easily create tech support requests and get them filled in a timely manor
  • Ability to see system status for things like network issues and known internal application bugs

Revised how might we question

How might we design an application that allows employees to quickly alert IT staff of IT issues and gives employees convenient access to system status for all the various systems and services they use?

Needs from executives, future developers, and future IT staff members

  • Ability to read through documentation to find information on how to setup new devices and use various services and applications as well as best practices used in application development
  • Ability to see information gathered from internal applets written to maintain the IT system, such as determining if devices were online

Revised how might we question

How might we design an application that allows for secure, centralized documentation on all IT systems and practices used at Smoke Cartel?

Define + Ideate

From this information we started to formulate a list of features we wanted to aim for in addition to how we should phase in these features. Feature prioritization was key as this system would eventually encompass the management of the entire IT department. But developing all the functionality at once was unrealistic.

Release 1

  • Asset management database
    • Establish a cohesive and consistent naming scheme for all IT assets along with a tagging system
    • Ability to assign assets to other assets (ie. label printer with a workstation)
  • SSubmit support requests through a desktop link in addition to a quick link in the company’s intranet portal that would associate requests to the IT assets for issue tracking
  • Live documentation on the system
  • Secure login system

Future releases

  • Ability to use mobile devices and scan asset tags for quicker management in various parts of the company’s campus
  • Editable live documentation from within the application
  • Login system that integrated with Microsoft’s Active Directory Directory Services
  • Central control of applets and a central dashboard for their information

Information architecture for the management application

  • Dashboard: Primary dashboard and landing page with the ability to change system status right away
  • Documentation: Living documentation for the IT systems
  • Reports and stats: General statistics on network use and web traffic
  • Services: Central dashboard for the applets developed
  • Support tickets: Support tickets that came in from employees
  • Repairs: Support tickets that had been converted into repairs which could be tracked through the repair process
  • Databases: Computer and asset databases
  • Tools: Additional features of the application, primarily for scanning IT asset tags

Prototyping and development

After gaining an understanding of the problems we wanted to tackle with this application through user research and after taking those insights and deciding on the features we wanted to develop, we began the process of prototyping and testing.

The process started with wireframes, creating a dashboard-style application segmented into the major categories defined in information architecture. The application was prototyped using Bootstrap and PHP.

Testing was preformed on a variety of devices from Windows and Android tablets, to iOS and Android phones, and laptops with various screen sizes

Early homepage design with statistics and known issue tracking
Documentation dashboard with accordion menus
Sample asset tag with barcode, QR code, asset name, ID, static IP address (if applicable), and notes (if applicable)
Initial asset tag scanner page. Barcode scanner was used to read the barcode and input the unique ID.


For the main management dashboard, testing was done with the executives who might use it. The primary test was accessing asset information and documentation.

For the support ticket creation front-end, we setup some cases and had employees in every department test the functionality.

Sample case

A computer isn’t working. Find the notes on the device to see if this computer has had problems in the past.

Sample case

You need the login credentials and instructions on how to add a network printer to a new computer. Find the documentation that explains this process.

Sample case

Your printer prints labels but they are horizontal instead of vertical and are therefore cut off. Submit a support request.


  • Touch was hard on smaller sized tablets
  • The wording of asset management as “Database” was confusing and often led to the tester not being able to find where to locate computers.
  • Documentation was straight forward and easy to find and reference. Although a search feature would be a nice addition to make the process faster


  • Brightly colored support ticket creation buttons in the company intranet were very obvious and easy to find
  • The support ticket creation dialog box asked only a few relevant questions that were easy to answer under 60 seconds and provided all the information needed for the IT staff
  • Both the desktop icon for tech support and the tech support buttons in the intranet were easy to find and did not have to be explained

Early computer asset information page prototype Early computer asset information page prototype
Early computer asset database page prototype Early computer asset database page prototype

Continued development

This project continued on in development over the course of a year, undergoing a variety of staged deployments of new features, each including quick and efficient onboarding for employee-facing changes.

The application’s final form utilized the following stack

  • MySQL integration
  • Node.js application on the primary domain controller to connect the applets to the online management application
  • Management application and API were written in PHP
  • Bootstrap was used for UI elements and grid structures for rapid development
  • A custom-made token authentication system was developed in PHP and Python for securing the system
  • The application was hosted on an Ubuntu server running an Apache web server


This project was my passion project for the final year of my time at Smoke Cartel. It transformed my daily work life by making asset management and tech support tasks much easier and it was an integral part of our development team’s ability to find documentation on the systems in place.

Technical issues that used to take three or more days to learn about and fix were down to half a day from report to repair.

Lessons learned

If I were to reembark on this project I would have absolutely made a mobile app. Since mobile web browsers restrict access to the device’s cameras, barcode scanning was not possible on our Android and iOS devices. This meant that the tagging system wasn't be as useful as it could have been.

Furthermore, the naming conventions established for asset management ended up generating asset IDs that were too long to be quickly entered into support ticket creation dialogue boxes or remembered by anyone other than the IT staff.

The overall project could also have benefited from more time spent in the wireframing stage. The final version, although effective, could have used the available space more efficiently. Unfortunately, time constraints meant that the project needed to be pushed to prototyping as quickly as possible.