When to Partake in a UX Project?

Every single product or service can benefit of employing a user experience (UX) designer. Unfortunately there are always way less good designers than projects and therefore they have to be selective.

Both the designer and the project benefit if the designer feels happy. In a selection process every designer has his or her own ethical principles to start with. When a project passes the moral test, please, consider:

  • What he/she can bring to the project?
    Knowledge? Skills? Positive attitude?
  • What he/she expects to get back?
    Moral satisfaction of making a good product?
    Or making a world a better place?
    Or creating a perfect icon? Or expressing the inner self?
  • What expertise is already presented in the project team?
    Who is in charge of the product/company development strategy?
    Who defines product/service functionality and visual style?
    Who decides what (brand) message the product communicate?
  • What can the designer add?
    On what level the designer have to be involved? Strategic?
    Or the help is needed in a tactical realization of the defined goal?
    Or the product needs someone who will prettify the existing solution without asking questions?

As you can see there is a world of possibilities on a different levels. Some designers aim for perfection on one of them, some on another. If both the designer and the employer are on the same page about the role and the level of involvement of the designer in the project and satisfied with answers to the questions above, you should proceed.

Here you will find some information of what can you ask and expect from the designer and how to communicate a UX projects needs and results effectively. Good luck!

The Process

Most designers hate to even think about the process. It seems that structure kills the fun and leaves no space for creativity.

But on the other hand the process is exactly what makes the difference between hobby and profession.

When a customer comes to you he wants to see a professional who will find and solve project problems and who he can trust. The one who blows worries away. How? By proposing a good strategy and by acting accordingly with the strategy proposed.


This is a delicate moment. When a customer or his representative approaches you, he  already has something. This can be a raw idea, a business plan or an existing product with quite some history. Most probably he loves what he/she already has.

Your is goal to find out:

  • What you customer already has?
  • What is a problem to be solved?
  • Who (will) use the product?
  • What is a current status?
  • What is in the current implementation your customer is satisfied with?
  • What is in the current implementation the customer wants you to improve?

You can read more on a topic of stakeholders interview in a dedicated article on boxes and arrows.


Good planning is actually how you can ensure you will have enough time to do a good job and reserve some space for creativity.

Before going deep into detailed planning, first of all define:

  • the project goal,
  • the project scope,
  • success criteria.

While planning, consider how much time you’ll need for:

Go in small steps. Iterate.

It is important:

  • plan to perform several design iterations during the process in order to refine your design,
  • plan to reuse the results from the previous steps and iterations in the following steps and document key decisions.

If different steps are executed by different teams ensure sharing of the information.

In reality things rarely go according to plan but since you have it, you can adjust estimations, foresee consequences and proceed. Do not forget to communicate the plan adjustments and consequences to the project team and stakeholders.

Do not forget to communicate.

The Goal

A good project goal helps you to stay focused, choose a right design alternative, verify implementation and convince stakeholders on the choice of alternative.

A good goal is a SMART:  Specific, Measurable, Actionable, Relevant and Trackable.

A specific UX goal focuses on:

  • a human activity which the designed system supports,
  • people, or users who perform this activity,
  • a level of support which the system must provide,
  • a form of solution.

A specific UX goal  can be written as a single sentence “elevator-speech” form
(credits to Suleman Shahid from Tilburg University (the Netherlands)

design a <form of solution> that helps <people>
to perform a <human activity> with a provided <level of support>

“Create a web-portal that helps solo UX designers, startupers and project managers to define relevant steps and a scope of UX design in their project that is easy to apply in everyday work”.

A measurable UX goal defines UX metrics that are used as benchmark and for future design evaluation.

Those metrics could be taken from the problem statement above:

  • human activity gives you a hint about this activity success criteria,
  • level of support defines measures.

An actionable UX goal gives you a hint where to start:

  • a form of solution + human activity = benchmark area
  • form of solution = work outline
  • UX metrics = evaluation criteria

A relevant UX goal keeps you in focus. The relevance of product secondary features should be questioned trough the project. It could happen that the results of evaluations and chosen metrics show a good progress, but users and your designers fillings tell you the opposite. It is a moment to stop and revise.

A trackable UX goal allows you to see the progress though iterations and suggests the right direction at a specific stage.


UX design could be a complex set of activities in several dimensions:

In different projects you can work on one or several of those dimensions simultaneously. And while performing those activities you have to consider how the created design influences users’ emotions, feeling, cognition… the product aims to invoke.


When you start the project, you have to talk to project members in order to get essential information to create a good design.

If you have to give results of your work to someone to proceed, make sure you brief properly: not only share screens and reports but explaining the reasoning behind your design solutions.

Do your best to stay informed on implementation progress and be present when developers decide what to scarify in order to deliver the product on time.

Also just be a nice person and a good team player. Smile, feed developers with candy. It makes communication easier.