Anthi Malteza

Gathering project requirements with clients

The most common way to start a new web development project is to receive a rough description, and a proposal request from your client. “Here is what I need, how much does it cost, how much time do you need to make it work?” And some times, things are simple enough indeed, the project looks familiar, the client is experienced and has done her research and assessment already. The point is that we know the project requirements we have received are better than a hard guess. Still, applying some minor changes along the way can be manageable with small predictable projects, and most of times with a little back and forth communication we can fill in the most gaps.

But some times things don’t go as well, because the client has perhaps defined things without considering relations to important business outcomes they expect or restrictions they have to face. Often they have an insufficient understanding of available design & tech options, advantages and disadvantages. Potential risks and even opportunities to innovate may be left outside the discussion and scope. Unfortunately, when dealing with large, complex, challenging client requests, the cost of adding features or changing the scope of the project once it’s underway can be massive.

Miscommunications and missed opportunities can show up when the project is half way through, causing disappointment and friction. A poor project outline damages the quality of the end solution, the service provided, the relationship with the client, even one’s professional reputation. Luckily, to prevent such outcomes we can work with the client together during the project discovery phase, and take the time to make sure all important project aspects are addressed and aligned.

The core idea is: before kicking off project development we collect Information to craft a shared perspective on what the project – or problem – is. To capture the vision, business needs, goals, priorities and motivations behind the product or platform or solution we are about to craft, as early and fully as possible. Let’s quickly review the fundamental components of a well rounded project outline.


Where I am going VS How do I get there.

What is the high level business goal I want to achieve in this moment with this project.
What exactly is the result I am after?
And what is my starting point?
And where do I stand among my competition?
And what is the result of that?


What are the realistic and directed steps I need to take in order to reach my business goals?
What are some existing and some possible internal and external obstacles?
What alternative paths or shortcuts can we consider?
What innovations can we suggest?
Can I use this project to get ahead from competion? How?

It is essential to bring awareness about competing websites, applications, or products but try not to frame your thinking to what competitors do, or don’t do. Imitating or avoiding other’s solutions is no safe way to solve unique problems with new ways and satisfy your own end users. Try to be deliberate about choices and compromises, don’t waste resources developing features no one needs.

User experience

How do user needs change on different devices?
How is the weight of each need distributed across devices?
What additional restrictions do they face and what device-specific opportunities are there?
How do we make the design more context aware?
How do we maintain UX consistency across devices and channels?

Content matters

What do we need to get started?
What will we need later, in which format do we need it.
How much time to get things ready?
What are some ways to automate sharing / repurposing?
How do we best support clients with their marketing efforts?

Visual identity

Is there a logo we can use?
What brand materials are available right now?
Do they cover the needs of the upcoming project?
What else needs to be done?
Who will do it? Do I need to hire someone? Will the client hire someone?
How does it affect the budget and the planning?


An early over-specification of technical matters, commonly mistaken as control over the outcome, may get in the way of framing the project properly. Now that we know a lot more about the context of the project and we’ve gone through some in-depth conversations with the client, we can safely jump to tech specifications, as part of the project outline. In order to be effective, a discovery needs to start as technology- or solution-agnostic.


Better estimates.
The discovery phase is, essentially, meant to define all of the business, design and technical requirements of your website, and ensure that they can be implemented within your timeframe and your budget.
Better service.
Understanding more about your clients’ business context will inevitably improve the customer experience you are capable of providing, in addition to the solution, allowing you to educate and consult them better.
Better outcome.
Less uncertainty, less errors, less wasted resources means that more focus and effort can be allocated on the quality of end result.

The first of 4 project phases

The so-called ‘Double Diamond‘ illustrates this high-level design process which can be used to bring designers and non-designers on the same page. The two diamonds represent the cognitive processes of exploring an issue in width and depth (diverging) before focusing attention and narrowing down options (converging).

Wordcamp Greece presentation link

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.