IT purchased a new SAAS service portal that would eliminate some request forms currently in Microsoft Word and Excel, but the service did not include an interface for users.
Discovery & Constraints
I had very a very limited number of hours from the SAAS provider for development, so in our early meetings we took a look at several existing implementations and selected one as a baseline. With that as a guide, I came up with some pencil & paper sketches.
I met with the project owner and went over the early sketches, and he actually chuckled that he’d never worked with someone in a sketchbook like this. To drive the point home, he and I completed several other sketches as we talked.
Hypothesis & Validation
I learned the maxim, “love solving problems, not the solution,” very early on in my study of design, but that doesn’t mean you give up on a good idea when a stakeholder pushes back, it means you validate it. My hypothesis was that users primarily access an IT service portal for two reasons: to create a ticket or to check on a ticket.
The model portal did not have a status box on the home screen, but from my initial sketch on, I included one. The project owner said it wasn’t necessary, so I did a little guerilla validation and started randomly asking people in the hall what they’d use an IT service portal for.
Once I had my answers – and assurances from the developer that it would not be difficult – I was able to convince the project owners that a status box on the home page would be a great addition for users.
To make requests from IT, HR, office services, and any other department, users previously visited the forms page on the intranet, with with the addition of the IT Service Portal, the user now has to go to a different location for IT requests.
This fractured experience is not ideal, and IT was not receptive to making the service software available to all departments for all forms.