Product Management
The role of taste in building products
Taste is one of the hardest things to talk about in the product circles. So, let's talk about taste.
Take Marc Lou, a familiar figure within the Twitter Indiehacking circle. He's garnered attention for openly sharing his journey as a product builder. This transparency has piqued interest in his projects well before their launch, as followers have grown to appreciate his distinctive approach. A notable instance of this was the excitement around his AI logo generator, which swiftly climbed to the top spot on Product Hunt. Despite its remarkable simplicity, the product captured the audience's attention, largely because the audience already understood the creator's taste.
LogoFast on Product Hunt
Unlike indie hackers, and other product builders, companies do prioritise rigorous A/B testing and data-driven decision-making. As the projects involve larger teams, and processes, they subscribe to the philosophy of 'letting the data do the talking'. Take this snippet from Flo Health's Medium blog here for example. Each and every feature is rigorously tested and experimented before going live.
However, a shift is occurring in this mindset.
People are considering taste and sensibility, despite the fact that taste is one of the hardest things to talk about.
Brie Wolfson describes this inexplicability in his essay on Taste—
When I ask people what they mean by “taste,” they’ll stumble around for a bit and eventually land on something like “you know it when you see it,” or “it’s in the eye of the beholder.” I understand. Words like taste are hard to pin down, perhaps because they describe a sensibility more than any particular quality, a particular thing. We’re inclined to leave them unencumbered by a definition, to preserve their ability to shift shapes. But I don’t think we have to. And for the past several months, I haven’t been able to resist the urge to try to articulate taste.
This comes, in part, from a place of wanting to be precise — now that the term is such a frequent and varied part of our lexicon, it runs the risk of losing its meaning. But I also believe taste is something we can and should try to cultivate. Not because taste itself is a virtue, per se, but because I’ve found a taste-filled life to be a richer one. To pursue it is to appreciate ourselves, each other, and the stuff we’re surrounded by a whole lot more. So, how to wrap my arms around this term in a way that captures its spirit without flattening it?
I can’t think of a piece of writing that does this more effectively than Susan Sontag’s “Notes on ‘Camp.’” In her words, “a sensibility is one of the hardest things to talk about... To snare a sensibility in words, especially one that is alive and powerful, one must be tentative and nimble. The form of jottings, rather than an essay (with its claim to a linear, consecutive argument), seemed more appropriate for getting down something of this particular fugitive sensibility.”
Consider the approach of Linear, a company that diverges from the data-dominated decision-making model. Linear emphasizes the importance of taste and opinion in validating ideas and assumptions, rather than relying solely on A/B testing and metrics. This approach is about trusting one's gut in a product's readiness for launch, based on qualitative feedback and iterative improvements.
This perspective is shared by Jason Fried, Co-Founder of 37 Signals (makers of Basecamp and Hey). Fried challenges the notion that everything must be A/B tested, questioning the practicality and relevance of 'statistical significance.'
He argues for a more holistic view of success, focusing on overall profitability rather than the minutiae of individual product performance. Yet, the essence of 'taste' remains somewhat enigmatic. It involves an understanding of what makes a project or product resonate, balancing quality, appeal, and budget.
But there are some great examples showcasing this. Apple's approach to sustainability reporting exemplifies this. Apple provided a new spin to the boring 10-page report format, focusing instead on a creative ad campaign outlining their efforts in a smart, eye-catchy fashion. They could have done the same thing in a more convenient format, but they chose to do it differently.
Apple provided a new spin to the boring 10-page report format, focusing instead on a creative ad campaign outlining their efforts in a smart, eye-catchy fashion.
As Brent Schlender describes in "Becoming Steve Jobs," Apple's resurgence from near-bankruptcy was driven by Jobs' ability to harness 'trusted auteur directors' to realize a singular vision. Airbnb's Brian Chesky also embodies this concept of taste. His 15-year journey in developing a nuanced understanding of both the demand and supply sides of Airbnb's service has culminated in a distinct, qualitative essence that defines the brand.
Taste is nothing but intuition translated to action. It's your System 1 in action. A firefighter immediately notices thick smoke billowing from the house. All the years of training and experience has honed his instincts, and snap-second judgements. In split seconds, the firefighter is deciding on calls to backup, begin immediate entry, as well as identify escape routes to rescue victims.
Taste is nothing but intuition translated to action.
Who should steer the course of a product's development – data-driven product managers or visionary auteurs? Should the focus be on relentlessly testing every modification and feature addition, or should we trust in the guidance of these auteur directors to fulfill their promise of impeccable taste?
Dear enterprises, we're tired of your subscriptions
Software is eating the world. But are we eating it the right way?
When you build a SaaS app, how do you price it? The first option which comes to everyone's mind is a monthly/yearly subscription model.
While building Clarity notes, I was stuck with a usual question when it comes to building a SaaS—How should I price the app? We settled on the usual monthly/yearly pricing structure. It included a free version to allow users to try out the YouTube note-taking feature as well as a Pro Plan involving all the advanced features not available in the free version. We also tailored an Academic Plan, offering students an affordable option to take notes on YouTube.
I was not an expert in pricing while launching this app. However, it took me time to explore the various options available for pricing in general. If we take the mythical thirty thousand foot view, no matter what we’re actually doing with pricing, whether it’s a — non profit, retail, SaaS, DTC etc — we’re ultimate in the business of value creation. Price, after all, is the exchange rate on the value we’re creating in the world. In Pricing 101, the monthly subscription plan is just one of the many possibilities to set the pricing. There are multiple such value metrics, such as — per seat per 1000 visits, per CPA, per GB used, per transaction etc.
Circling back to the value metric of a monthly subscription we tried out for Clarity Notes, when viewed in isolation, this case might appear appealing — after all, who wouldn’t be tempted by a service costing less than a cup of coffee a month?
Yet, when considering the broader context of numerous SaaS apps and subscriptions vying for a user’s attention, the allure diminishes. In today’s gig economy, there’s a growing trend towards renting rather than owning everything — from daily news sources like the New Yorker to music playlists on Spotify, and even on-demand video services like Netflix and YouTube.
Sure, there are some costs associated with running software — ranging from customer support, cloud storage etc that could justify the monthly subscription model?
I came across this graph in Lenny’s newsletter which depicts the opportunity cost of not setting the pricing to the right value metric. We’re missing out on revenue by charging just a flat monthly pricing.
If you remember back to your high school or college economics class, the professor put a point on a demand curve for the perfect price and said “the revenue a firm gets is the area under that point.”
The problem here is — what about all that other area under the curve? You’re missing out on that revenue by charging a flat monthly fee.
37signals rolled out an antidote to SaaS monthly subscriptions models with Once, which is a heretic to what it calls the “Church of Recurring Revenue” by selling software the old fashioned way: pay once and host the software. Just because software isn’t sold in a box doesn’t mean it has to be a subscription. “The post-SaaS era is around the corner,” promises Jason Fried, CEO of 37signals.
SaaS still makes sense for many products, but its grip will slip. Installation and administration used to be hopelessly complicated, but self–hosting tech is simpler now and vastly improved. Plus, IT departments are hungry to run their own IT again, tired of being subservient to Big Tech’s reign clouds — Jason Fried
Enterprises might also be facing various other hidden costs apart from hosting tech and providing customer support. Take this software for example — Audionotes.pro
It’s an application helping you take automatic transcriptions of your audio notes. Audionotes is basically a Bubble application made on top of a GPT-4 API helping process and summarise notes better. It’s a wrapper on top of a subscription wrapper (Bubble) on top of another subscription wrapper (GPT4 API). And we pay for all the wrappers together (as a subscription)
In the long term, the users pay the brunt and might churn from opting into these subscriptions. (It’s one big pyramid scheme of subscriptions for the user). We also cannot blame the enterprises as they are also heavily dependent on various other enterprises offered as subscriptions.
Taking these factors into account, I’ve realised that Clarity notes is not just competing with other Youtube note taking apps, it’s also competing with Youtube, Netflix, Spotify etc. All of us are eating into the same monthly salary, piece by piece.
Which makes us think — Are there any alternative pricing models when it comes to SaaS products?
We’re seeing various innovations in SaaS pricing. Let’s look at five different software pricing models that don’t default to a monthly subscription model.
Lifetime deals
Once you purchase and redeem a lifetime deal, you have access to that tool for the lifetime of the product.
This might seem like a great option for users. You pay once and forget about it. The company also can benefit from the immediate capital injection. They are phenomenal for getting early adopters onboarded FAST.
However, growth might slow down when the lifetime deals end. In this regard, monthly subscriptions are considered a more sustainable offer for the enterprises.
Not just that, with lifetime deals, there is also this risk of complacency in updating and adding new features. However, in subscription models, this comes as a part of the package. Indiehackers place their apps in SaaS boutiques such as Appsumo for getting more visibility.
Lifetime deals + Monthly subscriptions
iA, the popular writing software has a very contrary take on their SaaS pricing. They offer both. They provide the customers and option to either buy or subscribe.
Surprisingly, the revenue share between one-time payments and monthly subscriptions for iA has been a tie—50/50.
Buy Once + Host on your own server
If we circle back on the definition of a lifetime deal — Once you purchase and redeem a lifetime deal, you have access to that tool for the lifetime of the product.
Apart from the quick capital injection, it might not be sustainable for the enterprise as one might still need to pay for the hosting. These marginal costs might creep up over time.
Jason Fried, the CEO of Basecamp has a new spin to the pricing story. Through Once, they plan to provide users the ability to host the software. They just have to pay one-time for the software, and the rest is up to them to host it the way they would like.
Pay per task
Zapier, a company valued at $5 billion, revolutionized its pricing structure by introducing a “pay-per-task” system, moving away from the traditional monthly subscription model.
Pay-per-task, as an emerging model, reflects a nuanced understanding of customer preferences and a commitment to meeting their specific needs. This shift is likely driven by growing dissatisfaction with monthly subscriptions. Take, for instance, our annual expenditure of approximately $40,000 on Figma. Each monthly bill is a reminder of the disconnect between our usage and the costs incurred.
Alternatives like pay-per-pixel, pay-per-project, or one-time purchases are increasingly becoming more appealing.
Software Couture Houses
Recently came across Andy’s !Boring — an independently owned software couture house.
Under the !Boring umbrella, Andy has launched a suite of apps — Weather, Calculator, and Timer, (Not Boring) Habits wildly amplifying a pretty mild-mannered category, tearing down the traditional approach in favor of eye-popping aesthetics, zingy haptics, spiffy 3D animations, and plenty of the delight and fun that nabbed the app its 2022 Apple Design Award.
They are designer-labelled, contrarian, and far from the default. As the title claims to ‘ditch the default, and to support interesting’ —
How does the pricing work? — You pay for the membership and get access to the entire range of apps that are developed by Andy. It’s more like a SaaS, but instead of paying for one app, you pay for the whole gamut of apps. It’s a bit different from an aggregator such as Appsumo as it’s not a collection of curated applications.
I foresee many such software couture houses.
What’s next?
Historically, we have always taken the stance of function over form, and to just GET THE JOB DONE. However, this very act has backfired in some cases. People don’t just seek utility, but also fun and delight.
I just wanted to conclude this incomplete essay with a quote by Verganti, a pioneer in design-driven innovation—People don’t buy products. People buy meanings.
Dear enterprises, we’re tired of your subscriptions. We seek newer meanings and want to rethink our relationship with software.
It’s nice to see various such relationships emerge, as shown from the earlier examples — ranging from renting, to owning, to renting partially, to owning a suite of apps, to even renting a suite of apps. Software is eating the world. And let’s make sure that it eats the world the right way.
Insights are not just a salad of facts
What is an insight? Really?
What is an insight?
An insight for Elon was: “The most entertaining outcome was the most likely’. His tweet suggests that he believes in taking risks and embracing the unknown, rather than playing it safe.
For Maya Angelou, the renowned poet and civil rights activist, it was: “People will forget what you said, but people will never forget how you made them feel”. A perspective on the impact of emotional connections. ^6ce4d2
Some of these insights challenge norms and encourage a re-evaluation on how we look at the world.
Getting insights however is not so easy.
We cannot just pluck insights from a tree and serve it on a platter.
As Chris Kocek states in his book, The Practical Pocket Guide to Account Planning, “Contrary to popular belief, there is not a mythical tree inside our offices from which we pluck insights on a daily basis.”
For individuals like Elon and Maya Angelou, it likely required a wealth of life experiences spanning years to distill such profound wisdom into concise statements.
Insights play a pivotal role in shaping the direction of a project, product, or even an entire company. Their significant return on investment is why companies prioritize investing in insights. While it’s impossible to replicate the depth of insights derived from decades of lived experiences, alternative approaches through design research methods can lead to valuable insights.
Let’s understand the shape of an insight by how the design research methodology ships insights. A typical design research cycle looks like this:
You’ve got a problem or a question that needs solving. It could be creating something new or making an existing thing better.
First, you gather clues. You talk to people who might know something about the problem or have experienced it themselves. You listen to their stories, ask them questions, and take notes.
Next, you look for patterns. You analyze all the information you’ve collected and start seeing common themes or trends.
It’s like connecting the dots in a big picture. This helps you uncover insights and understand what really matters to the people involved.
Eventually, this becomes a process to churn out insights on a consistent basis within an organisation. There is a navigation from data, information, knowledge, INSIGHT and finally, wisdom.
An insight is not just a statement. On the contrary, it is everything else but the statement. It’s the reasoning behind that statement. Insights are stories conveyed in a succinct way to help us with sensemaking.
Why do they help us with sensemaking? Why can’t all the data captured through all the interviews and literature studies be enough?
Picture this: 111111111111111….(million digits)
You’re brain finds it easy to store it (even if it’s around a million digits). You’ve been able to find the pattern here. A repetition of the number one. A million times.
But now, imagine this: 100010…(million digits)
You’re not able to make a head or tail of this information. You are not able to find patterns anywhere and are stuck.
Eventually you slice and dice the data, segment and start seeing some patterns emerging from what seemed like a random salad of 1s and 0s.
This is the process which design research adopts. Except that instead of 1s and 0s, you are trying to slice and dice transcriptions, anecdotes, statements, reports .
Insights help compress data in a beautiful way as you can clearly see the ‘why’ behind them. It ultimately has the shape of a story.
Your brain is a sprawling library of information. Stories, however, are the VIP section—easily accessible and constantly on your mind. And stories are wired into our very essence. We’re storytelling chimpanzees.
They captivate us, stick in our memory, and stand the test of time because they tap into the core of what it means to be human—our emotions, experiences, and the universal themes that connect us all.
Insights are arrows that cut through all the noise. They’re not just a salad of facts.
Minimum Lovable Product
And not Minimum Viable Product.
We might have to rethink on the definition of the ‘Minimum Viable Prototype’.
Especially since the bar for what’s viable keeps rising up, with the likes of Gumroad, etc being built in a weekend.
Notion, Figma, Airtable, Superhuman and Discord with their extremly high quality user experience has led to a highly devoted user base among tech Twitter. It would be foolish to think of the MVP of Notion as a bare bones note taking app. The high quality UX has been extremely critical to its success.
We had low-floor, low-ceiling setups for an MVP in the past. Now, the ballpark has shifted quite drastically. It’s a higher floor, and an even higher ceiling.
Today, there’s so much capital in the startup ecosystem, and so many tools that make it cheap and easy to ship a product, that baseline applications have become a commodity. Most users can intuitively feel the cheapness of the average product today, and their app fatigue is at an all-time high.
MVP stands for Minimum Viable Product, and I want to specifically emphasize the word “viable.” We’re continually experiencing quality inflation as app-building frameworks get better. As it gets easier to build basic applications, the floor for what is actually viable rises.
The problem today is that most founders’ idea of what constitutes a software product’s MVP is outdated.
One of my best examples of the ethos of a ‘Minimum Lovable Product’ is the development of mymind by Tobias:
We don’t want to stress about keeping up with other tools (many of them here today, gone tomorrow) and shipping new features to satisfy “users” who demand it. We don’t want to try to meet every need and create a monster of a product, dinging bells and tooting whistles until we spontaneously combust. We want to achieve the purest form of our tool and let it continue to be that. We want to be here 10 years from now. We want to create, if possible, the digital equivalent to the iconic chair, sunglasses or notebook. Something you proudly care for, polish, return to, count on year after year. Something you own for a long, long time.
The desperation for newness is a sickness of technology.
It’s a disease perpetuated by algorithms, desire for immediate satisfaction and the craving of dopamine unfulfilled by unhealthy lifestyles.
Refusing to succumb to that illness requires saying no. As creators and business owners, it requires forgoing the temporary rush of users riding one tool to the next. It requires coming back to our original mission, over and over again, every time we make a decision about our tool.
And we hope it leads to something meaningful. A tool built to last.
Minimum lovable product is also not to be engulfed in featuritis and leading to doing all about everything. It’s about a balance where you see the whole triad as a whole. Making something lovable is about shifting the mindset. It’s not about how it works, but the way it works. 1
Take an example of keyboard shortcuts, which causes a lot of love among early adopters. Another thing is doing a little bit extra pixie dust. For example, in the way Obsidian has made plug-in development more lovable.
It is that simple.
I can assume that there might be counters, attacks and pushpacks to this heavy statement. Bear with me on this. Before we address the house on fire, let me take you on a quick detour.
This was my first day of a new semester while doing my Master’s in design studies at the Delft University of Technology. My professor at that time started the semester with the Pressure Cooker Test.
What was it about? As a team, we had to compress six months of product building and development into one day. It was, literally, a pressure cooker!
We wrapped up the day having made a very quick-prototypyish demo, presenting it to the mentors who had facilitated this event.
A year after this happened, I started doing my Masters’s thesis, where I underwent the conventional product-building process. I did roughly two months of design research, including planning, landscaping, feasibility studies and all that jazz, before building the product.
Throughout this phase, my mind wandered back to the Pressure Cooker Test.
Was there a faster, quicker, more rapid way to do the same?
The only issue was that most of the insights were gained after the product was in the hands of the users. During my weekly check-ins with my design professor, I often asked him, “Why does design research take so much time? Even after months of user testing, it doesn’t seem as close to reality as expected..”.
This was when my professor mentioned the story of another fellow graduate who was working with a prosthetics company to design use cases for an improved hip replacement surgery. The student had extended her design research, not by one week or month, but by a whole year. At the end of the design research, she had become an expert on hips. After one year of investigation, she was able to grab onto that 1% deep insight which led her to formulate the product vision and further development.
Now, who has time for all this?
You might not be having time to do such extensive research investigations. Oftentimes, it’s a luxury. Especially in startup environments where a week or two can make or break a company, we might need contrarian and unconventional systems for product building.
The bigger problem with research can be done for one day, one month, or even a year. The depth might change, but it wouldn’t necessarily guarantee that the product is better. You might increase the chances of it succeeding and still failing.
Most of the products don’t survive a day out in the open.
This led me to hypothesize that the best product insights are gained by putting the product out in the open as fast as possible. Even if they are not perfect or the best working solution available now.
If a wrong decision can make or break a startup, putting the MVPs out as quickly as possible is better. It’s similar to how we shoot bullets with a shotgun and attempt multiple hits expecting one of them to hit the bull’s eye.
Now, you might ask, how is this even connected to the discussion we have been having between code and no-code?
With no code, you could build startups for breakfast.
The times have changed.
From Learn, Test and Launch, it has now come to — To Launch, Test and then Learn.
The first time I used a no-code app was to build a COVID Wiki app during the second wave of the pandemic in India. As we wanted to intervene as soon as possible, we completed the process in 1-2 days, from ideating, brainstorming, building and launching. When I pressed this app’s launch button, it felt eerie and weird. The app was nothing fancy but — How could this be built so fast?
I launch, test and learn. All the time. No code had rewired my brain.
It has changed the way I think about building products.
So, umm, what is no-code?
If you’re with me so far, but still confused as to what no-code means, let me give you a quick primer.
No code is nothing but code. Except that all the syntax and programming language jazz are stripped out. In no-code apps, you find everything to be more visual. All those WYSIWYG-style drag-and-drop interfaces replace lengthy lines of code.
The no-code landscape is picking up quite fast. Now, you have a no-code alternative for most of the code-based products you find in the market.
This approach is a part of my product philosophy now. This thinking has penetrated deeper into the work I do.
For Noora Health, I’ve been building various mini-apps using these tools to solve specific problems in our workflow. I’ve also got quite fast at building landing pages using a no-code website builder, Framer. Recently, for developing a landing page for a client, a lot of cross-functional alignment was needed to bring all the marketing/comms pieces together. Using Framer, we could quickly collaborate and make version changes rapidly before going live. In a conventional setup, there would have been a lot of back and forth, which this avoids.
And there are other tools too. Creating finance, budget and subscription trackers on Notion. Or complex automation on Integromat and Zapier. And it’s happening everywhere. All without code. Even in some startups.
Julia created HelloPrenup (a prenup management portal) after getting frustrated by hiring various overseas developers who didn’t consider the sustainability of the product they were building. She decided to do it all independently with her co-founder using Bubble, a no-code application platform. The startup ended up raising $150K for 30% on SharkTank. (After all, the customer doesn’t care if the product is built using code or no code. They just care if the job is done.)
Gartner predicted that 65 per cent of app development will happen on low-code platforms by 2024. It’s no surprise to see the rise in no-code developer profile jobs.
The beauty of no-code is apart from the fact that it helps us to think with a higher level of abstraction.
From 30 ft vantage point to 30,000 ft above sea level.
Writing code and its syntax makes you look at it from a 30 ft view which might not always be required. Even though the coding languages are still some form of abstraction (programmers use various pre-packaged libraries and ready-made components in the building process), it is still very difficult for product managers, marketers and founders to read and understand.
For example, almost 90% of the time, people’s problems in business are usually SOLVED problems.
And there is a high chance that these might be reduced in abstraction to a template and made easy to build using existing no-code tools.
No code is like driving a car in first gear. You have enough tools and services available to get your MVP launch ready. If you want anything more, you will run into problems.
You seek code if you want to drive your car in fourth gear with much more control and precision.
Instead, the developer’s time could be best utilised to solve unsolved problems that have NOT been abstracted yet. Or in other words,
Use code only if no-code fails!
Becoming a Product Manager has fundamentally rewired my brain. I think of everything as a product, really.
When I say, ‘everything’, I’m talking about the entire gamut — children’s toys, medical devices, teacher training facilities, pharmacy counters. All these can also be looked at as a product. No, I’m not just talking about the tech products which you see listed on ProductHunt.
What’s so interesting about calling anything a product?
Thinking of a project as a project, or as a product are two different things.
They CANNOT be used interchangeably.
If you’ve been running various projects and would like to incorporate product thinking into your projects, here are a couple of things you could get started with:
Treat products as living, breathing creatures.
For a project, there is a fixed timeline and a fixed end goal in mind. Once the goal is met and the timelines are met, the project is COMPLETE. They are time constrained efforts which are supposed to be defined upfront. Fixed scope. Fixed time. Fixed cost.
Products, on the other hand are evolving creatures. They evolve in accordance to the growing needs of the company as well as the users’ needs. By this nature, they have to be constantly learning and adapting.
Remaining static (project-based) in a dynamic world, comes with it’s share of dangers. Projects don’t welcome change. Whereas, change and evolution are natural in products.
Shreyas Doshi, a product expert talks about the various differences when it comes to project and product thinking approaches.
Become a philosopher-in-residence.
To accommodate change, The Product thinker has to take in inputs from customers on a frequent basis and tries to balance and define requirements based on the company’s needs. Feature requests come from all corners.
When there are various moving pieces in line, the product manager has to prioritise the features based on various factors such as (a) cost, (b) complexity, (c) risk, (d) customer impact, (e) projected sales impact, (f) documentation etc..
The product person within an organisation plays multiple hats. One of them being that of a philosopher-in-residence constantly asking these questions and helping drive action and alignment across the board. You are asked to be critical, but also creative. Customer facing, but also business facing. It’s a one big balancing game.
The main question which the product manager is trying to drive is not in managing the laundry list of feature requests. It’s about constantly asking WHY. What are the evidences?
Why is it important?
What are our goals?
What else could happen?
How will it differentiate?
Why? Why? Why?
Rewrite the feature requests as user stories.
Features become the means to end and not an end in themselves. **When you make it about the customer, nobody can disagree unless they have a very strong reason.
- Boost creativity by providing clarity on the problems being solved. When we focus on solving a problem rather than building a feature, it gives us much more room to maneuver.
The most popular template for structuring a user story is the following sentence:
As a _, I want _ so that I _
The three variables can be understood as follows:
User X— signifies the user persona that is requesting the functionality.
Functionality Y — signifies the behaviour/functionality the user needs.
Goal Z — Signifies the need the user wants to get fulfilled through the specific functionality.
- As a passenger, I want to know the estimated arrival time for a cab so that I have an idea of how long do I need to wait.
- As a passenger, I want to know the total fare so that I know how much the trip is going to cost me.
- As a passenger, I want to be able to call the driver so that I can coordinate with them if required.
When I first started doing design observations, there was ABSOLUTELY no structure. I just went ahead to observe the surroundings and talking to as many people as I can. Although I did get some insights from this process, I realised that there could be a better way.
There are three major steps you could follow. Step 1 — Noting down the key assumptions concerning the user. Listing them down beforehand tells you how right/wrong you were about the user.
Step 2 — List down the category buckets. For example, while designing for the public healthcare space, I noted down the category buckets as — people, infrastructure, technology etc. This could vary according to the context of your problem space.
By listing down the category buckets, you prime your mind to think more consciously about them.
When in doubt figuring out the category buckets, you could also follow the AEIOU Framework. In short, A = Activities E = Environments I = Interactions O = Objects U = Users
In my current work designing for the public healthcare space, A = Activities (Daily doctor rounds etc) E = Environment (Maternity wards etc) I = Interactions (Nurse checking vitals of patients) O = Objects (Posters, Placards) U = Users (Senior doctors, Paediatricians etc)
The AEIOU Framework can also be downloaded and printed in a fun and engaging way to be used — Source: Open Practise Library
Once the observations are done, it’s advisable to process all your scribbles, sticky notes and field notes in one place. Best time to do this is when your memory is fresh. Process and collect them together. This is where the cream of the cream lies — your UNIQUE INSIGHTS
You can also reflect on the assumptions you had earlier before you visited the setting. It might have been that you might have changed your mind on some of the key assumptions. Observation visits have a great ROI in terms of user insights.
To summarise —
- Note down key assumptions
- Use the AEIOU framework to make categories of your observations
- Process and bring together all your field notes on the very same day
- Reflect and revisit on your assumptions