Home Why usability When to contract Services Our Team What is a plover Contact

When should I contract these services?

What outcomes we affect in each stage of technology development

Now is the best time to reach out. Developing and improving user experience of technology happens at all phases of the technology development cycle, from idea inception to each new generation of technology that is released. Below are some examples of how you can engage us in different development cycles. We affect outcomes, helping you to get your technology to market faster, increase customer satisfaction, decrease errors, and more.

Two large Baxter robots with faces and arms stand behind a table with red and blue blocks to sort into boxes.
Many colored sticky notes are scattered about on a brown cardboard surface.

Conceptualization.

This is our favorite time to start working with you on user experience. Ask yourself – how much time and money does it cost to develop a new product? If you’re going to spend that many resources, would you like to know if your concept has a high chance of success – or if you could better use those resources on a different product? (click to expand)

When we work with teams early in the conceptualization phase, we focus on ensuring you are meeting a user need. We answer questions like:

  • “How deeply do people care about this need?” – Some needs that users have, they don’t care strongly enough about to go out of their way to fix. We work directly with users to learn how important the need is to them. The stronger people care about it, the more they will purchase your product.
  • “Is there a more core or specific need we can meet?” It might be tempting to make a robot to complete every household chore – but that would require many intense and diverse capabilities in the robot. In our work, we determine core needs. For example, what is the most time-consuming household tasks? That way, you can focus on the highest user need and get your technology to market faster. The rest can come with later releases.
  • “Will this product really solve the user’s problem?” Many technologies have failed because the developers thought they had developed a solution to a user need, but found upon release that they had missed the mark. This is especially common if the expected customer base differs in important ways from the people making the technology. For example, young adult to middle-aged developers making products for older adults can easily miss concerns they might have (e.g., what if I trip on the short robot?). We work directly with your future customers to help you create something that truly fits their needs, resulting in product success.
  • “How much money would people be willing to pay for this?” – This is important to know early. If we learn that people are not willing to pay more than $200 for the item, and your estimated cost is $5000 per item, you will know if you must look into different types of customers for whom the technology is more valuable or wait a few years until it would be more affordable to create technology. Conversely, if what customers are willing to pay is similar to the estimated cost, we can set a cost goal to inform decisions on the components for your product, to keep it affordable and purchasable.

Early- to mid-development.

Whether or not you have thought deeply about the user experience yet, this is another great time to consider it. This is an optimal time to work on making the technology easy, intuitive, and robust to context. It is important to engage in this stage before you have completed the product. This is because our learnings about user needs will inform hardware choices, workflow needs, and more. Designing for the users from the start means that you don’t have to spend extra time and money changing the hardware and software design later to meet user needs. (click to expand)

When we work with teams during early- to mid-development, we focus on usability and robustness. We answer questions like:

  • “Does the hardware meet user needs?” For example, does the speaker have the appropriate quality to be audible used in a given use case? Are the buttons placed such that a user can easily press the one intended and not accidentally press another? This saves development time, meaning that you don’t have to later reorganize the design to include the necessary hardware, or reprogram the technology to function with the new hardware.
  • “Is the user workflow easy and intuitive?” Because engineers have spent so much time with technology, what seems intuitive for them is often not intuitive for naïve users. We learn what users need to understand and move easily through using the product, and pass tangible design recommendations to your team to make your product more effective for the end-user.
  • “Can users accomplish their goals quickly?” We can reduce user time on task. This might look like consolidating information, reducing workflows that are no longer relevant, and more. Doing so increases customer satisfaction, time saved, and willingness to purchase or recommend the product.
  • “Can our customers use this technology in the different contexts that they need it?” Engineering tests on the engineering floor usually look very different than tests in the environment the product will be used. Is the lighting different? The sound environment? Can the mobile robots roll over the types of terrain they will encounter – whether that is in a home (hardwood floors, carpets, or bumps that divide one room from another), in cities (bumps and cracks in sidewalks, puddles), or rugged natural terrain? We identify contexts of use, test use of robots in these contexts, and provide recommendations or design requirements, to decrease product errors in diverse situations that customers use the robot.

Two warehouse workers in orange vests walk through the warehouse. One is in a green pool inner tube with green flags, acting out the part of the robot.
A white humanoid 'Pepper' robot is dressed in a chef's hat and uniform. Its chest has a blue screen with a menu.

Late develop to release.

If you are approaching a release date, this is still a good time to consider user experience! Whether you have explored user experience earlier in development or not, considering it before release can boost your product’s success. At this late stage, we work closely based on your constraints. For example, you might only have one or two hardware components that could be modified. Elements of the user interface might still be flexible. We then hone in on how these elements can be modified to provide the best user experience. (click to expand)

When we work with teams during late development, we focus on what is still possible to change to improve user experience and meet your timeline needs. We answer more specific questions about your program like:

  • “What type of errors or failure cases are most important for us to prioritize fixing?” At this stage, you want to get your product out on time, and every minute counts. We help you prioritize which errors will more negatively affect the users and their trust of the product. We help prioritize what needs to be fixed before the release date and what can be fixed after, to decrease critical errors and build user trust.
  • “Does my robot’s communication makes sense to users?” When robots communicate with lights and nonverbal sounds, it can help or hinder user understanding. Even word choice can affect what the user does next. We can recommend specific tweaks to this communication interface to help users understand how to interact with your product so they can understand your product’s value and increase purchases.
  • “Does the menu organization support user understanding and ease-of-use?” How a menu is arranged can make the difference between a user quickly and easily finding what they need (invisible use) and getting lost and frustrated within the software. This can be a quick change that makes all the difference to product lovability, increasing purchases and use.