How to engage dev folks to design great interactions

In a typical design process, agile, waterfall or Design thinking, the role of building features often comes down to laundry list of features after ideation. Development teams often pick the list, prioritise, estimate and go ahead to create a build plan. During ideation sessions, it is hard to involve an engineer who is stuck in execution pressure, lift him from a delivery deadline, ask him to participate in open brainstorming on a new product possibility. Often avoiding ideation with team leads to low energy of execution and ownership. I strongly believe that one who finally codes has the best opportunity to make the impact. But how?

1. Convert your Pre-planning meeting into a problem redefining meeting

Pre-planning meeting is weekly meeting to discuss and take inputs on “Coming Next” features as mapped on a typical product roadmap. As organisations get bigger and you start seeing the “processes creep” in and slowly remove the essence of a meaningful meeting. It's time to wake up seize the opportunity to create value, fun together with the team. How to break ice here? Start with a simple questioning process that can be a disturbance to those who do not like to listen to signal of change. So the trick is to list the plan, and turn around the discussion to “ What problem does this feature addresses ?” and hence “What problem are we addressing here ?”

“Re-defining is a way to accommodate a perspective”

2. Question the feature by asking “what problem are WE solving?”

We wanted to design a Search, filter, advanced search, search results on a mobile app. Well, technically it was a straight rip-off from the web experience with the usual UI guidelines advised from Google or Apple. Adding a few minor details, the discussion could have been ended right there.

Instead we tuned around and asked “What problem are we solving here?” to our users, partners, business and platform? This triggered serious debate on should it not be part of product strategy meeting! Fun part was to give this a quick try from each attendee and ask him what does he think here that we are solving. Responses were great and slowly the discussion was guided to key questions like:

Why should we design search? Is it working on web? Do our users use search? If so, what do they like to search on our platform?

We quickly asked our data-guy to run some queries and help the questions get some light. It tuned out that search on web engaged nearly 40% of our overall users and was increasing incrementally week on week.

Team found this valuable, and explored to dig deeper. If our users are getting these value out of search, how can we simplify its interactions, improve the quality of results and finally persuade the user to commit on our mobile app.

“A good question is likely to change everything, else it certainly evolves the current status quo”

3. Share your grand vision upfront

It often helps to sketch the light at the end of the tunnel. The big picture sketch of the problem you are solving enables the team members to build faith in the idea. In our case, we discussed “Search” as potentially opening up the key information to our user base eventually unfolding 10x more ways of driving engagement and conversions. This is an exercise to see is this effort “Sell worthy” to anyone. Engineering team quickly found the value in this analysis and started counting ways to increase and improvise many product metrics. Though it simplifies users life, it also creates number of opportunities to increase overall commits across platform. Let this vision sink and guide team mates to evangelize.

“Clarity of the big picture secures so that we can take risks !”

4. Invite dev team to drive the white-boarding

Yes! encourage and support collaborative sketching. Ask a designer to moderate and quickly help the ideas of dev shape up as rapidly as possible. If an engineer is shy give him sticky notes and simply ask him to put his ideas and arrange it in a flow. Our development team loves to give names to each sticky notes, add buttons and use a sketch pen to establish a relationship between pages. If an Engineer has a idea of writing down a piece of code, help him visualize its relationships.

As we ideated in how to simplify search for our users, engineering team came up with auto-suggests while the user typed, comparative filtering of search results, sector mapping, scaling filters and so forth. Designer seized the occasion and sketched deeper outlines or wireframes in spontaneity or a flow.

“Let the ideas enrich your larger goal that you have set for yourself and team”

5. Avoid competitive benchmarking of features, re-focus on the problem

It is natural that as one is involved in solution making to quickly quote “Best Practices”, “What competitors are doing”, “A new technology they browsed recently” and so forth. This is a digression from the problem you are trying to solve and in the process of ideation. Say “NO” to benchmarks here. We may take it later.

“Some things are good for later”

6. Help engineers get the right information for their idea to come to reality

As a moderator of this process, I own the responsibility to ask and provide as much as data possible required for the ideas to flourish. My data buddy comes first in the list. Let him participate in the ideation and run short queries to gather unusual data points that help us build on the idea. For example, we were not sure how many of our users are “Filter Freaks”- meaning, how many exhibit the behaviour of using filters while searching for the information.

Our data guy was quick to show us that 15% recurring users like to use filters at any point of time. But is that good enough? One of our engineers suggested that what we are calling filters are not really “Advanced Search” they are simply slicing our databases by topics we have tagged. This insight helped us to separate “Filters” from “Search” from “ Search results” or from “ Search suggests” as multiple product points required to enhance the overall search experience, what the Gestalts or Indian Shunya calls the effect of “Whole” from the “Parts”.

“When we work with diverse minds we work better”

7. Estimate the business value of the idea immediately, enjoy a buy in

How do we know if this all worth it? We do not need the whole marketing team or a nod from CEO to tell us that this is valuable. List down as many possibilities this idea can possibly generate to improve core product metrics. We focused on amount committed per % user retention to see product impact. Solving this problem should increase touch points for % increase in engagement resulting in more commitment in actual. If you are conceptually comfortable, fix a time with business folks to run your idea to arrive at a projection number.

Have clean blocks of time to work out estimates

8. Take a break, not for too long

Ideation can get hectic. It is hard to get detached from your million$ idea! It’s ok to completely forget the context, get out of the meeting and sip some coffee. Mind needs processing time for reflective action. Assemble in a evening meet-up usually in a canteen or outdoor space and reflect upon the morning's session. The unwinding would have created space for reflective action resulting in richer view of the problem. Let the development team now have the support of the designer and business to get the idea executed. Pods of 4–5 is good number to encourage ownership of the idea.

“Process your idea in a state of awareness and not in thought alone”