Avoid The Iceberg
Every design project carries with it implicit requirements. Requirements stem from all manner of sources. 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 even more ambiguous. 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.
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 making to understand what you are designing. Then once you understand the space, 10% is actually designing it —just putting the pieces into place.
I. 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.
– System pain-point that needs improvement
– Attitudinal bias (can be positive or negative) toward a solution
– Functional value gap
– Address a trigger
II. 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 (an existing foothold)
– Time (prototype, prove-concept, build, test, refine)
– Resources (people)
– Motivation (justification for investing)
III. 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 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.