Scenario 1:

What technique would you deploy when you want to understand your app users better? How do they perceive your app? Why do they do or not do certain activities?‍

Regular user interviews, perhaps?

Listening to your real users is one of the ways to empathise with your users; you get the first-hand experience. Interviews give critical input that influences product roadmaps.

Team members are no different. Talk to them regularly to understand what motivates them (or doesn't) to do their job that you intend them to; more importantly, the one for which they signed up. Document conversations so you can see how environment, situations, other team-related, organisation factors influence them to do something good vs. great (or not do at all).

Why not put effort into putting those conversations in frameworks? Why not go over our notes a few more times to understand better? Why not synthesise our findings to taking action for our team? After all, we do all of these for our app users, don't we?

Scenario 2:

What next steps would you take after finding out that after multiple iterations (over quarters), usage on a feature is non-impactful?‍

Re-think your feature offering/ positioning. Or, in some instances, drop the feature.

It's a regular practice in organisations to look back and evaluate all the features ever built and how they are performing. Analytics data, attribution to NPS, revenues are some of the ways to measure this. If something eventually doesn't work, folks go back to the whiteboard and either come out with a revised plan to try something different or drop it. A while ago, at a company I worked, we were trying very hard to make 'chat' work. Even after two years of effort, maintenance of the feature cost us way more than the return. We eventually canned it.

At your place of work today, there would be methods, practices, tools, even people where you are still investing but don't see any impactful return. The tool is only adding operational and staff-hour overhead. The legacy practices are slowly injecting bureaucracy in the system and are slowing you down.

If you see yourself in these situations, make a call and move on. Decide to change the process/ the tool and move on. Decide to drop an unessential step in your development cycle and move on. Decide to let go of the person because it's no longer a good fit and move on.

Scenario 3:

You've been designing the product for months. Looking back, you realise that content is all over the place. The workings of new app features are no longer apparent to users. Your onboarding content confuses users. Worse, there's no onboarding. What would you propose to stakeholders to pick on priority?‍

You'll likely advocate putting effort into content strategy. Define objectives, tone, and guides; have a centralised wiki of all copy even.

A new person joins your team and asks for past usability test documentation and reports; asks a question about an action icon in the app from 4 years ago. It's almost impossible to direct them somewhere, which doesn't include a Google Drive search or a Slack search, or memory. Questions like what were the trade-offs one had to make, what were the tech challenges, are they still relevant become challenging to answer promptly.

Lack of guidelines, centralised wikis, and explainers make it heavy enough of inertia to move past. Result: Onboarding of new members take time. More features you develop, the more scattered your un-documented design knowledge becomes.

However, if you take out 20 minutes 3 times a week to document every iteration of a design, after every design decision made, after every flow of design that solves a particular type of problem, you'll create a rich repository of knowledge that is simple, easy to understand, and scalable.  

At Cuddle,  we mostly do it in writing long-form, presentation decks, and explainer videos.