Is the terms of reference really presented in the final version?
The product begins its life cycle with the formation of a collection of requirements for it. This code is most often the terms of reference (TOR). It provides detailed information about the technology of the future product, the target audience, as well as the functionality that should ensure the operation of this product. Often such a task is given in the form of a "raw", a sketch, which in the process of work will become overgrown with details. In order not to get into a situation where the part of the task related to the design and functional requirements did not fall under significant changes, it is necessary to carefully study these aspects, to talk them over with the customer as much as possible.
To draw the UI, do we use the company's corporate identity (as well as the company's previous UI developments, if any) or do we create a new one for a specific product?
Often, a new product is not created from scratch, but within the framework of another product or a block of company services. Based on this, we already have a set of stylistic and color rules and requirements for the design of UI components. In this case, you just need to confirm that the new product will be created based on these rules. If a service is created from scratch, it is necessary to make a sketch of the so-called mood board in order to agree on the style and color scheme with the customer.
Are there similar products on the market?
There are times when a customer comes up with an idea for a product that already has analogues on the market. To expedite market research (which is a must when developing a new product), it is important to ask the client for examples of these products. You can ask the customer what is good in these products, what is bad, inconvenient, what to focus on, how the new product will surpass the services given in the example.
What is the range of devices to use the product?
Sometimes we are faced with a situation where a product is created only for specific platforms for specific and narrowly focused purposes. In this case, the UX / UI specialist does not need to think over the options for how certain components will behave on different platforms (smartphones, tablets, desktops). It will also save time creating unneeded UI components for these platforms. It is important to discuss this issue before starting work, even if this has already been mentioned in the terms of reference.
What will be the level of prototyping?
Another important point that will save a lot of time at the initial stages and eliminate potential serious fixes to the product prototype is the choice of the type of prototype for demonstration. There are several typical flavors for prototype styles:
- A prototype of primitives (rectangles, circles, squares, etc.). No detailed elaboration is required here, and all UI components (text, buttons, etc.) are shown as primitives.
- Detailed prototype. This is a complicated version of the prototype, here we are already using the monochrome design of the project, the buttons look like full-fledged buttons, and the text and titles are close to real ones.
- Painted prototype. This is already a full-fledged product prototype based on existing UI components.
It is worth knowing in advance how best to present a product prototype to the customer at the initial stage, since not all customers are able to see the complete picture of the product based on primitives.
It is clear that this is an incomplete list, and we have forgotten something. What would you add to this checklist?