Category: General Stuff

When entering a situation for the first time, or when re-visiting issues later on in the cycle, there are a few critical questions that as a designer you should continually ask (at least subconsciously if not always out loud) to avoid confusions or misunderstandings downstream.

1. What assumptions are we making (about the user, task, context, technology, marketing requirements, etc.)

2. What are the dependencies if any? Should team x be aware of what’s going on with this part of the product? Does team y know about team x’s change request?

3. What are the expectations for this feature (held by stakeholders, customers, users, etc.)? Do we need to adjust those expectations due to changing circumstances, etc.

So in sum, always examine your assumptions, dependencies, and expectations and make sure everyone is on the same page! It’s hard to remember this when you are suddenly thrown into a situation or aggressively pounced upon by an engineer or product manager, but it pays off invaluably down the road in complex, multi-disciplinary contexts.

I must confess–I find it amusing when people talk about “the” design process as if there were one final absolute ultimate standardized process that always guarantees success. Hmmm! Even I’m not sure what that really is! In my mind there exist multiple flavors of a general “ problem identification/solution creation ” process or methodology, with different steps depending upon the company, industry, and individual characteristics of the designer, as well as personal range of experiences, and evolution of preferred methods.

Fundamentally a design process features cyclical iterations. Not just iterations for the sake of iterating, but towards resolution, winnowing down multiple possible options (hypotheses) to get to the optimal/sufficient/viable solution for a given problem. It’s also cyclical–there’s a 360 degree revolution from start to finish, then starting again with different problems and situations (that may have emerged while investigating the initial issues, for instance). Or you may have to hop back up or jump ahead to other steps per emerging information or changing circumstances. It’s this fluidity and dynamism that I realize confounds non-designers (i.e., engineers and product managers). It’s not a recipe, nor a formula.

Also there’s something else that is difficult to pin down and quantify but must be accounted somehow: that serendipitous spark of brilliant creative insight, often expressed in terms of aesthetics but also it could be clever mechanics or nifty usability or a compelling story of use. To outsiders this must all seem quite confusing, chaotic, or even a bit mystical. Yet there is actually a general overarching pattern and structure, moving from problem to solution.

Here’s my take on the major phases of my particular flavor of “the design process”:

Understanding: a phase for becoming deeply informed about the users, market, industry, domain, competitors, as well as learning stakeholder concerns, issues, values, goals, etc. and ramping up on existing products if available. This will help identify the core problems and shape the personas, scenarios, and overall problem scoping. This is paramount. If you’re not solving the appropriate problems, then the entire design effort is in jeopardy. What is meant by “appropriate”? Depends upon the user, context, goal, task, etc. :-)

** Verify your personas and scenarios with real users and other stakeholders to ensure accuracy. (like the old adage, “trust but verify”)

Modeling: a phase for articulating the pieces that help in later design work, mapping out the objects and data/tasks/flows in the product or system, modeling the main workflows and tasks, and laying out the overall architecture of content and functionality.

These result in analytical artifacts, mostly diagrams for starting critical conversations and getting initial consensus and understanding/agreement from major stakeholders about the skeletal frameworks for the product (especially true for digital designs, web apps, software, services). Architectures are key here too: screen architecture, content structure, etc.

** Assess your models with Product Managers and Engineering leads for completeness of capturing and representing all the relevant tasks and objects and functions, etc.

Visualizing: a phase for actually designing possible solutions, with hand sketches, wireframes, mock-ups and prototypes all done as needed to help identify which options work best for your particular situation.
** Evaluate the visualizations (of whatever fidelity level) with your users via usability tests to catch usability problems, missed features, etc.

Hopefully issues of flow and architecture have been resolved by this stage, but more likely they will be often revisited as greater fidelity of the solutions emerge, especially at the prototype level. There needs to be a general understanding that phases can and often will need to be revisited but this should not be considered “failure” or “wasting time”. It’s all part of the practice of designing!

However, excessive re-addressing of design solutions should be avoided with the help of early upfront activities and artifacts like personas, scenarios, flows, and other items which help identify major requirements and so forth.

And as for that spark of creativity…personally I believe that true designers are always sketching and thinking and writing, jotting down options and alternatives, even when a phase isn’t “done” yet. Or if you’re leaping ahead downstream, that’s OK too. Naturally thoughts and images come to mind, just jot them down. Try things out. Sketching is a great way of probing and reflecting upon issues, just visually. It’s a way of freeing up your mind and getting ideas out there. A lot of it is just statistical: it often takes tons of ideas to get to that good one. So keep generating even while researching and meeting with stakeholders and drafting models/architectures. Developing this habit early increases the creativity potential (as well as open whiteboard brainstorming sessions with stakeholders), so I think it should be folded into “the process” from the beginning and doesn’t become a mad rush at the end to conjure up “the solution”.

So in the end, for me a well-thought out and compelling design solution results from informed understanding + personal ingenuity/creativity + collaborative inputs + technical viability + commercial value.

(I will most likely re-visit this equation, many times! :-)

Problems. And a passionate desire to improve upon problems found anywhere.

But to elaborate more on that…I think there are at least two (and certainly more…coming soon!) critical factors that shape the kind of designer you are.

1. The questions: Do you like to ask questions about the user? About the technology? About the business? Ideally all of them, but I’m betting that some designers are more naturally inclined in one orientation than others, which is fine. Also, do you like to ask tactical questions of construction and production primarily? Or more strategic questions about the product lifecyle, platform, ecosystem, etc. Or perhaps conceptual questions proposing hypotheticals, that drive research imperatives and foresight activities?

Just as Trinity told Neo in the nightclub in The Matrix: “It’s the question that drives you.” So what question burns in your mind? That more than likely shapes type of designer you are or strive to be.

2. The artifacts: What do you like to make? What artifacts from the design process do you naturally gravitate towards or have affinity for? Do you like the flows, diagrams, models, and maps? Or getting into the pixels and code? Or maybe somewhere between? Hopefully not excel spreadsheets! :-)

3. (possibly third one) Users/domains: What kind of domains and situations and users do you like to design for? Enterprise? Consumer? Mobile? Medical? Again, no right answers, just something to reflect on for yourself in terms of what challenges you as a designer and gets you excited, what you naturally gravitate towards, and keeps you thriving.