ITSM Development and a lesson from UX Design Thinking
All are original works, references provided where appropriate.
UX Thinking (or UX Design Thinking, or UXT), and in particular the Prototyping stage, is prevalent in Web/App design.
Where is it in ITSM service design and delivery? In my experience, not very many places.
In fact I over exaggerated, it’s nowhere at all. If it is, please show me and let’s chat, we’ve already got lots in common.
So quickly, what is UX Design Thinking?
Design thinking is an iterative process: Empathise – Define– Ideate – Prototype – Test.
I’m going to cast my own flavour on how I think even just one part of UX thinking can hold huge benefits for ITSM.
There are similarities between ITSM development processes and UX Thinking. Here is the process I use:
For now, I want to zone in on one glaring addition from UX Thinking: Testing.
In a typical development process the testing is done after development.
In UX Design Thinking the testing is (optionally*) done before development.
* I've added optionally, as not all development pieces warrant a prototype e.g. they are straightforward enough.
This gives UX Thinking a distinct advantage. If a situation occurs where the testing highlights a mismatch in customer-supplier perception of requirements, then we’ve only built the wrong outcome in a prototype, not the real thing.
Of course this saves time, and money.
Suppose you are thinking that 1) To tighten requirements/scoping and 2) Reduce time/cost by eliminating Design Thinking Prototype Testing and surely the final delivery is as expected, and quicker/cheaper to boot?
Maybe so.
Of course the real answer will depend on the scale and complexity of the project, and also the type of stakeholder. Let me just say this, missing requirements does happen, fact. There I’ve said it.
So prototype testing will solve the misunderstanding of requirements.
The stakeholders will see what the finished product will look like – the UI. They will also interact with it to get a feel for how it will work. Great.
Hold on.
There’s one additional benefit here that is sneaking up on us like a Toyota Prius – the stakeholders are involved in the system design, they are part of the solution.
There are no unexpected twists, it’s transparent from the beginning. Changes can be made early on if required, before expensive development begins. The solution can be perfected, saving a visit to have to enhance it at a very near later date.
As Kevin J. Smith, President of the IT Transformation Institute sums up:
“Transparency throughout the process of working with users to improve the user experience is an important goal to keep. Transparency creates a natural vehicle for communicating quickly and clearly with users and helps to avoid misunderstandings and mismatched expectations.”
One final thing.
How much extra time and cost is actually required for prototyping?
Of course that depends on how the prototyping is done. Draw it as a wireframe in pencil and it’s minimal. Produce high-fidelity interactive prototypes and we’re talking considerably more time.
Mitigating this time however, is the fact that design prototyping tools exist these days such as Sketch, Figma and XD which are designed for fast delivery and that is indeed what they are: Rapid Prototyping Tools.
Couple this with the fact that I have already rebuilt the entire Cherwell V10+ interface (every object, dialogue, icon and even toolbar) and suddenly the time investment again becomes minimal.
Thank you for reading.
If you enjoyed this article even if it’s because it’s just a little bit different, please give me a mention and feel free to share it with your network.
