Spirit & Vision

We like to think we know what users want, and that’s what we design to. Covering both business users and consumers, we have controls, patterns, layouts and guidelines, but those tools need to come together to meet the Expectations, Values, Motivations and avoid the Deal Breakers so that the experience is optimized for the individual user and not the technologies used.

Expectations

  • Convenience
  • Consistency
  • Predictive
  • Customizable
  • Security
  • Ease of Use
  • Error avoidance
  • Device-optimized
  • SoLoMo

Motivations

  • Fun/Entertainment
  • Self Expression
  • Discovery
  • Preparation
  • Productivity
  • Shopping
  • Socializing
  • Context

Values

  • Comfort
  • Freedom of movement
  • Flexibility
  • Collaboration
  • Error Recovery
  • Efficiency

Deal Breakers

  • Confusion
  • Slowness
  • Errors
  • Insecurity
  • Complexity

Design Principles

Mobile First: allows people to complete a task when they want, where they want, how they want; surfacing the most important actions, tasks, and information first. It also can mean an adaptive experience based on the persona and task at-hand. It’s important to remember that ‘mobile first’ as a design principle doesn’t automatically mean responsive, but in most cases for web applications a responsive approach is recommended.

Personalized: allows people to configure and personalize the experience in a relevant way, intuitive to them. They are given a house and the means to furnish it as they like rather than a ‘furnished apartment’ they were handed without any say or opportunity to make it their own.

Flexible: allow people to work within the system they way they want. Allow for frequent and infrequent task completion paths; linear and nonlinear ways of working.

Predictive & Automated: as people spend more time in the system, the system should respond by surfacing frequent tasks, workspaces and information most used without explicit ask or action. As many tasks should be automated as reasonably possible to make people’s working lives easier.

Simple: A single piece of information or task should be no more than three clicks away from any other piece of information or task. Period. If a flow isn’t allowing for this criteria, the flow needs re-designing.

Fun: “Wow that was easy.” “I may not like the task but I love this interface”

Above All, User-Centric: follow user-centered design processes. Demand design principles are in place as part of any MVP criteria.

Visual System

With the YaaS identity we combine strong, meaningful attributes and elements to form a transformative brand for a transformative time.

Primary Colors

techne combines the soft modern tones with high-contrast, friendly colors.

#e0e9f0

#ffffff

#313440

#0486e0

#fcdf2b

Secondary Colors

We use a broad range of secondary colors that complement our primary colors.

#b7c1cd

#04ce26

#fbbb21

#ff3b30

Typography

Good typography adds personality to an application, and can help set tone in the absence of visual elements. hybris and YaaS IO uses Dosis to create a friendly and inviting environment.

Dosis

Dosis is being used for large text such as titles and headlines. We use Dosis in 3 different weights.

ABCDEFGHIJKKLMNOPQRSTUVW

abcdefghijkklmnopqrstuvw

0123456789

Aa

Regular(400)

Aa

Medium(500)

Aa

Semibold(600)

Font sizes

Grumpy wizards make toxic brew for the evil Queen and Jack.

H1 - Dosis Regular(400), 29 pt - Page Title, mobile header

Grumpy wizards make toxic brew for the evil Queen and Jack.

H2 - Dosis Medium(500), 26 pt - Section titles

Grumpy wizards make toxic brew for the evil Queen and Jack.

H3 - Dosis Semibold(600), 21 pt

Grumpy wizards make toxic brew for the evil Queen and Jack.

H4 - Dosis Medium(500), 19 pt

Open Sans

For the main body copy we switch to a font with a great readability on the screen. Open Sans is a Google font that’s crisp and clean. For maximised legibility we slightly increase the leading as well.

ABCDEFGHIJKKLMNOPQRSTUVW

abcdefghijkklmnopqrstuvw

0123456789

Font sizes

Grumpy wizards make toxic brew for the evil Queen and Jack.

Body copy - Open Sans regular, 15 pt

Usage


Click on the thumnail to see an example of the applied fonts, weights and sizes

Tone & Voice

Guiding Principles for Tone and Voice

  • Mobile first
  • Consider 3Cs (context): user context (likes/hates/habits/state-of-mind, device posture), environmental context (time, day, location, place), world context (what is happening around the user we can leverage or use to inform the UI)

Language

  • Friendly
  • Concise
  • NO PASSIVE VOICE. Only active voice.
  • Present tense
  • Avoid redundant words; redundant to themselves and to the context
  • Avoid including information the user doesn't need to know or care about
  • Lead with the most important information and focus on the user's task
  • Avoid the use of contractions
  • Don't 'second guess' the user's intentions. Only ask for confirmation of action if action will cause root-level or irretrievable changes.
Is Not Is
This is a large file and may take time to download. Please wait until all files have been download. Large files may take additional time to download
has been successfully deleted. deleted
To add a product, upload an image. Upload an image to add a product
You are. Is not. Will not. Did not. You're. Isn't. Won't. Didn't.
Do you really want to delete this file? Warning! Warning! File will be permanently deleted.

Punctuation & Capitalization

  • Use periods for messaging with multiple sentences, or when the sentence has other punctuation. Like this one.
  • Use initial caps
  • Capitalize proper nouns only. Do not capitalize random words in a sentence. It IS difficult to Read.
  • Use an ellipsis... to indicate lag or that an additional action will be required after making the selection.
Don't Do
Spell out numbers greater than ten
i.e. fourty two		 Use numeric characters for numbers greater than ten
i.e. 23, 57, 87
Use lower cases for labels
i.e. save		 Use initial caps for labels
i.e. Save
Spell out words with common abbreviations
i.e. application		 Use common abbreviations
i.e. app
Use words like 'please' or 'sorry'
i.e. "Sorry, that file cannot be deleted."
i.e. "Please contact your administrator if you forgot your password"		 Be concise and friendly. Stick to the important content and lead based on the task.
i.e. "File can't be deleted."
i.e. "Forgot your password? Contact your admin."

Messaging & Dialogs

Keep messaging as generic as possible to allow for product branding/labeling name changes in the future. Use hyperlinks to guide the user to pages where they can get more help or informations.


Is Not Is
Billing Method added.
 Billing Method added
Shipping Cost saved successfully. Shipping costs saved Package couldn't be saved, a Package requires min. one Service. Save unsuccessful. Add a least one Service.
Image upload wasn't successful. Try again Image upload unsuccessful. Try again.
Package approved. Team can decide when to publish to y Market. approved. can decide when to publish.

Language and Translation

Initial UI messaging should be written in American English using the guidelines above. hybris Translation Services will take care of product copy translations.

System Errors

Every service in YaaS uses the common error message schema for error response payloads. However, these messages are typically not human-friendly. We recommend using the error code mapping provided for API Best Practices at the Dev Portal. Some examples on how to write YaaS system errors:

  • We need all required fields complete to keep you moving.
  • We need all your entries to be correct to keep you moving
  • Whoops! We can't find what you're looking for. Try again
  • Whoops! Something went wrong. Make sure all fields are complete and try again
  • Whoops! That doesn't exist. Try again
  • That's so great it already exists! Try something different
  • There's a ghost in the machine. Sorry about that. Please try again
  • Something went very wrong. Please try again.

Writing Help

Do explain: Don’t explain:
  • Unfamiliar concepts
  • Where to find obscure information
  • What format the information should be given in
  • If possible, provide a link to documentation where people can find further information on complex topics. The link should always be to the topic, not to the documentation source.
  • The interface
  • The user’s job to them

Example how to use Links

Do: Don’t:
More information on how to create a service on DevPortal. More information on how to create a service on DevPortal.

Accessibility

Being truly user-centric means supporting ALL users. Techné is designed to be accessible to all users. All interfaces should make every best effort to adhere to the W3C Accessibillty guideline critiera as detailed here:

Web Content Accessibilty Guidelines:
http://www.w3.org/TR/WCAG20/

Authoring Tools Accessibility Guidelines (candidate recommendation:
http://www.w3.org/TR/ATAG20/)