Translating
Big picture concepts into designs
Attention to detail is immensely important but sometimes designers get lost and see the forest for the trees.
Seeing big picture means understanding how each small design decisions contributes to not just your vision but larger strategic vision of the product and the business.
Beyond convergence and divergence
Of course, double diamond diagram is a staple for every designer. We know what it means, how to use it and more importantly its value.
Namely, the problem as important as the solution.
But so is the larger context.
While convergence helps us all get aligned and be on the same page, if you are working in a close knit design team, where business stakeholders are far more removed from the project, this approach is not enough.
The bigger picture.
In my own work, (and perhaps due to the nature of consulting industry, where the client is an external agent and the awareness of business interests is ever so starkly present), I always look at the bigger picture.
-
Where is the company heading? What are their goals? What are their current priorities?
-
Where are they in the trajectory of their growth?
Converging business objectives with user needs is an absolute necessity to make design decisions that last and have impact.
Take for instance, a company that is trying to tap into a new market. While there might be user needs that could be addressed and small design enhancements, those that are aligned with its current goal and therefore will bring the competitive advantage in the market need to be prioritized.
Taking a convergence a step further.
As we all know behind every great designer is....
Well, a developer! And sometimes a team of them.
Working with external developer teams, who have a different approach, can be challenging.
-
At which point we accept the limitation of technology and scale down?
-
And when do we do the exact opposite?
Here is where the combo of user needs and business objectives come useful too.
We can find some answers by looking at those.
If the users are constantly complaining about a certain functionality and our competitors offer something superior in regards to that functionality, well, we might have to look into enhancing some of our technical capabilities.
But, wait!
What if the main goal of the business this year is to reduce costs?
What if we cannot afford it?
This is where the technological capabilities need to be balanced out with user needs and business objectives.
In fact, a lot of innovation is done by working with constraints (including budget and technology) and challenges as it forces us to search for not so obvious answers and solutions.
Some examples in my work
Both Brights Minds and Pay it Forward are great examples of mobile applications that created not to support an existing business but to set off an innovative idea.
With a great amount of creative freedom, there came challenges too.
Firstly, it was in defining scope. The user research in the discovery phase yielded a number of interesting insights and diverse pain points.
Combining those insights with competitor analysis (along with overall industry review - for Pay It Forward the whole idea was to fill the gap in the market) revealed a potential for the product that is not only desirable by users but viable.
While both of these case studies deal with design as a concept, there are few examples of my work that while I cannot share explicitly, I can tell a few things about (and most importantly, what I have learned from them!).
The Real Deal.
The challenge: Build an app in-house for the frontline employees day-to-day operations
Impact: High (Company's main operations depend on the success of software)
Timeline: 8 weeks incubation + 3 months to launch the MVP pilot version
They are big. Like real big. We are talking 10K+ employees.
They are also pretty old school. If you were define them based on the organizational structure, I would say they are deep in the orange but dabbling in green.
Low trust, high chain of command and hierarchy but also - design thinking and centre for innovation.
The core project team consisted of SMEs, designers, developers and a project lead.
Designers and developers were both external to the organization in question.
As a designer, I was from one organization, whereas developers were from another.
Straight away the first challenge we confronted that we were dealing with is having people that used to starkly different organizational cultures (evident from weekly meetings) but more importantly approaches to work.
Let me paint the picture.
Starting Backwards.
Or as they call it.... the 'waterfall' approach.
One of the very first things I was presented with after a conversation with developers is guidelines to current software capabilities. Not making things 'complex' was the priority.
But wait isn't the goal of the project is to determine feasibility?
Yes but in the old school world, and unfortunately still in many organizations today, it starts with outlining business requirements (often a collection of stakeholder opinions) and technological limitations (often chosen due to its cost efficiency). But if those considered in isolation without looking at the user needs, then the solution is very likely to fail.
For myself as a Designer on the project, getting in front of the users as early as possible was paramount importance.
But not everyone on my team had the same perspective....
The UX Nightmare.
User research was a contested topic on this project as it still is in many organizations today.
The resistance was strong, the pressure was high and we had no control of actually getting to the users ourselves.
Everyone wanted to see tangible results (aka wireframes).
Initially, we worked off the current solution that people were using, which included everything from Excel documents and emails to pen and paper.
So while we got access to these resources, we didn't know how users were actually utilizing them, what was important to them and why.
We knew what was important for the business and in the client's view that all that mattered.
And so the reason I am telling this story is because I understand that in the real world, we don't always get what we want and may face resistance to our methods, along with people who question our expertise.
So what do we do?
We pivot.
Show them, not tell them.
If you think about, we can apply Design Thinking almost to any challenge.
And so we did.
To the very challenge we were experiencing.
What if we looked at our stakeholders as users? The end users of the product that we are selling which is our services. Even though it technically was already sold, the understanding of the value and our appraoch wasn't there.
The solution?
Ask questions and empathize.
We tried to look at our stakeholders from a different perspective, humanize them and understand that differences in background along with years of work with a different structure and approach meant they had little understanding of our world.
How does that make them feel?
Disempowered.
Not good.
I got together with another designer on my team and we brainstormed some solutions, closely listening to the recordings of our meetings for clues.
Since everyone in the team had a distinct job, stakeholders didn't merely wanted to be included. They wanted to feel valued and needed.
They also wanted to feel like our partners.
They also had a starkly different approach to ours, so how do we educate and create a shared understanding while still maintaining a partner relationship?
We transformed some of our meetings into Learning exercises.
Where each person or a group of people can share what they considered was important information with the whole team.
Those sessions were immensely useful as we quickly realized how much valuable information and resources our stakeholders brought with them
.And honestly, it was such a better understanding of their expertise then your usual introductions of "I am Brian and I work in this department with super long name that half of the people in the room even heard of".
In our turn, it gave us an opportunity to share where we are coming from, talk about the value of user research and also the expertise that goes behind it.