Kuidas anda prototüübile tagasisidet?

Introduction

A prototype is an early sample, model, or release of a product built to test a concept or a process. Prototyping is also an important phase in the process of creating websites, applications, and information systems, whichallows for feedback to be provided about the new system in the very earlystages of the project.

One of the bottlenecks in this process, as we have seen, is the phase when the prototype needs feedback.

How to provide effective feedback on a prototype, especially when there are many stakeholders whose opinions and recommendations must be taken into account?

How to encourage all the different parties to talk whilst also keeping the discussion on track?

We know from our experience that it is far from easy. And so, we wrote this book to help you analyse your prototype independently so that you could provide relevant feedback on it which helps move the project forward.

We believe it will help enhance the collaboration between designers, user experience experts, and the client. All of the chapters in this guide can be used to provide feedback on both the latest as well as the first versions of a prototype.

We hope that our experience and tips prove useful to you.

Trinidad Wiseman’s team

How to use this guide?

At the end of each chapter, you will find control questions. These blocks of questions serve as practical tools that help the whole team guide the project in the desired direction and they help the project receive the feedback it requires.

The designer’s point of view

In this section, we share our experiences on how to avoid common bottlenecks in the process and how to facilitate co-operation. We also provide tips on which actions may be skipped during the creation of a new system and which ones may not.

What is a prototype?

A prototype is a draft version of the system’s user interface, which is used to form a first impression, gather feedback, inspire discussions, and test actions and steps.

Prototyping is an efficient way of quickly identifying potential errors, for testing functionality and usability, and for demonstrating design alternatives in the early stages of a project before it goes into development.

The designer’s point of view

A prototype usually doesn’t have colours, the correct fonts, or final images — those are added later, during the visual design stage. Creating a designed prototype takes more time and more work and as such, it’s not the optimal route to take in the early stages of a project.

The evolution of the prototype

Prototypes are used throughout the entire design process. They can be divided into two categories according to their level of detail: low-fidelity (lo-fi) and high-fidelity (hi-fi) prototypes.

Lo-fi prototypes are used more for sketching out ideas and quickly thinking them through with the advantage of being fast to make, low-cost and simple. They can be changed very easily and quickly. For example, paper prototyping is often used for lo-fi prototypes.

Hi-fi prototypes are digitised prototypes that resemble the finished product a bit more (although they still lack the final visual design). Hi-fi prototypes are beneficial for communicating with the project’s key persons (as they help to collect feedback) and in performing usability tests on end users. Although the creation of such a prototype takes more time, this stage is still very important as it helps to detect potential functionality and usability issues before the development process begins.

Conclusion

The form and fidelity of a prototype changes in time, so we recommend starting with a lo-fi prototype and finishing with a hi-fi prototype.

Why is a prototype useful?

A prototype helps to learn a lot quite quickly in the early stages of a project.

Creating a software user interface takes a considerable amount of time. A prototype provides the opportunity to determine the most important aspects of it very early on through discussions, to communicate ideas and to point out any deficiencies—it is substantially more cost-effective.

It ensures the satisfaction of the main parties and the users

Key persons, users, and other parties in the project will be involved in the prototyping process already during the project’s early stages. As a result, the potential solution will be discussed very thoroughly so that the needs of different stakeholders can be met better.

It reduces risks

Many software projects are unable to meet delivery deadlines and budget limits due to incorrect volume assessments and assumptions made on the basis of insufficient information. A prototype helps to evaluate the volumes of development tasks much more accurately.

Conclusion

A prototype helps save time and money and it guarantees that all parties involved are on the same page regarding the system to be created.

The importance of feedback and its role in the design process

Prototyping is also important for improving the usability of a system. Usability has a different value for different users depending on their goals. In fact, a prototype will help to gain a better understanding of different user goals and preferences much more quickly.

During the prototyping phase, it is important to gather feedback so that the various stakeholders involved in the project, e.g. its key persons, could make some necessary decisions during the early design phase.

Conclusion

Timely gathering of feedback helps to gain a better understanding of the goals and values of different users and to make business decisions on whether the level of usability is sufficient for the project’s purposes.

When and in what format should feedback be collected?

Today, it is considered a best practice to ask for feedback as early as possible, usually based on unfinished work results – this helps to avoid squandering resources on putting the perfect finishing touches on unsuitable solutions.

We recommend gathering feedback in the form of a relaxed but focused discussion.

Each meeting should have a specific goal – for example, it could focus on a discussion of the structure of the news section, the information layout on the homepage or the operational logic of the search function etc.

It is much easier for a designer to present their ideas and to make any quick adjustments where needed with the help of a prototype and spoken explanations. Participants can get answers to their questions, communicate their ideas and needs, and finally confirm that the current vision of the solution meets their expectations.

The designer’s point of view

No component is set in stone – during this time, everything can still be changed, features can still be added, even several versions of the solution can be prepared. Don’t be afraid to share your ideas and to ask questions. This is exactly the right time to do so as we use prototypes to find the best solution within the framework of the specified conditions.

How to structure feedback?

We suggest dividing the information presented and collected during the feedback meetings into four categories so that it is clearly understood by all parties. This helps to avoids misinterpretation and enables the designer to better understand subsequent activities to be taken based on the feedback.

  • Likes: the parts that I like the most

  • Questions: the parts that I do not understand

  • Critique: the parts that could be improved

  • Ideas: new ideas to consider

Conclusion

A prototype should be reviewed in the early stages of the project through a discussion and the feedback collected should be divided into 4 categories: likes, questions, critique, and ideas.

The four categories of feedback

What should you focus on when providing feedback?

A prototype should be analysed in parts, answering various questions during the process. Depending on the prototype’s fidelity, some questions may be unsuitable or have a lower priority in certain stages or for specific categories.

On the other hand, it is important that all of these questions do get asked and answered. A structured, subject-based approach is very helpful here.

We recommend analysing a prototype according to the following four categories:

  • Business: how does the solution help to achieve the goals of the business, organisation, or system?

  • User: how does the user act within the system?

  • Technology: how complicated is the suggested solution technologically?

  • Execution: do the project’s team and other prototype target groups understand the solution?

If another company or website does something successfully, it does not mean that their solution would also work as well within a different context or at all. Large companies experiment a lot and many of their solutions are not viable in the long-term even for them.

A prototype should include an essential amount of accurate information that the system will eventually feature. It is not worth including all of the content and functionality in the prototype during this stage of the project. For example, dates are usually not updated, not all of the options are available and certain keywords for the search function might not work in the prototype. However, if displaying some piece of information correctly is critical in assessing whether the solution works for the user, it must be included.

The business perspective

The very first thing to do is to determine whether all parties involved understand the business goals of the project – what kind of changes are expected?

In the case of design projects, the main goals are usually things such as directing user behaviour, simplifying and speeding up activities, creating new opportunities or simply creating a more pleasant look.

  1. Does the suggested prototype of the solution meet the project goals?

    Example

    The goal of our project is to speed up the process of issuing invoices. Does this type of system accelerate the issuing of invoices?

  2. Does the prototype of the solution make it easier or more difficult for users to behave in the correct manner?

    Example

    Our users are sales managers who are expected to send an invoice to the customer’s e-mail right after the sale of a product. Is this the easiest way of issuing an invoice? Does the system’s work process facilitate performing the task immediately or does it cause users to postpone it? Does the user have to remember that they still need to do something?

  3. Can we offer this service at a sufficient quality level? How does our organisation need to change?

    Example

    If we offer our service via an information system as well as over the counter, is the user able to get all the information they need independently, or do we have to increase the number of our telephone customer service specialists? With that in mind, can we somehow improve the solution?

  4. Do the sequence of activities and the feel of the functionality also communicate the priorities of the brand?

    Example

    Our brand’s priority is our promise of being able to offer a specific service to our customers quickly. Does the prototyped solution demand little effort from the customer and enable them to use the service as quickly as possible? Have the wait times been replaced with rapid replies? Have we applied the best automation and data reuse practices so that customers and customer service specialists don’t have to enter data manually? Do we force users to read long and complicated texts instead of using a “click-click and done” approach?

User’s perspective: the tasks

A user is the person who will eventually utilize the developed solution. They may be a client as well as a co-worker.

To assess the prototype, we need to ask control questions about the user, their task, language use, and the issues they may encounter.

The designer’s point of view

If the questions are too complicated to answer, it may be the result of insufficient user surveys or interviews. In this stage of the project, usability testing enables to identify usability issues with the help of the actual users.

  1. Who is the user of this solution and what task or tasks do they perform on the site / in the system? Does the prototype conform to the user’s purpose?

  2. Is it clear at the start of the process what kind of service we are dealing with and how it should help the user to achieve their objectives in a better and faster manner?

  3. Is this solution the fastest and simplest way (that requires the fewest operations) of fulfilling the task? What could be done to speed up and simplify the performance of the user’s task?

  4. Does the system apply a personal approach for the user, as if it knows their preferences and earlier choices, which allows the user to perform subsequent activities easier and faster?

  5. What happens if the user terminates the process — are they notified of that? Are they directed to a location within the solution where they can start with another activity? Where do they get feedback on this process in the future?

  6. How often will the user use this solution in a day, month, year? Is quick or thoroughly explained use important to them? Does the prototype of the solution conform to the user’s preferences?

  7. Where do the users utilize the solution and what equipment do they use for that (nowadays, the systems are not used in an office behind a desk in many cases)? Does the prototype of the solution conform to the users’ preferences?

Is the use of language and the length of the texts justified?

If the user interface includes lots of components that aren’t necessary, it starts to look messy and it becomes easy to lose focus. Consider what could be removed and whether the overall layout on the screen could be divided into smaller parts/subsections. The important thing is not to reduce the efficiency of the layout that is used many times during the day.

  1. Does the user call the activities they perform and the fields in the prototype using the same terminology used in the prototype?

  2. Does the solution include all the data that needs to be asked for or shown?

  3. Is the text accurate and true to life? If not, is it at least being written?

  4. Have abbreviations, officialese, foreign words, and long text-based instructions been avoided? Has unnecessary text been removed so as not to hinder comprehension?

  5. Is the information asked from the user justified, i.e. it is necessary for performing tasks/using the service?

If the user gets stuck, how can they get help?

  1. Does the user have a clear and secure starting point (e.g. the homepage) to return to and start again if any issues arise?

  2. Is it easy for the user to find where they can get help?

  3. Is the customer support number easy to find?

  4. Are error messages sufficiently informative for the user to understand what they did wrong and how they can correct their mistake?

  5. Can the likelihood of error messages appearing be reduced by redesigning the form?

What is the organisation’s technological readiness?

To create a good system, good ideas are needed as well as the technical capability and resources to execute those ideas. It is time to check how big of a jump your company is willing to make on the innovation scale and what it will cost you.

From this perspective as well, sharing a prototype and conducting a discussion around it is the best way of evaluating whether it is technologically feasible to execute the project.

Example

If you want to show a product’s price on your website to customers, then that price must be come from somewhere. If we do not wish to enter it manually, then it has to be imported from another information system. In that case, maybe it would be wise to start with the source data?

Next, be ready to ask the following questions when involving your technology experts in the project.

  1. Do we have an information system which already includes the source data needed for creating new services? Can the source data be imported out of the current information system? How much development work is needed for the current information system to enable the development of new solutions?

  2. Have we already started creating, implementing or designing an information system that offers access to source data?

  3. Do we currently have a faulty information system? Is the creation of a new system justified and could we shut down the old one afterwards?

The work group’s perspective

A prototype is not a finished information system – to complete the information system, the prototype should be used by various people as a tool for testing solutions. A prototype can be considered reasonably well executed if you can give a positive answer to all of the following questions.

  1. Are all the elements and their purposes in the solution understandable?

  2. Are all the interactive elements clearly identifiable? Do these elements behave as expected after the user has interacted with them?

  3. Is it clear how and when the system moves from one page to another?

  4. Is the system missing necessary parts (e.g. does it have broken links, are error messages displayed etc.)?

If the answers to these questions are ambiguous, then the designer should be actively involved in the development work as well. In that case, it will be the designer’s task to explain, specify, and, if necessary, further develop the solutions.

What should you pay attention to within the different parts of a prototype?

A web-based system (and therefore, its prototype) includes typical user interface components – a homepage, a search function, forms, and navigation. All of these components have different requirements and objectives based on their functionality and overall goal and these have to be taken into account when providing feedback on them.

How to provide feedback on a homepage?

The first thing a user sees in a system, on a website or in an application is the homepage. Because of that, it needs to be memorable and easy to understand. Within 30 seconds, it should be clear what can be done on the page and which company owns it. The homepage should also include references to all important functionalities on the site.

In the case of a homepage, its content and functionality must have a clear order of priority. It is good practice to have 20% of the most important functions placed above the screen’s breakpoint (i.e. the part that is visible immediately upon opening the page). Deciding what to include in this 20% should be based on which content is used most by all users. However, you must also keep in mind that the more buttons and content there are on the homepage, the less likely the user is to click on anything at all.

The designer’s point of view

Although it is common to begin designing a prototype from the homepage and then everything else, then in cases where the project has not yet been developed enough to know its exact contents, it may be better to start from the opposite end and leave the homepage for last.

How to provide feedback on a search function?

The search function is one of the most important functionalities within many systems and websites.

When it comes to creating a search option, you should think about specific scenarios where people need to use it and avoid trying to create a search function that works for every occasion. In general, users tend to consider all-encompassing search functions rather unpleasant and inefficient to use.

Over the course of a discussion, you should reach a general consensus on what should be reachable via the search function and which items are so crucial that they should be included in the menu or within the website’s content (in other words, when searching for those items would be a waste of valuable time).

For the initial search function, large and flexible search forms should be avoided. For the search results, think about how the user will work through them and decide on which one to open.

If the search provides results of different types of items, additional filters should be provided for them after the search has been conducted.

How to provide feedback on various functionalities?

From the user’s point of view, functionalities are the reason why they use a system. It is important to ensure that the various pathways that refer to the different functionalities of a system are named according to the task they help the user to achieve or the functionality it provides them with.

Functionalities also include the operational logic of user interface elements. One of the easiest ways of making sure whether or not they actually are logical is to conduct usability tests. At the same time, if the team thinks that the user interface seems to be behaving “oddly” or that it seems “a bit loose”, then usability testing will usually confirm that, which in turn means that we could have saved time by fixing the issue before testing. In other words, there is no reason to test things we already know don’t work.

  1. Are elements that refer to a functionality names similarly throughout the user interface and do elements that provide the same functionality actually behave in the same way?

  2. Have the developers accounted for both those people who might be using a functionality for the first time as well as those who use it several times a day?

  3. Have more complicated tasks been divided into smaller parts for new users?

  4. Can experienced users perform tasks faster and with less effort (e.g. fewer clicks)?

  5. Has the use of excessive elements – those that stem from not being able to/not daring to decide which way the user may wish to use them – been avoided?

  6. Do the user interface functionalities behave similarly to other user interfaces with similar functionalities (especially those that the user has previously used)?

  7. Does the user interface behave as expected on different devices (e.g. the expected behaviour of a mobile user interface is different from a computer user interface)?

  8. Do all elements of the user interface behave as expected (e.g. you can only select one radio button at a time and dropdown menus expand downwards)?

  9. Does the system give hints about or explain its functionalities to the user?

  10. Are most default values unchanged in most cases?

  11. Does the user interface encourage users to try out its different components and not punish the user for it?

How to provide feedback on navigation?

A website’s navigation system must be evaluated to ensure so that users can navigate a site as easily and logically as possible. It is important for the user to understand which page they are on and how they could find the information they need. A page’s most important navigational labels should be clearly visible, named accordingly, and have a uniform design. Various methods can be used to evaluate how well the navigation is performing, for example, card sorting and usability tests.

At any time, the use must be able to answer these two questions when interacting with the user interface.

If they cannot, then the prototype must be changed. The questions are as follows:

  1. Where am I right now?
    This information is provided by headings, highlighted menu elements, etc.

  2. Where can I go from here?
    This information is provided by elements that take the user to the next step in the process (e.g. the order of the fields in a form, information provided when closing a window) or that prompt them to confirm a choice (e.g. buttons).

To provide feedback, the following questions should be considered.

  1. Is it clear to understand which element should be used next?

  2. Does one specific element always stand out at as the one to be used next and have the developers avoided providing the user with too many elements to pick from?

  3. Do navigational elements behave in a consistent manner (i.e. similarly throughout all pages of the user interface)?

  4. Are element names unequivocally clear to the user (would they name the elements in the same way)?

How to provide feedback on forms?

Frequently, an important part of websites is entering data, which the user may be asked to do through a form. Usually, forms include several different elements, such as input fields, dropdown menus, Call-to-Action buttons, etc.

For the user to be able to enter data as comfortably as possible, a form should not be too long or too time-consuming. Simple and logical layouts, visually correct labels, and uniformly placed and aligned columns all provide added value to and increase the user experience.

  1. At first glance, does the form immediately seem to be properly organised, is its length appropriate to the results the user expects to get from it, and is it generally easy to fill out?

  2. Does the page with the form seem trustworthy and does it clearly refer to the company behind it (proper links, brand elements, no typos, a sufficiently formal style)?

  3. Are the fields in the form grouped together according to their connections (questions and answers that are thematically related are grouped together)?

  4. Are all the questions in the form justified by being necessary for fulfilling the purpose the form exists for?

  5. Are different elements placed in such a way that elements used with a keyboard and those used with a mouse are grouped together?

  6. Have long mouse movements, scrolling, long distances between elements for the eyes to track, excessive mouse clicks and keystrokes been avoided?

  7. Can all the questions always be answered correctly, in the manner asked for?

  8. Does the user understand what is asked and know how to answer by using the elements provided?

  9. Would a real-life conversation with members of the target group make sense if they were asked the same questions in the same order?

  10. Is it clear to understand whether the form was submitted successfully or unsuccessfully and are they given clear next steps to follow? Does the user clearly understand whether they have completed their task (usually some benefit or wish) or whether they still need to do anything else to complete it?

  11. Does the form technically prevent the erasure of data on forms that have already been submitted?

  12. Can the form be filled out with only a keyboard? (This can usually be confirmed with the actual developed form since the technologies available for prototyping may not always allow this.)

How to provide feedback on content?

All websites and information systems have content used to convey their messaging. That content must be useful for the user and meet the site’s goals. The text must be legible, and the font should be clear, sufficiently large and have the right colour. The contrast between the site’s background colour and font colours should also be considered.

It is common for initial prototypes to have so-called dummy content instead of actual content, because testing the website’s primary functionalities and navigation system is more important in the beginning. In more detailed prototypes, the content should be the actual final content, which means that Lorem Ipsum should not be used in those. Since in most projects, copywriters (often the client’s specialists) and designers are usually different people, then content creation should be planned out early on.

  1. Is the text effortlessly legible at 100% magnification at a typical reading distance on a typical monitor? The user must be able to increase the size of the text by up to 2x without other elements starting to overlap or a horizontal scrolling bar appearing. A prototype helps to clearly identify the places where such issues may arise (although the prototype itself might not actually accommodate magnification).

  2. If the visual appearance of the text is the same that will be used in the final design, then are the font, size, and text colour used in the prototype legible enough (prototypes often use temporary fonts and colours)?

  3. Has enough space been left for the text? Consider both translations into languages with longer words (e.g. Russian) as well as compulsory empty spaces around the text.

  4. Is the meaning of the text unambiguously clear to the target group? Does the text “speak the language” of the target group (if the target group is the general public, then the text should also be clear to understand for a 7th grade pupil)?

  5. Does the text avoid decorative but confusing additions (unnecessary conjunctions, emotional or judgmental language, clarifying yet unnecessary parts of a complex sentences, repetitions, text that has been copied from the rules just in case)?

  6. Is it possible to correctly understand the meaning of the whole text and each paragraph by quickly skimming over it?

  7. Is the text sufficiently engaging?

How to provide feedback on visual design?

A cohesive design and look are extremely important for a website, as they allow for engaging the user’s attention and holding their interest. A good design is pretty, simple, clean and creates positive emotions in the user. When evaluating visual design, you should also consider whether it matches to the client’s branding.

Although design is often absent from prototypes, they provide an overview of a site’s structure and attention should be paid to the spaces left for branding elements, their placement and goals.

  1. Are there separate spaces left for our company’s distinct visual elements? Are those spaces big enough?

  2. Do our branding elements significantly lower the user’s work efficiency? Is the reduced efficiency justified?

  3. Is the user’s attention focused on the next most important activity? Is there a component that competes with that activity or element visually? Is that competition justified? Can this issue be solved through visual design?

Conclusion

There are a lot of control questions and not all of them can be discussed during every meeting. You should consider going over just one topic or category at every meeting, and you could schedule longer discussions to go over an entire chapter at once.

We believe this e-book can help you to better plan those meetings and to agree on specific discussion topics in advance.

If you wish to be notified when we publish any other e-books, organise events, or publish new articles, then join our mailing list.



Wishing you fruitful feedback sessions!

Trinidad Wiseman’s team