Thinking Design in Process

I've never been a theory-heavy person. With years of training the field of Neuroscience, Physiology and Behavior, I've been taught the practicality of the animal form and the rules of homeostasis. There were no secrets here. If you were grumpy for a day or two, it was due to a bad feedback mechanism releasing hormones or neurotransmitters that activated stress pathways. The cure would be to get some rest, wait for your body's balance to equalibriate, and then go on with your life. If the problem persists, there would be pharmaceutical solutions for it.

This logical, yet very constrained view of the human body had prepared me enough to pursue a career in medicine, physical therapy, or one of the many health industry-related routes, but didn't address much of why people did things, let alone put a stop to certain harmful behaviors that were causing them to be unhappy to begin with.

In medicine, preventative maintenance was always suggested and backed by research, but rarely took into account user needs, their mindset, or the contextual surroundings of their respective environments. It was then that I decided to shift my focus to developing solutions that would place user needs as a priority.

I decided to do it through the medium I was most familiar and enjoyed working with: technology.

Years later, I found myself working in IT and writing for an online media company about the topics of interior design, home technology, and software solutions for the domestic space. It was a stepping stone for a career change, but it was my transition into the field of Human Computer Interaction Design that led me to the realization that designing for delight was far more satisfying than designing for failed physiological systems. It was here that I embraced the reason why I was the only person to keep a sketchbook with me at all times during my medical internship rotations. It was here that I solidified my design process that reflected everything that was me.

It was also here that I started to do a psychoanalysis on myself in order to discover how I thought about the world around me, consciously using that as a reflective tool for feedback to how I adapt to ridiculously messy design spaces.

So how does one master the art of problem setting? I believe the basic building blocks to a great design starts with a few well-framed questions that usually result in lots of good answers. This helps build constraints, although like any foreign problem - talking to the experts tends to get you the best insights into what users truly need. Thus, exemplar research, interviews, and focus groups (when a larger pool of feedback can benefit) tend to be essential at the start of any project, but it's even more important when dealt with an unfamiliar space.

Above is the typical product life cycle for technology development. But one should realize that it often looks something along the lines of the diagram seen below (courtesy of Joyce Hostyn of Open Text).

Getting that thread to unravel is probably one of the most difficult things to do; design isn't a straight forward, linear, or quantifiable process. Design is about research, analysis, intuition, and synthesis, but it's also about designing meaningful solutions that get used and not thrown out after a few week's use (unless you're designing for that). It's about addressing problems creatively and with heavy doses of empathy scattered throughout. Socio-cultural context cannot be ignored or misunderstood.

So, when presented with a problem, I enter what I call, "sketch-a-holicism." I use pictures and exemplars to familiarize myself with the space. These can be gained through ethnographic observation, short interviews, and mind-maps that connect the dots without having to invest hours and hours in pointless affinity diagram exercises. If funds permit, I always go to the area of implementation and embed myself into the culture, just to see what it would be like to face the problem at hand. I consider this a quick dose of first-hand research.

Note: It's also probably not a bad idea to invest in a really good portable camera. Any signs of inspiration along the design process will benefit greatly by contextual photographs that have a story behind it.

At this point, many will jump the gun and dive into the books. I say to hell with that. If I can't experience and immerse myself in the problems first-hand, then there is no problem. A simple re-design of an existing solution will suffice and will save time and money for everyone.

After initial research, it's good to immediately consider what you want for the end result to be. Expectation management is probably one of the most important things to consider the design process, so don't ignore this. Finding out what the client really wants and what he/she says they want is a few days' work all in itself. I never rush through this process. Define what needs delivering. Then... plan to overdeliver.

I'd also point out at this point that the best part of design is being able to come up with sky-high, crazy solutions that make sense to you and only you. The second best part is being able to argue for it in a presentation to stakeholders and have them meet you on the same page. It's an exercise of elaborate communication. It's pretty much the closest thing you can come to diving into the dreams of the other person.

Thus, the ability to communicate with clients and keep the on the same page constantly throughout the design process is essential in managing their changing expectations throughout the product's life cycle - being able to catch these dynamic changes is a skill worth investing in.

After solidifying the deliverables, exploring the space a bit, and getting the client to match my pace, I jump into simultaneous overdrive. This process consists of a mix of concept development alongside exemplar, literature, and expert research in the field. In many ways, you can consider this when I hit the white board with my design team in quick, weekly meetings to consolidate what we've gathered for concepts and research. Critiquing ideas and using sandwich model compliments, no idea is left behind and no idea is too crazy or stupid.

But eventually, decisions must be made. I tend to take lead in such situations, placing emphasis on timelines and schedules, as well as re-framing the current problem space (which is iterated again and again after each play session a.k.a. weekly design meetings) in order to give folks a good idea of where they are in the design process. If it's just me on the project, then I usually keep an on-going self-tally of the decisions made up until that point with the rationales behind each step forward. These are good for reports to clients.

When it's time for building the prototype for testing and iteration, I often leave it on autopilot. If the problem was framed well and the right questions have been addressed in the conceptualization phases, then the rest should be a matter of getting it into the hands of the target populace and seeing how they react to it.

That's not to say there's no skill involved in interviewing and managing test subjects' expectations. Focus groups and test sessions can often be expensive and time consuming since companies must pay for both the participants and the user experience expert conducting the experiment. It's important to use the rule of: Plan twice. Execute once. Have the proper questions ready and don't waste a second. However, it's up to your professional judgement whether the experiment must stop, requires further questioning, or needs a second iteration in order to gain better insights.

This should've been mentioned before, but I'll say it now: It's also important exercise to monitor your biases and thought process. Everyone has them. Whether you're an engineer, cognitive science, or design background, what one considers "aesthetically pleasing" will tend to vary from 'kinda cool' to 'brilliant.' Knowing your biases will help you manage them - so you don't end up with an annoyed tone when subjects don't "get" your design at all.

By now, a pretty concise target and direction should be apparent and its refinement that takes that "pretty good idea" into "elegant execution." At this point of high iteration and beta testing, I also consider all the points of implementation: Acceptability, marketing, remaining funds, and time schedules for release. It's vital that the design withstands the test of time (or again, if it's designed to be destroyed, that it does so within an accepted time window). It's also important to keep the client in the loop, especially during these preparations before launch. The client should be made aware to the risks involved for each decision to be made at this point, reducing designer/project manager responsibility and merging responsibilities to disperse risk to the proper parties. One man alone should not be taking the bullet for a failed project. Everyone is responsible for the decisions made at some point in time.

Reflection is key to growth. At the end of each project cycle, I make time to write down the strengths and weaknesses I encountered. Here, I discuss how my team can grow from these points (perhaps pairing a professional with someone who's animate to learning something new) and taking a few days off to reboot for the next project.

It may be just my IT side speaking, but I see the field of design as very much like computer science. Programming languages changes all the time, but so do expectations and user needs. It's up to the practitioner to stay up to date with tools, build a repository for best practices, and adapt for constant change. Only then can the 'thinker' meet the 'designer' at the end of the tunnel.