These principles will lead to an excellent experience for our users. Think of them as criteria that you can refer to when crafting, evaluating and building new functionality for Octopus Deploy.
Provide familiarity and consistency
We want users to feel familiar when using Octopus, which will make the product easy to use and intuitive. We achieve this by reducing the user’s cognitive load, matching the user’s mental model, using existing conventions, and being consistent.
Consider
- Reducing the number of decisions and information available to the user (reducing noise).
- Using existing conventions and terminology familiar to the user, which requires less effort and reduces the learning curve.
- Using consistent patterns and labels.
Ask
- Is the primary action evident to the user, or are there competing objectives?
- Will the terminology and concepts be familiar to the user, or will there be a substantial learning curve?
- Does the functionality match the user’s mental model?
- Is the UI explaining the functionality?
- Is there an existing pattern or terminology in the product I can use?
Be responsive and helpful
We want to avoid surprises and keep our users in the loop. We can help our users by ensuring they have context, know the expected result of their actions, receive feedback, and have access to information that will help them complete their tasks.
Consider
- Being responsive by providing visual feedback for user actions.
- Providing concise help text in the form of a Note or the contextual help bar (when more help may be required).
- Giving guidance on what can be done to resolve user or system errors.
- Informing the user of the system status.
- Providing context and hierarchy to help the user know where they are.
Ask
- What's the best way to provide feedback on an action the user has just performed? Should it call out the user's attention or be visible but in the background?
- Is there critical information that the user needs to complete the task?
- Does the user have the context of where they are in the product?
- Is there a way for the user to return to where they were?
- Is the user waiting for something to happen?
Build trust and credibility
We want our users to explore, experiment with, and recommend our product confidently. Our system needs to appear reliable and credible. Performance, error states, and unintended consequences of actions can make the product appear unreliable and degrade the user’s trust.
Consider
- Preventing error states the user doesn’t need to be in.
- Helping the user out of error states.
- Allowing users to explore the product without fear of penalty or consequences.
- Improving the product’s performance (and perceived performance) to provide a positive experience for customers at scale.
Ask
- If the user starts to explore away from the critical path, will information be lost, and will the user be able to find their way back?
- Is the error state preventable? If not, how can I help the user resolve the error?
- At scale, will performance be compromised? What’s the threshold for poor performance before it negatively affects our brand and opens the door to competitors?