Design Principles

Developed based on years of experience, these principles guide designers in their day-to-day work and decision-making. They represent a crucial aspect of the design system and overall strategy to ensure we build tools that delight users and bring better data to learning.

Resemble the user’s world

Follow an institution’s mental model

Closely map Watermark to reality. Follow the institution’s mental model of institutional effectiveness and continuous improvement, and create a system and language that is consistent with it.

Let project timeline and user workflows guide navigation

Users may have very different session goals depending on when in the project process they are. Make it easy for them to see, state and identify appropriate actions for the current point in time. Include appropriate hints that trigger the user to take the next appropriate step (eg, “You’re ready to open your scoring period”).

Let users focus on the current task at hand

Support the user’s current primary goal first and hide the rest away by either presenting them as secondary actions or making them available on demand. Support each role’s specific goals. Support for edge cases should be discoverable but not prominent.

You are what you report

Watermark will help users shape and share their story. Since the final report should crystallize the goals and learnings of the assessment process it’s a good starting point to understand our user’s motivations and priorities.

Reflect decisions that naturally happen outside of Watermark

Acknowledge parts of the process that happen outside of Watermark. For example:

  • Curriculum maps always exist, even if we don’t see them.
  • Rubrics are “designed” in a meeting room, using MS Word, they’re only later “brought” into Watermark

Support a positive continuous improvement culture

Help jobs become easier

Our administrator’s jobs, their faculty’s jobs, and ours. That’s why we partner with our clients to pilot assessment projects that work as a way to show their faculty the value of assessment. Providing some level of access to results to all contributors makes the value of the process visible to everyone.

Prompt decisions to the appropriate and respective decision makers

We’ll improve the culture of assessment data-driven decision making by achieving an appropriate level of faculty and student involvement. Bringing contributors onboard is one of our customer’s main pain points. Moving complex decisions up to the admin’s (the believers) level helps simplify the experience for contributors. This also allows institutions with low faculty-engagement levels to reduce the burden on their faculty.

Reduce adoption and execution friction

We reduce cognitive overload by making the experience easy to learn, easy to demo, and minimizing interaction cost whenever possible. We create memorable and consistent experiences, so seasonal contributors can easily find their way throughout Watermark

Help them shift from stick to carrot

Continuous improvement should not be a chore; it is about storytelling and reflection, not compliance. Although contributions may be completed as tasks, the holistic system approach cannot be about data entry, but presented as a storytelling exercise.

Synthesize, don’t suppress differences

Watermark will take the needs of all users (and their personal groups) into consideration, as well as the similarities and differences in workflows across multiple institutions.

Meet users where they are

We will meet faculty where they are. We will not adapt to outlier processes. Not every institution has a positive culture of assessment or continuous improvement, much less a mature one. Clients have mentioned this as one of their main everyday challenges. Watermark is built to improve both existing and new (or nonexistent) data-driven cultures.

Guide and support

Build inclusive and equitable experiences for all users

Designers play a significant role to ensure accessibility of Watermark by empathizing with users and creating usable designs accessible to all. Students seeking higher education and faculty and coordinators utilizing our tools deserve equal and equitable experiences in Watermark.

Accessibility isn't only helpful to people with disabilities but also to many others in the mainstream; there could be some situational, temporary disabilities such as injured arm, carrying a baby in one arm, etc.

Follow a narrative

A narrative provides guidance and context to the tasks performed in Watermark. A good narrative should allow Coordinators (and even the Watermark Sales team) to tell a clear story about Watermark and reduce adoption friction. Committing to a narrative may sometimes mean prioritizing getting the right message across, rather than implementing a nice-to-have feature that can incorporate confusion.

Prioritize reliability and efficiency rather than flexibility

Previous products have allowed great flexibility, but at the cost of complex user workarounds and frustration. Watermark will guide the users through a clear path to success: The Watermark Way of getting work done. We avoid introducing workflows in which flexibility confuses users to reduce frustration within the system.

Define defaults and recommended paths

Defaults avoid unnecessary cognitive overload. Recommended paths build confidence in our products and prevent frustration. If multiple orders of operation are possible, select one as the primary action to recommend.

Help users shape and tell their story

In order to do so, Watermark needs to map their narrative.

Unobtrusiveness and error prevention

The user should always feel in control. Do not over-validate, instead, make sure the user has been properly introduced to a functionality throughout the experience. Avoid fixing workflow errors with messaging.

Avoid rabbit holes

Keep the user focused on their main task at hand. Intermediate tasks should not remove the user from their original context.

In a compound component like Select or Action Menu, child components are rendered in the parent's slot element, part of its shadow DOM tree. Slots essentially serve as a placeholder for markup that you the developer define in the light DOM tree, like <wm-menuitem>, <wm-option>, text content, or other child elements.

The browser distributes the child elements defined in the light DOM into the shadow DOM of the parent. The result is a flattened DOM tree—a merger of the the light DOM and the shadow DOM. This flattened tree is what you see in DevTools and what is rendered on the page.

With the standard implementation of the component, dynamically updating the child items will throw an error. Elm's efficient diffing of the DOM will register that only the child items have changed and try to update them, but the component has already been composed.

Rendering the component in a Keyed node and giving it a dynamic id will cause the entire component, rather than just the child items, to render anew, avoiding the error.