This is an interesting project because it arose from a water cooler conversation. I was catching up with a friend of mine from the customer support team who was basically having a moan. (Let’s call him Rob, because that’s his name). Rob was under tremendous pressure, the only person in the company that could manage our communications with partners and had been on call for the past twenty days in a row with a one month old baby in the house. He went onto explain that the main problem was network outages, if there is a drop out in our network anywhere in Europe the team needs to a. Fix it and b. Keep a constant line of communication open with affected partners. The process for this communication was funnelled 100% through this one person on the team and if he was unavailable it basically didn’t happen, a bit of a concern when the company is contractually obliged to notify partners of an outage within an hour of it occurring and keeping up regular hourly updates until it is resolved. This is one of those problems that had been bubbling away under the surface for months without being much attention, but it’s obvious how big a deal it is. The one person responsible was at risk of burning out and even when he was working at full tilt the team was still not meeting its legal obligations.
There would generally be two or three outages a week (It’s a big old network) and the process was… haphazard (think HSE haphazard). There was communication between technicians in teams chats and emails AND jira tickets with info flying around in all of these channels. Rob was taking the information he could find, compiling it in an excel document (that no one else had access to) and copy pasting it into emails he was sending manually through outlook whenever he got the chance. If anyone else tried to manage this process it fell apart. It could’ve been so much simpler, so I told him I’d design a fix for him.
This was entirely self directed so there was no brief or requirements set out for me. My priorities were to:
I had a fair idea in my head of what we needed from the start. A simple one or two page tool built around a form that anyone could fill in that would send out emails at a set time to our partners. The design process started with interviews. I had a series of more formal conversations with Rob and other members of the team to establish:
Not sure if you've noticed but I'm absolutely mad for lists right now. Drop me an email and you'll get a bonus list of my top ten lists. These ones aren't even on there. Now THAT'S exciting.
I kept track of everything on a Miro board as I started work. I shared it with members of the project team so I could give them oversight on the process and involve them as much as possible, I also shared it with other members of the design team to help me out with design reviews.
I reviewed other types of notification emails used in our industry to get an idea of how this is usually communicated and worked through user flows to wireframes to an inVision prototype with reviews at every step of the way for both the tool and the emails themselves.
I had our users populate an email using the inVision prototype to test out the flow without needing any development resources. When everyone was happy with the process we went into full development.
