Product design doesn’t have anything in common with processing intense grief. Does it? Sometimes we have to be forced into taking a step back in order to see the obvious.
Everyone grieves in their own way; everyone feels it differently. In our recent experience, 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.
Spaghetti-brained grief
As a software developer, I spend my week staring at complex code, muttering and swearing (sometimes 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 smallest 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
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 was always on the back-burner as far as bug fixes and enhancements were 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...
Grief-inspired design
It’s a known fact, that there simply aren’t enough hours in the day. 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 wasn'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.
Finding balance
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.
Results are split into a collection of tabs based on current status, these tabs provide item counts to provide users with a quick overview of current statistics.
A further set of sub-tabs reveals additional options for advanced users.
The display of search results follows the same minimalistic principles. Results are contained within a traditional grid but columns are merged in order to provide display large amounts of text in a more natural manner.
The provided list of columns are sensitive to the existing context, while additional options are provided to allow users to expand upon these defaults.
A quick-scroll area is provided on screen to allow users to read through the entire description without navigating away from the list of search results.
Additional features allow users to drill down to reveal further information. Tool-tips reveal user contact details while selecting individual records within the search results screen will provide access to further information and full task history.
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.
Conclusion
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.
Top comments (0)