This is a personal tale of how the loss of a family member lead me to rediscover a love of design, take stock of day-to-day life and bring some good to others.
Eight days before Christmas
The phone rings; the unthinkable has happened; a deliberate act by somebody we trusted has taken the life of a loved one before her time. The perpetrator of this act also saw fit to take their own life mere hours later.
The next few months are a jumble of emotion and pointless (and ultimately incorrect) self-recriminations, these are intermingled with a funeral, inquest and countless news articles almost all of which manage to manipulate events for the sake of a more saleable story.
Ultimately, our family is left with is a list of questions that can never be answered, Why. What if. How could anyone do that.
Two years later and to many, our loved one is merely a statistic; another woman murdered by her spouse for what? Jealousy? We’ll never truly know.
Everyone grieves in their own way; everyone feels it differently. We didn’t have any advanced warning, no time to prepare; this wasn’t something that can be classified as an act of god. It was deliberate. Our experience opens our eyes to how vulgar and unforgiving the world can be.
It’s still very raw, that’s unlikely to change for the foreseeable future. Yet deep down, we know it could have been worse; that others have been put through events which make our own experience pale in comparison.
Yet even with all this, Claire would’ve been the first to start plying us with alcohol until we were all laughing and smiling.
She would’ve reminded that we should love every minute of our lives.
She would’ve pointed out that life has to go on.
For our children.
Keep calm and carry on, right?
I’m a software developer, I spend my week staring at complex code, muttering and swearing (sometimes even under my breath 😉) until everything compiles.
Grief complicates even the simplest task, it makes everything feel insurmountable and makes us question ourselves even when we have no need to. In such a situation, we gravitate towards effortless solutions in what usually ends up feeling like a meaningless effort to reassert a level of control over life.
Writing software isn’t just code, in the right mindset it’s an art form. Admittedly most users don’t get to see our art because it’s hidden away in compiled DLL’s and other encoded files.
When suffering from grief our thoughts are jumbled like the worst spaghetti code you’ve ever seen. As with coding, the only way to fix the problem is to search for the simplest class, function or module, take that as a starting point and simplify everything from that point onward.
It was that search for simplicity which fuelled the return to my creative side. As Headspace states:
Some of our greatest cultural riches are the byproduct of grief: the pyramids at Giza were burial mounds. Homer’s “Iliad” is a tragedy. Christian texts begin with the loss of Eden. From a safe distance, we admire and appreciate the creative fruits grief has harvested over the course of millennia; collectively, humanity owes a whole lot to heartache.
This simple statement was something that echoed in my mind, albeit on not anywhere near as grand a scale.
In one way or another, we all yearn for simplicity, the feeling of grief merely accentuates that feeling, bringing it to the forefront. Grief makes the smallest things feel that much harder to achieve, it creates a feeling of distance between ourselves and the things around us which if we’re not careful, can snowball into something crippling. A sentiment with which I became innately familiar.
Return to work
So, on to nicer thoughts… In the office, among the multitude of our internal systems is our development task tracking application; it’s a bespoke tool written in ASP with an appearance which wouldn’t have looked out of place in the latter half of the 1980’s.
As an internal system, it’s always been on the back-burner as far as bug fixes and enhancements are concerned, despite being used by the majority of the team on a daily (if not hourly) basis. More often than not, any updates are hastily applied so that more time can be devoted to the products that keep the company running 💹.
Because of this, its usability is poor. Sure, the various behavioural oddities and workarounds become second nature, but in the midst of spaghetti-brained grief the tool I’ve been using every single working day for the last who-knows-how-many-years was making my life harder.
I realised that I could actually get the data I wanted more quickly by querying the database directly than using the front-end application. During a grief fulled rant on the subject a trusted colleague pointed out the obvious — we’re software developers, so if we can’t fix it who can?
Ordinarily I probably would’ve thought of this as not being my problem, after all, we’ve got enough work to do as it is. But grief does funny things to you…
It’s a known fact, that there simply aren’t enough hours in the day to do everything we want to do. This is very true of the software development world, where sometimes we’re forced to pick between doing something the right way, or doing it quickly.
But a project inspired by grief can’t function in this way. Everything needed to be perfect and that’s something that can’t happen with an internal system.
So, this was to be an unapproved, out-of-hours project. Projects of this nature allow us to experiment with different concepts and ideas, we learn more in this sort of situation, where the constraints of time and money don’t apply but there is still a purpose to the work at hand.
Before long, I had transitioned through half a dozen different design prototypes and rediscovered my creative side, realising that this was the sort of venture that I so badly needed.
In time, I came to the conclusions that anything I built needed to follow a few basic tenants:
- A simplistic colour pallet. Two or three colours supported by application areas defined by black outlines and white or grey interiors.
- Minimal interface. The existing functionality needed to be preserved, but there’s no point in littering screens with operation buttons which add clutter.
- Multi purpose components. A pop-up isn’t just a pop-up, it provides a status indicator, a tabstrip isn’t just a navigational tool, it provides statistical information. The possibilities go on…
- All pertinent information has to be available at a glance, minimising additional navigation and providing an immediate overview to the end user.
- We can draw attention to product areas with animations, but using fancy animation to reveal product areas only serve to slow the users progress (I really should’ve known better before trying this).
The existing tool isn’t overly complex, but it does provide a plethora of options for use by the various teams. Beyond a few more basic options, not everything is used by everyone. I could have introduced use options to define different user types, but as a personal project I didn’t want to mess too much with the underlying data structure.
This restriction meant that the majority of my work had to be restricted to the search process, but as this was the area of the application I had the biggest problem with, this wasn’t an issue.
My issues with the existing search functionality could largely be broken down into two categories:
- Complexity of the initial search screen and the difficulty of editing a search once it had been executed.
- The amount of information returned in search results which returned full descriptions of change requests (which could be quite long) while not providing any other information.
Both categories need to balance the amount of data displayed on-screen with simplicity of the user interface.
Balance between functionality and data is a core tenant of any search application. Hell; finding balance is a core tenant of life.
Following the design tenants outlined above, I split the existing search options into eight core categories, and then organised these categories in order of priority.
These categories are represented on the search screen with the highest priority options displaying on the first line (the number of options automatically adjusts according to screen size). Additional options are hidden behind an expandable section; this approach allows all users immediate access to core search options while advanced users can expand the options list to two rows of settings — a selection which is remembered in subsequent sessions.
Search functions are displayed using pop-ups; highlighting indicates the selected options. Initially users are only able to search for a single product, client or employee, but additional drill-down search options allow searching for multiple values.
This approach removes the need to navigate around separate application areas, everything is provided to the user within a single screen but is carefully hidden in order to prevent overloading users with too much information in one go.
There are of course additional screens which expand beyond those demonstrated here, but the design process follows the same basic principles of simplicity.
Grief makes a mess of our thought processes, in my attempt to straighten out some of that mess, I stumbled across similarities with basic design principles which helped me on my way but these principles aren’t really any different from recommended UX practices.
The process of working through grief requires simplification of thoughts, segregating the those that matter from those that don’t, stepping back from complicated tasks and allowing us to approach them when we’re ready.
It’s by no means a process that’s as easy as it sounds. Like good design, it takes time to achieve and there are many false-starts.
My grief has helped me come to the realisation that life needs to be simple, that the applications I write need to at least appear to be simple. Balancing the that simplicity with a hidden complexity is a skill that needs to be practised.
My only hope is that I don’t become as practised in processing grief as I am at designing applications and writing code.