Design like a User

I once spent 3 years designing an application.  Between creating mock-ups, logical diagrams, and proposed architectures, I spent the bulk of my time discussing the application.  I'd sit with various people who I knew would need to interact with it and learned what they liked, didn't like, thought I missed, or fathomed would be a burden in my specification.  I talked to clients, learning about the demands they faced, the urgency they had when seeking information, and the knowledge they needed from our platform.  My first duty in design was to listen.

I lacked the formal knowledge of a typical developer.  I learned about backend database structures through conversations, research, and testing.  I practiced Boyce-Codd Normal Form before I knew it was a thing, creating Excel sheets and using VLOOKUPs for the information I needed.  Maybe, if I'd have this knowledge before, I'd have a solution faster.  Instead, I learned, looked, and listened.

My first duty in design was to listen.

As an interpreter, I'd seen people create masterpieces with words.  I'd observe the greats on stage, their faces, shoulders, bodies, and hands crafting art with a message.  Seconds later, their movements would be elsewhere, but the impression remained priceless.  As a designer, I sought these ideals in my product.  I wanted the user experience to have harmony with the motions of the job, to support it every step of the way, each piece carefully scaffolding to the next.  I wanted it to embody the company brand, so there was no denying its place within the company.  I wanted an opus.

Most of all, I wanted to solve what was becoming an undeniable problem.  The infrastructure in place was struggling to meet the need and our clients wanted more.  It was time - time to move on from what we had, time to push the envelope not just with our services, but with the systems that supported them, and time to take paper to programming.

I wanted the user experience to have harmony with the job, each piece carefully scaffolding to the next.

My exploration served as a roadmap, helping guide pieces of an overall larger project, but it also set fire to something inside of me.  As my career progressed, I found myself designing software again, albeit on a much smaller scale.  Data visualization, when done well, functions much like a mini-application.  It provides a consistent look and feel, guiding the user appropriately through gathering insights.  Ideally, it projects its ideals at first glance.

I was not a natural developer.  I came from the business side, so calculations eluded me far longer than they likely should have.  I could see what I wanted to achieve, but getting there presented a challenge.  Kind people, like Michael Cristiani supported my learning curve, endless questions, and rants about what seemed like arbitrary difficulty to do simple things.  Yet, I chipped my way slowly up the mountain again, learning the logic and language of Tableau.  Now, I enjoy figuring out how to do the impossible, whether circumventing pre-level of detail calculations with cascaded sets or creating visualizations that match the ideas in my head.  

Data visualization, when done well, functions like a mini-application.

Yet, one thing remains constant: a fastidious desire to do right by my target audience.  It's not enough to design an application I enjoy or think meets the specification.  It's the users.  The design should support them, it should force them to take pause and notice the details, and it should feel intuitable.