Designing Business Features Into WhatsApp for SMBs
This project started with a macro trend and a broad design question, not a product brief. Over one semester, I scoped that question into a specific, testable problem, ran three rounds of iterative research, synthesized findings into a prioritized problem set, built wireframe concepts, and tested them with users.
Methodology
I ran three iterative rounds of semi-structured interviews, each designed based on what the previous round revealed. Participants were small business owners across caterers, tutors, photographers, fashion designers, salons, and boutiques in India.
Round 1 (n=4) focused on understanding how and why SMBs were using WhatsApp as their primary business communication tool. It surfaced an immediate methodological challenge: the contentment problem. Users had adapted to their workarounds and largely didn't describe them as friction. They couldn't easily articulate what was missing. That forced a more indirect approach in subsequent rounds.
Round 2 (n=4) added experience-based questions (describe a time a customer was unsatisfied and how you handled it) and design speculation questions (if you had a magic power related to your business, what would it be?) to surface latent needs that users couldn't describe directly.
Round 3 (n=6) walked participants through their full customer journey, from first contact to delivery, to build detailed journey maps. Affinity mapping across all three rounds organized the complete body of findings. A prioritization matrix, plotted on generalizability and sketchability, narrowed a long list of potential design directions to three.
Refining the prompt
The starting point wasn't a product problem. It was a macro trend and a deliberately broad design question: what can social media apps do to help SMBs in ways that aren't advertising? Desk research pointed to a specific opportunity — direct messaging adoption among SMBs had accelerated sharply during the pandemic, and WhatsApp in particular had become a primary business communication tool in markets like India.
Three signals helped us narrow the scope. WhatsApp use among Indian SMBs had grown roughly 90% in the years before the study. India was the fastest-growing instant messaging market globally. And we had direct access to this user population. That combination — strong trend signal, growing market, accessible participants — made India the right place to focus. From there, we translated the broad prompt into a set of research questions to guide the first round of fieldwork.
What we learned in early fieldwork pushed the problem statement into sharper focus. The biggest gaps weren't in communication or reach — SMBs had figured out how to get customers. The friction was in everything that happened after: keeping track of orders, sharing consistent product information, and rebuilding catalogs from scratch for every new customer.
Research questions
- How is WhatsApp being used by SMBs in our target population?
- Are SMBs experiencing distinct pain points that could be alleviated?
- Are there aspects of their business that could be streamlined through WhatsApp?
Findings
WhatsApp worked for these SMBs because it placed almost no technological demands on them or their customers. Everyone was already there, adoption required no training, and the informal nature of the platform fit the informal nature of most of these businesses. That same strength was also the constraint: running a business through a personal messaging app meant building workarounds for everything the platform was not designed to do.
Across six business types, I mapped every pain point raised in interviews against the industry it came from. This let me see which problems were concentrated in specific niches and which ones cut across almost every segment. Catalog creation, order management, and scattered business information showed up everywhere — food catering, photography, boutiques, salons. That cross-industry signal was the first filter for deciding which problems to design for.
The second filter was a prioritization matrix. I plotted each problem on two axes: generalizability across business types and sketchability — how readily it could be translated into a wireframe concept that users could react to. The three problems that scored highest on both became the focus of the design phase.
Design concepts
Each problem had a corresponding wireframe concept. The goal wasn't to produce fully realized product specs — it was to build something concrete enough for users to react to. I designed three concepts: Contact Annotation for labeling and storing business-relevant customer details, a Queue for separating incoming orders from personal messages, and a Catalog Composer for building and reusing menus and product lists without starting from scratch each time.
Concept testing
I tested all three concepts with users from earlier rounds of the study. The bar I was measuring against wasn't just whether the designs solved the right problem — it was whether they felt within reach. These were users who had actively resisted more complex business tools. If the concepts required a learning curve, they would fail in the same way dedicated software had already failed this population.
What the concepts addressed
Concept testing validated two of the three concepts directly. Contact Annotation and Queue both resonated with users and were within their technical comfort zone, which was a meaningful bar given that perceived complexity was the primary reason these SMBs had avoided dedicated business tools in the first place.
The third concept surfaced something more interesting. The navigation pattern we designed for organizing and finding menus was rejected, but the feedback reframed the problem: organizing and finding menus was difficult and time-consuming in ways that went beyond what our wireframe addressed. It wasn't a failed concept so much as a signal that the problem needed more scoping before a design solution.
Concept testing also surfaced a bonus problem we hadn't set out to solve: transitioning from personal to business conversations within WhatsApp felt awkward to users. That thread wasn't in scope for this project, but it pointed to a real gap worth investigating in a follow-on study.
Limitations
The contentment problem was the hardest challenge of the project. Users had adapted to their workarounds and didn't initially describe them as friction. Surfacing latent needs required moving away from direct questions about pain points toward experience-based and speculative prompts, which took two full rounds of iteration to calibrate.
The remote nature of the project constrained method choice. Being unable to observe users in their actual business contexts meant relying entirely on self-report, which is especially limiting when studying workflows that happen in real time.
A longer research phase would have allowed for more iteration between concept testing and design refinement. Three rounds of interviews across one semester was enough to identify and validate the problems, and not enough time to fully close the design loop.