What a designer needs to understand about your business before designing for it

A designer needs to understand four things about your business: what you sell, who your customers are, how your company operates and what your team can build and run. Users and goals cover the first two. Operations and team are where a design that is right for the user can still be wrong for the business, so check a designer's grasp of those two before you spend time on their proposals.

The four pillars come from Parasharan Chari, founder of Medkart Pharmacy, an omnichannel pharmacy chain, speaking in Mastering Design Decisions, an episode I hosted, published in August 2023. When the conversation turned to when a designer earns or loses trust, he listed four things he expects every designer to understand: the product or service, the customer, "our operations as a company" and the team, "so that he gives me a feasible set of solutions". Without all four, he said, "there is a lack of trust". Roles and figures below are as the guests stated them at the time of recording.

The four pillars, and what each means in a software business

Medkart is a pharmacy retailer with stores and a warehouse, not a software company. The middle and right-hand columns are our translation of the four pillars to a SaaS company, not the guest's words.

A brief that covers users and goals reaches the first two pillars. The next section is about why the last two decide whether a design can be used at all.

Why operations and team decide whether a design is feasible

The examples of design that Parasharan Chari and Dhimant Trivedi gave in the episode came from knowing the operation, not from looking at a screen.

• The search that matters because of a cost. Medicine strips are so cheap that barcoding each one makes no financial sense, Parasharan Chari explained, so staff at the counter type medicines in. Making that search more intuitive is, in his words, the design aspect: a priority that comes from the economics of a strip, not from the screen.
• The counter screen. The health advisor has a single screen. Prompting them to offer products the customer did not come in for is, in his words, also design.
• The warehouse. A typical medicine has a 38-second pick time; if it could be made 37, "I'm talking about those 10,000 strips giving me 10,000 more seconds in a day".
• The design with no designer. Dhimant Trivedi, Head of Engineering at Contrado, a personalised web-to-print business, described tracking when a print roll leaves the printer without asking the operator to log it. The software adds a small barcode to the end of each print file, and a scanner fixed next to the printer reads it as the roll comes out. A brief that described only the operator's screen would have been unlikely to lead there.

Service design research has a name for the part of the business those examples come from. G. Lynn Shostack, then a banking executive, described the service blueprint in Designing Services That Deliver (Harvard Business Review, January 1984). In its later form, set out by Mary Jo Bitner, Amy Ostrom and Felicia Morgan in Service Blueprinting: A Practical Technique for Service Innovation (California Management Review, 2008), a blueprint lays customer actions across the top, then the actions of staff the customer sees, then the staff actions behind the line of visibility, then the support processes carried out by people inside the company who are not in contact with the customer. Everything below the line of visibility is invisible to the customer. For an internet service with no frontline staff, the authors suggest replacing the visible-staff row with a row for the technology the customer uses.

Our inference from that: in a software product, the interface is one row of the blueprint. A designer who sees only the interface is designing one row and guessing at the rest, and the rows they cannot see are the operations pillar.

The team pillar has an older source. In How Do Committees Invent? (Datamation, April 1968), Melvin Conway argued that organisations which design systems are "constrained to produce designs which are copies of the communication structures of these organizations". We read that as a practical warning rather than a law of nature: a proposal that cuts across the way your teams are split is likely to meet those seams in build, in support and in every later change. A designer who knows how your team is organised can tell you where that cost will land before you commit to it. Parasharan Chari put the same point in a founder's terms: he wants a designer who knows "my team's capability", so that the solution is "practical and feasible".

Public-sector design guidance makes the same split. The UK government's guide to the discovery phase asks teams to learn about users and what they are trying to achieve, and, alongside that, about "any constraints you'd face making changes to how the service is run", for example technology or legislation.

How to tell whether a designer has understood your business

You do not need a test project. You need the designer to explain your business back to you in their own words, early in the work, and to listen for whether the explanation would change what they propose.

The method is borrowed from healthcare. The US Agency for Healthcare Research and Quality describes the teach-back method as "a way of checking understanding by asking patients to state in their own words what they need to know or do", and adds that it "is not a test of patients' memory". The same holds here: if the designer cannot explain an operational constraint back, check your explanation before you judge the designer.

Ask them to tell you back:

1. One operational constraint, and what it rules out. The equivalent of "strips are too cheap to barcode, so the search has to be fast for someone typing". If they can name the constraint but not what it rules out, they have heard it without using it.
2. Why the obvious solution would not work here. If your team has already rejected an obvious fix for a business reason, a designer who has understood the business can say what that reason is.
3. What their proposal changes behind the screen. Who in support, implementation, finance or operations does something different if it ships, and whether that is more work or less.
4. Who would build, run and support it. Which of your engineers, with which skills, and what it asks of them after launch.
5. Which customer it serves, and which customer it costs. In B2B the buyer, the administrator and the daily user need not want the same thing.

Signs that the understanding is there: the designer names constraints before you do; the options they bring differ in what they cost your operation, not only in how they look; and they ask to see the support queue, the onboarding process or the people doing the manual work. One guest named the opposite sign: work that mimics the competition too closely, "more of a copy and not something original".

How long should this take? A guest in the episode answered that it is "not a matter of time" but of interactions and the work carried out, and that some designers win trust on the second day. That matches the test above: the explanation back can come in the first working conversations, whether the designer is a new hire or an outside team. If you are still hiring, our guide on how to hire a product designer for your SaaS product covers interviews and onboarding; this check is for after they start.

Your half of the bargain: define the need and open the doors

In his closing advice to designers and to businesses looking for one, Parasharan Chari kept both halves together. The designer should know the four pillars; the business should "please define your needs better, because a lot of times loosely crafted requirements have a lot of standoffs".

One way to define the need well is to turn a requested solution back into a problem. The UK government's discovery guidance makes the point with an example: a team told to build an interactive map of contact centres is really being asked how to make it easier for people to find their nearest centre when they need a face-to-face appointment. A designer cannot test feasibility against a solution they were handed; they can test it against a problem.

The second half is access. A brief carries what you already know you know. The operations and team pillars live in people and places that a written brief does not reach on its own, so give the designer:

• time with the people who do the work behind the screen: support, onboarding, implementation, and whoever handles the exceptions by hand;
• the evidence that work leaves behind, such as support tickets, workaround spreadsheets and internal checklists (our article on enterprise UX for complex workflow software explains why workarounds are evidence);
• early conversations with the engineers who will build and run the result, before a direction is chosen rather than after;
• someone who understands both sides. On stakeholder resistance, one guest's view was that a stakeholder resisting a design may not have understood its business impact, just as the designer may not have understood the business impact of the stakeholder's concern, so someone has to act as the bridge.

What goes into the written brief itself is covered in our article on outsourcing UX design without losing product knowledge, including a decision log. The point here is narrower: a brief is not a substitute for access to the operation and the team.

How we work on this

At Tcules, we treat the operations and team pillars as research questions, not background reading. In our UX Research work, we begin with the decision the team faces, the current belief, the evidence already available, and whose work and consequences are missing from it. In operational products we may examine artefacts, support records, workarounds, handoffs, policies, product data and the environment in which the work occurs, because evidence can come from the work around the screen.

Before production, we agree decision owners on both sides, the evidence available and missing, and the access and confidentiality requirements, as set out in how we work. That agreement is where the team pillar becomes explicit: who on your side holds business, domain and policy authority, and what we are responsible for.