Select Page
Our Beliefs Are What Limit Us

Our Beliefs Are What Limit Us


While technology continues to race forward our accepted societal beliefs, norms, and behaviors are based upon generations of antiquated assumptions, concepts, and methods devised centuries ago.

Solutions which stem from our current beliefs and unconscious assumptions will not solve our current problems. Solutions within existing paradigms are simply a continuation or an extension of the current model.

So how do we:

  • Draw out our unconscious beliefs and assumptions?
  • Evolve beyond our existing beliefs and assumptions that are limiting us?
  • Overcome the power of precedent?
  • Disrupt entrenched ways of thinking?
  • Find new motivations for the status quo?
  • Transcend our fear-of-change?

By drawing out our unconscious biases, beliefs, and replacing them with new baseline assumptions we can radically shift our solutions. With a new holistic baseline, a new set of modernized beliefs, we can begin investing in new models that make old models obsolete.

Beliefs that limit us include:

  • Scarcity is real and resources are finite
  • Land can and should be owned
  • Borders, boundaries, countries, governments, and armed conflict are inevitable and acceptable
  • Degradation of the planet and our environment are inevitable and acceptable
  • Poverty and hunger are inevitable and acceptable
  • Technology is the solution
  • How we live today is how we live tomorrow
  • Convenience and comfort are positives
  • Profit is motivational
  • Money and economies are required for commerce
  • Change is scary and difficult
  • There are many, many, many, others…
Verities of Disruptive Design

Verities of Disruptive Design


The PRSYM verities inform a belief system that help to drive new ways of thinking.

  1. A brighter future is possible.
  2. Our beliefs are what limit us.
  3. All of the resources and technology required to eliminate social, economic, and environmental ills already exist today.
  4. Technology is racing forward within belief systems that are thousands of years old.
  5. We have have a global climate crisis and future models work backwards from this.
  6. Solutions that originate within current beliefs and unconscious biases only extend existing paradigms and cannot truly solve current problems.
  7. We need new ways of thinking informed by new beliefs to evolve.
  8. The most fundamental belief to begin with… is that we are all connected.
Problems Before Solutions

Problems Before Solutions


Over the years that I’ve been designing things, there has always been endless discussion about delivering simple, easy-to-use, approachable, and consumable products.

Interestingly for all of the talk, it is very rare for companies to actually deliver on the promise of simplicity. Everyone always seems to start out with the best of intentions, with idealistic motives, and then in the end delivers an intimidating, complicated, confusing, bloated product; leveraging documentation in some form or another to help guide the customer through the labyrinth.

Truthfully, the picture isn’t as bleak as I’ve painted here. There are a few companies here and there that deliver simple products with a high degree of consistency (Apple, and Google come to mind.) And fortunately almost everyone (regardless of discipline, background, or hierarchy) seems to agree that delivering products that actual non-technical human beings can use is a good idea. There is very rarely any disagreement that simplicity as a goal is important, relevant, and critical to the success of a product within the marketplace.

So the question remains… why is this so hard to do? Why are there so few simple products in the world? Why is simplicity so elusive? Why is it so difficult to deliver a simple, easy-to-use, easy-to-understand product? Realizing the significance of simplicity coupled with its elusiveness and having found what I believe is the answer, I feel as though I’ve unearthed one of the ‘seven wonders of the world’ so please read on.

The answer is quite simple. ‘Define and agree on what simplicity means.’ Sure sounds easy, doesn’t it?

Simplicity as a principle is completely subjective. Everyone has a different idea of what ‘is simple’, and what ‘isn’t simple’. So in looking for a common definition I turned to the dictionary. Unfortunately the explanations found there couldn’t be more complex. I found over 29 different definitions for ‘simple’.

From there I started synthesizing the explanations into patterns, into groups. Almost all of the examples talk about what simple ‘is not’, what it ‘isn’t doing’, what it ‘isn’t being’, what it ‘isn’t’. So by definition ‘simplicity’ is the nature of not being, not doing, it is the nature of non-action; it is the simple act of saying no. This discovery was completely revolutionary for me for the following reason. Simplicity is about what you don’t create, rather than what you do create. Simplicity is about not doing. It’s about your eraser, not your pencil. It is by definition reductive thinking.

Here is my best attempt at a simple definition:

  • Simple (adjective)
  • Easy to understand and use.
  • Not elaborate, ornate, artificial, or complicated.
  • Occurring or considered alone; mere; bare.

So to recap, if your goal is to deliver something simple, you have to be very direct and clear about what simplicity means, how this principle will be used to make decisions, and most importantly what the agreement is/means. Simplicity is about completely agreeing on what you are doing, as well as what you are not doing, form the beginning without backsliding. In order to deliver on the promise of simplicity you fundamentally have to do less. This means that all of the people involved have to be ok with doing less. This can be quite unintuitive and contradictory to the nature of creative professionals who are in some form always tinkering on a subconscious level. Simplicity means discipline, agreement, and focused execution.

I’ve outlined some steps teams might employ to help deliver on the noble promise of simplicity:

  • Agree on a common definition for what ‘simplicity’ means.
  • Agree upon how decisions of what-to-do, or more importantly, what not-to-do will be made relative to the common definition.
  • Make the decisions up front.
  • Stick to the plan.
  • Do not backslide.
Importance of Feasibility

Importance of Feasibility


Avoid the iceberg.

Every design project carries with it implicit requirements. Requirements stem from all manner of sources. Hopefully the target customer, often the client, the technology, or the business. There can often be so many it can seem overwhelming. Where do you start? Who do you listen to? What is really important? To make things more complex, some requirements are soft and malleable. Usually these are the attitudes or opinions of people involved with projects. Other requirements are quite rigid and introduce difficult constraints that have to be worked around within a designed system. It is often these unseen, unspoken, undocumented rigid requirements that get missed early while making project estimates. Dates are set, commitments are made, work begins, then as you dig into the project you begin the discovery process.

Project requirements are the iceberg beneath the surface just waiting to sink your ship.

Once you hit one you know it. Designs often have to be iterated multiple times to accommodate and keep projects moving forward, but often at huge loss of schedule, and cost to the team. In fact it is hidden requirements like this that are the basis of agile vs. waterfall development. Waterfall pretends that you can dig in while planning a project and identify all of these icebergs document, and plan contingencies for them. Agile knows better, and assumes that you will have to do some work, some investigation to dig in and see what you’re up against. Either way you’re trying to understand what is hidden within the project sitting in front of you and identify efficient ways to workaround.

The Three Requirement Sources

There are three standard sources which inform design requirements; the customer, the technology, and the business. It is critical to identify these sources as early as possible within projects. By understanding the motivations behind investments from a customer, business, and technology perspective, designers are fully empowered to identify assumptions throughout the design process. This will help designers develop project principles, codify design goals, and to make appropriate decisions and compromises (yes all designers compromise) relative to the importance of the requirement source.

One of the first hard truths relative to working as a designer for a living is that; 90% of design is about understanding what you are designing. Then once you understand it, 10% actually designing it.

1. Customer Requirements

Hopefully you have a very clear immediate customer need in mind with your project. This is often a well understood opportunity addressing a known customer issue, gap, pain-point, or trigger, often supported quantitative data, or qualitative customer research. Sometimes the customer requirements stem from an ambiguous emerging customer need. These can be tricky, and are often a loosely-defined, or competitive opportunity influencing, or capable of influencing a customer (typically supported with quantitative projections and qualitative competitive data). Either way these should be your north star on the project. The customer needs or requirements should always be used as the first inflection point in decision making. Codifying project principles, and design goals should begin with your customer opportunity, and should be used to negotiate, technology and business requirements.

Customer Needs

  • System pain-point that needs improvement
  • Attitudinal or emotional bias (can be positive or negative) toward a solution
  • Functional value gap
  • Address a trigger

2. Technology RequirementS

Customarily these requirements are non-negotiable at the expense of significant cost to the organization. Savvy designers possess enough technical knowledge and experience to identify small workaround investments which have a large scale impact to the overall quality of the design.
To identify these sources early, designers must read all technical briefs and functional specifications associated with the project. Designers must also attend meetings, and ask clarifying questions. Appropriate proactive involvement directly in the project, will work in the favor of the designer.
In turning towards the technical stakeholders (developers, contractors, testers, program managers, project managers, etc…) designers are also building relationships with the people responsible for making designs real within the physical world.
Any engineer worth a damn will tell you, anything can be built, it’s just a matter of cost, or how much you are willing to pay to build it. In systems design this cost is typically the engineering and quality assurance resources assigned to the project, as well as the amount of time they have to build and stabilize it.
If your design concept isn’t technically feasible, with the resources you have, and the time you have, you’re simply wasting everyone’s time. Save yourself the heartache. Vet concepts early with technical leaders. Figure out what is possible, but don’t compromise on your customer goals unless you have no other choice. If you backslide too far, you likely aren’t delivering any incremental value.


  • A platform to build from (some existing technical foothold to build off-of)
  • Time (prototype, prove-concept, build, test, refine)
  • Resources (people)
  • Motivation (justification for investing)

3. Business Requirements

Evidently, businesses tend to stress strategic business goals, directives, or charters which emphasize a particular technology, investment, integration, or outcome. These directives can and often do, conflict directly with the market, customer needs, and the designer’s principles and goals. Nonetheless, it is the job of the designer to understand and accept the motivations of the client or organization and elucidate solutions that balance everyone’s needs.
It is common for designers early in their career to misinterpret business priorities or identify them too late in the project to be appropriately effective. Such requirements can be obfuscated in overly technical business speak, organizational politics, come from misinformed sources, or through multiple layers of hierarchy within larger organizations. Thus it is critical that designers possess appropriate courage and conviction to ask (sometime difficult) clarifying questions of the most executive management. This must be done within the requirement gathering phase of a project to be effective. As with most things in life, timing is everything. If these questions are asked too late, the opportunity has been lost, and the designer may be perceived as difficult to work with, and may potentially lose credibility with the client, or organization as business goals are missed.

If you don’t have a clear strategy for how your design will move the needle towards established business goals, again you’re simply wasting everyone’s time. There is a very delicate balance between intentionally stretching a team beyond it’s current implementation or current technological gate, and taking things so far beyond what’s feasible, that no one can buy-in to support the proposal.

Business Needs

  • Business justification for investing
  • Metrics to measure success
  • A clear deadline for delivery
  • To earn the respect and trust of people who actually have to manage and build your designs, feasibility is the first priority. Take it upon yourself as the designer to understand all of the technical constraints and affordances and make the right trade offs. This will minimize disruption and streamline the implementation of your design. Remember until it’s been translated to code, tested, stabilized, and proved – all you’ve produced is a drawing and unless you’re a fine artist that isn’t going to pay the bills. Ideas on paper aren’t fiscally valuable until they have been translated to code. Take it upon yourself to know something about the technology being used to implement your solution and then and only the. Push gently to evolve.

Pin It on Pinterest