From Concept to Creation: Unleashing Strategic Thinking in Design

A framework for designers on how to adapt their thinking and play different parts while designing products

A tiny backstory

As an architect by education and UX designer by profession, I have realised that there are tonnes of parallels that can be drawn between the 2 industries. While the tangible results between the 2 are quite different, there is a great amount of common ground in the way both of them help us view the world, and think about design. Balancing aesthetics with usability, while paying great attention to detail are key factors that unite the two.

Moreover, the ability to rapidly zoom in & out, to simultaneously assess the big picture, while being observant to minute visual elements are another obvious similarity. For example- having to dissect the challenges a physical site poses, like topography and wind direct vs knowing the nuances behind creating a custom door details.

In the world of product design this could be translated similarly: From understanding the objectives for a business and for users on a higher level, to crafting the most delightful micro-interaction to spark user joy. However, one of the most striking similarities between designing physical spaces and digital products is:

The designer’s capacity to synchronize their thought process basis the project’s current stage.

So, this blog is about some of my learnings (which I diligently, albeit messily scribbled in my notepad) while reading “The elements of UX” by Jesse James Garett. We’ll be looking into:

1. Why is it essential to know about these elements.
2. A brief overview of what are these elements
3. How can these help us in guiding conversations with peers and stakeholders.

Why do these elements matter?

Here’s a few thoughts that I was pondering over recently:

How often do we jump straight into designing high fidelity screens, only to realise that our objectives seem hazy?

And, do we sometimes get overly engrossed in perfecting an animation or visual, when discussions are more about high-level strategies?

…I know I have been there a few times🤪.

In order to get to the stage of addressing this, we must break down the task of crafting UI into a more granular level, to grasp the task as a whole. While this is something that we as designers unknowingly do in our day-to-day tasks, Jesse James’s framework can help us at each stage by:

1. Understanding the immediate requirement of the task.
2. Seeking the right kind of feedback basis this.

For instance, during preliminary ideation of a new feature, it’s essential to start with the vision, and eventually focus on the impact it can make through UI. Enough chitter-chatter now, let’s get to the main stuff. 😅

So, what are these elements?

As we move up the planes, the degree of abstractness decreases.

They are five layers that rely on each other, and they go from abstract at the bottom to more concrete as we move up.

#1 Strategy:

This is the foundation of any project. This is where objectives, both as product makers and user goals are identified and brainstormed on.This marks the beginning of the product design process, but that doesn’t mean the strategy must be set in stone before the project can move forward.

Goal 🧐: To get to the bottom of questions like: why are we creating it, would it add value to our users, how would the business benefit from this etc.

Tip💡: Strike a balance between framing your product strategy statement in a way that’s too general or too specific. Why? Because solutioning isn’t the goal here but the outcome should be clear.

High-level questions to ask in the strategy phase

#2 Scope:

Understanding a product’s key value propositions and diving deeper into how objectives set at the strategy level can be met.

Goal 🧐: To ideate on how these functional requirements would work with each other, and if they interconnect. After all these would become the means to help users accomplish their objectives.

Tip💡: Try documenting the objectives after/during discussions, so that it doesn’t deviate and the different approaches to achieve that objective are explored. Every approach/feature henceforth can be imagined from the lens of whether that objective is met. This way, we can assess if multiple features also satisfy the same strategy.

Different methods to map objectives to requirements

It also helps to write as clearly as possible when trying to grasp what we’re building, this ensures that there’s less that’s left to chance. When in doubt, write more than writing less.

Write clearly to induce more clarity at each stage

#3-Structure:

This element defines how the value props finalised during the scope phase start coming together. This is when the IA is fleshed out keeping in mind the content & functional requirements and the UI starts taking shape.

Goal 🧐: To start identifying metadata and defining them in a clear and cohesive manner. Grouping, ordering, organization and presentation of data come into play here.

This can apply to a series of different screens or to grouping within a screen.

An example of how to start organizing meta-data

#4-Skeleton:

Above the structural layer lies the skeleton, which defines what form these functions will take. It involves :

• Providing users with the ability to perform tasks i.e. interface design
• Helping users go places within your product i.e. navigational design
• Communicating ideas to the user in a systematic hierarchy i.e. information design

Goal 🧐: To start defining journeys, content, and navigational components..basically everything that can help users perceive the screen. This is where the journey starts shaping up in the UI.

Designing the flow for sharing a stickie

#5-Surface:

The last stage is the surface element i.e. the aspects of the product our users notice first i.e. sensory design. This is where visual and sound design really start taking shape.

Goal 🧐: To define the final visual output in terms of colours, typography, shadows, and refining the interactions. This is also when transition easing and micro-interactions on screens are defined.

Tip💡: When people comment that a design is “busy” or “cluttered,” they’re really reacting to the fact that the design doesn’t lead them smoothly around the page. Instead, their eyes bounce back and forth among a variety of elements all clamoring for their attention. One method that helps is following the “eye-tracking method” to understand if users are being drawn to what we as product builders want them to be drawn to.

After applying the visual treatment

Decoding the elements further

In the strategy plane, the goal is to stray away from solutioning. Here, we are not concerned with the final shape of the site, product, or service at all — we only care about how the product will fit into our strategy. On the highest plane, we are only concerned with the most concrete details of the appearance of the product.

This is when requirements and user flows are locked in, and the nitty-gritties of the product’s appearance must be scrutinised. So clearly, the planes are very much interdependent on one another.

Plane by plane, the decisions we have to make become a little more specific and involve finer levels of detail.

Practically speaking, as designers, we move rapidly between different planes but it’s important to keep the framework at the back of one’s mind, like a mind map. It’s best to move into the next plane when there’s adequate clarity to begin.

The choices we make on each plane affect the available choices in the next plane above it. Choosing an out of bounds option on an upper plane will require thinking decisions on lower planes

Ideal scenario: When decisions taken in the strategy plane flow into scope, which flow into structure

On a daily basis, following these planes with discipline may not be feasible. For example-If we are designing IA in the structure plane but the decisions taken in the scope plane were ambiguous, the result can usually be a lack of clarity on what needs to be executed in the current and subsequent planes. This can result in fewer choices for us going forward too!

If the choices we make do not align with one another, projects may derail and deadlines can be missed, resulting in an increased amount of effort by all teams. This interdependency circles into a ripple effect from the top, down the planes.

As we progress through the stages, decisions taken at the skeleton and surface level may be less costly. But pivoting on decisions made before the structure level can result in increased effort. So it’s essential to give equal weightage to the brainstorming and visual stages.

Common scenario: When requirements are revisited when in the structural plane

Why is this framework helpful?

More often than not, in day to day work, these planes do not function as independent entities with defined timelines. This process is likely to be a lot less structured and a lot more fluid and dynamic. Here’s some of the less glamorous skills that may help us as designers:

Knowing when to commence work for each plane, at the right time:

One of my biggest learnings (which I’m still learning to implement everyday) when collaborating with cross functional teams is this: It may be impractical to expect work in each plane to finish, before commencing work in the next plane, as the process is always ongoing. A simpler approach is to commence work in each successive plane, just before the requirements of the previous plane are locked in.

What I learnt along the way:

While most of the learning happens when one applies this framework to a project, this book also made me recall past projects and take notice of the application of this principle there.

1. Dissecting feedback:

Decoding stakeholders’ feedback and bucketing it into a specific plane can be helpful in knowing how to pivot. Is the problem that the functional requirements need to be re-looked into or will a visual change create the impact that’s necessary ? Several times, feedback flows in for decisions that are taken at the surface and skeleton level. However, if the previous 3 planes are disregarded and we jump straight to arrangement and visuals each time, we may have skipped addressing the critical why’s behind the product.

It’s not merely a visual change that’s needed, sometimes we may need to dig deeper.

2. Taking a step back:

In our day-to-day tasks as designers, it’s easy to get carried away and wear our visual design hats right away when a problem is presented. When we do this, we lose sight if where we began in the first place and why we landed on that specific solution.

One of my biggest learnings is to consciously ask the harder questions that are contained in the strategy and scope plane before letting things progress further.

Hope this framework helps you adapt seamlessly to the different stages involved in building your product! Until next time!