One of the most interesting aspects of the Design Thinking process, is not only the strengthening of the relationships that are created within the Product Design team (including not only Designers, but an entire ecosystem where Developers, Product Owners, Customer Support Groups, Marketing Professionals, Inventory Managers, to name but a few, collaborate), but also of course with the Users/Clients, who become part of that product journey, not only uncovering the solution itself, but how that product eventually morphs and continues to live past launch/release cycles. Another rewarding aspect of the process itself has always been the imminent realization that whatever is uncovered, tested and refined, has to eventually be built, within a series of constraints. These constraints can be of multiple natures, be it financial, platform wise, resources, timelines, among others, all of which is going to be the focus of attention for this article.

Constraints. Every Product Design initiative always has a series of constraints associated with it, something that should be clearly showcased when the process starts. Further constraints may be added to the scope of the initiative particularly as time goes on, but initially there’s already a listing of topics that all the participants in the Design Thinking process need to be aware of. Those general constraints are associated with a trifecta of factors: timelines, resources and finances. Expanding on these fundamentally operational constraints: timelines are part of the DNA of any project that is tackled. The need to release something to market, an MVP that is ultimately viable, which can be expanded upon, creates challenges from the Design process itself, in terms of running effective Research, Validation, Iterations, Testing exercises. All these phases provide different types of input into the solution that is being morphed, but once again Designers have to forcibly be strategic about how they devote time to each one of them (and how they bring different players to these phases, in order to gather the information they need to keep the process breezing along). Timelines are also deeply entwined with Resource allocation. Depending on the availability of team members, of different natures of course, allows for a lot of these processes and initiatives to be conducted more rapidly, and enable for iterative cycles for instance, to be produced in a speedier manner.

Resource availability is also tied with different layers of expertise, not just from a Design perspective, but also from other professionals who are involved in the process, and need to be available to participate in it. That includes for instance, professionals in Product Ownership, Development, Customer Support, Marketing, Sales, Inventory Management, the list goes on, but summarily, they all have a pivotal impact in the solutioning effort, and their contribution should always be accounted for. Matter of factly: without enough resources, the challenges to fulfill & keep the timelines established can become a herculean task in itself.

Deeply entwined with the previous two factors, there is of course the financial constraints that have implications across the board. It’s important to consider the budget that is being estimated for a particular initiative, whatever that may be, since that informs not only the timeline devoted to it, and the Team resources that can work on it, but also and by extension, a series of other factors evidently tied to the operational side of the process, namely tools for Research, Validation, Iteration, Testing, for capturing Analytics, not to mention of course, from a Usability testing perspective, and of course from a Development perspective. Everything has a quantifiable cost, which needs to be identified, since in itself also informs the viability of what is being built, and the available timeline to built it, and whom with. The practicality of these factors should always be considered by Designers when tackling any project they embark upon, particularly as they envision schedules and outputs of every phase of the process. These three constraints are of course the baseline of any project, but here are a few others which compliment them, which always need to be considered when devising a solution in a Design Thinking Process.

Technology Constraints — when initially identifying the problem, clearly understanding the tasks users want to perform and what their expected outcomes are, there’s an evident realization of how the users will experience something, by which this means, what devices will the users interact with in order to satiate their needs and get their tasks performed. Identifying these platforms, across multiple ecosystems and strategies is fundamental, since from early on, Development, Product Management, Customer Support partners, among others, can highlight and provide additional context for goals that need to be addressed, but also the limitations that may derive from certain platforms on which the solution will need to exist (or for for that matter, the lack of resources of professionals to work on said platforms). Further downstream, understanding the technological constraints is also fundamental in devising alternatives to interactive paradigms that are being applied, which for limitations of different natures can’t be applied, or alternatively how the creation of new paradigms may simply be ineffective within the the technological constraints that exist. The Pandemic has also brought forth other types of constraints, while also liberating others of course, but when it comes to technology itself, it has demonstrated that co-located collaboration was not an option, and tools such as Miro, Whimsical, Mural, had to take the lead in allowing teams to effectively discuss, collaborate and document ideas. All this to say that when it comes to Technology, and even though there’s an aspect of celerity in how it changes rapidly, it’s fundamental that all the partners in the process understand its constraints at all times. That indeed creates a series of guidelines by which everyone has to abide by, yet allowing for the creation of solutions that are in tune with that same ecosystem.

Contextual Constraints — it goes without saying that every solution that is devised, exists within a certain universe of requirements. These requirements are of different natures, but there’s quite a few that Designers and their partners can never forget: understanding the implications of Legal, Privacy, Ethical constraints is of the utmost importance. In the past I’ve worked in applications in the telecommunications arena, where a baseline feature we’ve all come to expect, such as the recording of a web conference, had to be thoroughly researched for its legal implications. Creating features, being innovative within a product are always to be nurtured and incentivized, however one must always keep in mind that whatever is brought forth is aligned with the context, industry, and the users themselves which will operate that product or feature. This of course ends up looping with the Research phase which was itemized earlier in the article and the importance of all the phases for the Design Thinking process to be effective. They all integrate with each other, and they all serve a purpose. These 5 constraints aren’t meant to be castrating, but mostly become beacons, assisting the teams in understanding where they operate and how the solution they are indeed producing will effectively resonate with their audiences.