UI, UX: Designing functinality in Tech Industry

Design is a rather broad and vague term. When someone says “I’m a designer,” it is not immediately clear what they actually do day to day. There are a number of different responsibilities encompassed by the umbrella term designer.

Design-related roles exist in a range of areas from industrial design (cars, furniture) to print (magazines, other publications) to tech (websites, mobile apps). With the relatively recent influx of tech companies focused on creating interfaces for screens, many new design roles have emerged. Job titles like UX or UI designer are confusing to the uninitiated and unfamiliar even to designers who come from other industries.

Let’s attempt to distill what each of these titles really mean within the context of the tech industry.

UX DESIGNER (USER EXPERIENCE DESIGNER)

UX designers are primarily concerned with how the product feels. A given design problem has no single right answer. UX designers explore many different approaches to solving a specific user problem. The broad responsibility of a UX designer is to ensure that the product logically flows from one step to the next. One way that a UX designer might do this is by conducting in-person user tests to observe one’s behavior. By identifying verbal and non-verbal stumbling blocks, they refine and iterate to create the “best” user experience. An example project is creating a delightful onboarding flow for a new user.

“Define interaction models, user task flows, and UI specifications. Communicate scenarios, end-to-end experiences, interaction models, and screen designs to stakeholders. Work with our creative director and visual designers to incorporate the visual identity of Twitter into features. Develop and maintain design wireframes, mockups, and specifications as needed.”

Experience Designer job description at Twitter

Example of an app’s screens created by a UX designer.Credit: Kitchenware Pro Wireframe Kit by Neway Lau on Dribbble.

Deliverables: Wireframes of screens, storyboards, sitemap

Tools of the trade: Photoshop, Sketch, Illustrator, Fireworks, InVision

You might hear them say this in the wild
: “We should show users the ‘Thank You’ page once they have finished signing up.”

UI DESIGNER (USER INTERFACE DESIGNER)

Unlike UX designers who are concerned with the overall feel of the product, user interface designers are particular about how the product is laid out. They are in charge of designing each screen or page with which a user interacts and ensuring that the UI visually communicates the path that a UX designer has laid out. For example, a UI designer creating an analytics dashboard might front load the most important content at the top, or decide whether a slider or a control knob makes the most intuitive sense to adjust a graph. UI designers are also typically responsible for creating a cohesive style guide and ensuring that a consistent design language is applied across the product. Maintaining consistency in visual elements and defining behavior such as how to display error or warning states fall under the purview of a UI designer.

“Concept and implement the visual language of Airbnb.com. Create and advance site-wide style guides.”

-UI Designer job description at Airbnb

The boundary between UI and UX designers is fairly blurred and it is not uncommon for companies to opt to combine these roles.

A UI designer defines the overall layout and look & feel of an app.Credit: Metro Style Interface 4 by Ionut Zamfir on Dribbble.

Tools of the trade: Photoshop, Sketch, Illustrator, Fireworks

You might hear them say this in the wild: “The login and sign up links should be moved to the top right corner.”

VISUAL DESIGNER (GRAPHIC DESIGNER)

A visual designer is the one who pushes pixels. If you ask a non-designer what a designer does, this is probably what comes to mind first. Visual designers are not concerned with how screens link to each other, nor how someone interacts with the product. Instead, their focus is on crafting beautiful icons, controls, and visual elements and making use of suitable typography. Visual designers sweat the small details that others overlook and frequently operate at the 4X to 8X zoom level in Photoshop.

“Produce high-quality visual designs—from concept to execution, including those for desktop, web, and mobile devices at a variety of resolutions (icons, graphics, and marketing materials). Create and iterate on assets that reflect a brand, enforce a language, and inject beauty and life into a product.”

Visual Designer job description at Google

It is also fairly common for UI designers to pull double duty and create the final pixel perfect assets. Some companies choose not to have a separate visual designer role.

A visual designer lays out guides and adjusts every single pixel to ensure that the end result is perfect.Credits: iOS 7 Guide Freebie PSD by Seevi kargwal on Dribbble.

Tools of the trade: Photoshop, Sketch

You might hear them say this in the wild: “The kerning is off and the button should be 1 pixel to the left!”

INTERACTION DESIGNER (MOTION DESIGNER)

Remember the subtle bouncing animation when you pull to refresh in the Mail app on your iPhone? That’s the work of a motion designer. Unlike visual designers who usually deal with static assets, motion designers create animation inside an app. They deal with what the interface does after a user touches it. For example, they decide how a menu should slide in, what transition effects to use, and how a button should fan out. When done well, motion becomes an integral part of the interface by providing visual clues as to how to use the product.

“Proficiency in graphic design, motion graphics, digital art, a sensitivity to typography and color, a general awareness of materials/textures, and a practical grasp of animation. Knowledge of iOS, OS X, Photoshop and Illustrator as well as familiarity with Director (or equivalent), Quartz Composer (or equivalent), 3D computer modeling, motion graphics are required.”

-Interaction Designer job description at Apple

Tools of the trade: AfterEffects, Core Composer, Flash, Origami

You might hear them say this in the wild:”The menu should ease-in from the left in 800ms.”

UX RESEARCHER (USER RESEARCHER)

A UX researcher is the champion of a user’s needs. The goal of a researcher is to answer the twin questions of “Who are our users?” and “What do our users want?” Typically, this role entails interviewing users, researching market data, and gathering findings. Design is a process of constant iteration. Researchers may assist with this process by conducting A/B tests to tease out which design option best satisfies user needs. UX researchers are typically mainstays at large companies, where the access to a plethora of data gives them ample opportunity to draw statistically significant conclusions.

“Work closely with product teams to identify research topics. Design studies that address both user behavior and attitudes. Conduct research using a wide variety of qualitative methods and a subset of quantitative methods, such as surveys.”

UX Researcher job description at Facebook

UX designers also occasionally carry out the role of UX researchers.

Deliverables: User personas, A/B test results, Investigative user studies & interviews

Tools of the trade: Mic, Paper, Docs

You might hear them say this in the wild: “From our research, a typical user…”

FRONT-END DEVELOPER (UI DEVELOPER)

Front-end developers are responsible for creating a functional implementation of a product’s interface. Usually, a UI designer hands off a static mockup to the front-end developer who then translates it into a working, interactive experience. Front-end developers are also responsible for coding the visual interactions that the motion designer comes up with.

Tools of the trade: CSS, HTML, JavaScript

You might hear them say this in the wild: “I’m using a 960px 12-column grid system.”

PRODUCT DESIGNER

Product designer is a catch-all term used to describe a designer who is generally involved in the creation of the look and feel of a product.

The role of a product designer isn’t well-defined and differs from one company to the next. A product designer may do minimal front-end coding, conduct user research, design interfaces, or create visual assets. From start to finish, a product designer helps identify the initial problem, sets benchmarks to address it, and then designs, tests, and iterates on different solutions. Some companies that want more fluid collaboration within the various design roles opt to have this title to encourage the whole design team to collectively own the user experience, user research, and visual design elements.

Some companies use “UX designer” or simply “designer” as a catch-all term. Reading the job description is the best way to figure out how the company’s design team divides the responsibilities.

“Own all facets of design: interaction, visual, product, prototyping. Create pixel-perfect mocks and code for new features across web and mobile.”

Product Designer job description at Pinterest

“I AM LOOKING FOR A DESIGNER”

This is the single most common phase I hear from new startups. What they are usually looking for is someone who can do everything described above. They want someone who can make pretty icons, create A/B tested landing sites, logically arrange UI elements on screen, and maybe even do some front-end development. Due to the broad sweeping scope of this role, we usually hear smaller companies asking to hire a “designer” rather than being specific in their needs.

The boundaries between each of these various design roles are very fluid. Some UX designers are also expected to do interaction design, and often UI designers are expected to push pixels as well. The best way to look for the right person is to describe what you expect the designer to do within your company’s process, and choose a title that best represents the primary task of that person.

OWL (Web Ontology Language)

1 Introduction

The Semantic Web is a vision for the future of the Web in which information is given explicit meaning, making it easier for machines to automatically process and integrate information available on the Web. The Semantic Web will build on XML’s ability to define customized tagging schemes [XML] and RDF’s flexible approach to representing data[RDF Concepts]. The next element required for the Semantic Web is a web ontology language which can formally describe the semantics of classes and properties used in web documents. In order for machines to perform useful reasoning tasks on these documents, the language must go beyond the basic semantics of RDF Schema [RDF Vocabulary].

This document is one part of the specification of OWL, the Web Ontology Language. The Document Roadmap section of the OWL Overview document describes each of the other documents. This document enumerates the requirements of a web ontology language as perceived by the working group. However, it is expected that future languages will extend OWL, adding, among other things, greater logical capabilities and the ability to establish trust on the Semantic Web.

We motivate the need for a web ontology language by describing six use cases. Some of these use cases are based on efforts currently underway in industry and academia, others demonstrate more long-term possibilities. The use cases are followed by design goals that describe high-level objectives and guidelines for the development of the language. These design goals will be considered when evaluating proposed features. The section on Requirements presents a set of features that should be in the language and gives motivations for those features. The Objectives section describes a list of features that might be useful for many use cases but may not necessarily be addressed by the working group.

The Web Ontology Working Group charter tasks the group to produce this more expressive semantics and to specify mechanisms by which the language can provide “more complex relationships between entities including: means to limit the properties of classes with respect to number and type, means to infer that items with various properties are members of a particular class, a well-defined model of property inheritance, and similar semantic extensions to the base languages.” The detailed specification of the web ontology language will take into consideration:

  • the design goals and requirements that are contained in this document
  • review comments on this document from public feedback, invited experts and working group members
  • specifications of or proposals for languages that meet many of these requirements

1.1 What is an ontology?

An ontology defines the terms used to describe and represent an area of knowledge. Ontologies are used by people, databases, and applications that need to share domain information (a domain is just a specific subject area or area of knowledge, like medicine, tool manufacturing, real estate, automobile repair, financial management, etc.). Ontologies include computer-usable definitions of basic concepts in the domain and the relationships among them (note that here and throughout this document, definition is not used in the technical sense understood by logicians). They encode knowledge in a domain and also knowledge that spans domains. In this way, they make that knowledge reusable.

The word ontology has been used to describe artifacts with different degrees of structure. These range from simple taxonomies (such as the Yahoo hierarchy), to metadata schemes (such as the Dublin Core), to logical theories. The Semantic Web needs ontologies with a significant degree of structure. These need to specify descriptions for the following kinds of concepts:

  • Classes (general things) in the many domains of interest
  • The relationships that can exist among things
  • The properties (or attributes) those things may have

Ontologies are usually expressed in a logic-based language, so that detailed, accurate, consistent, sound, and meaningful distinctions can be made among the classes, properties, and relations. Some ontology tools can perform automated reasoning using the ontologies, and thus provide advanced services to intelligent applications such as: conceptual/semantic search and retrieval, software agents, decision support, speech and natural language understanding, knowledge management, intelligent databases, and electronic commerce.

Ontologies figure prominently in the emerging Semantic Web as a way of representing the semantics of documents and enabling the semantics to be used by web applications and intelligent agents. Ontologies can prove very useful for a community as a way of structuring and defining the meaning of the metadata terms that are currently being collected and standardized. Using ontologies, tomorrow’s applications can be “intelligent,” in the sense that they can more accurately work at the human conceptual level.

Ontologies are critical for applications that want to search across or merge information from diverse communities. Although XML DTDs and XML Schemas are sufficient for exchanging data between parties who have agreed to definitions beforehand, their lack of semantics prevent machines from reliably performing this task given new XML vocabularies. The same term may be used with (sometimes subtle) different meaning in different contexts, and different terms may be used for items that have the same meaning. RDF and RDF Schema begin to approach this problem by allowing simple semantics to be associated with identifiers. With RDF Schema, one can define classes that may have multiple subclasses and super classes, and can define properties, which may have sub properties, domains, and ranges. In this sense, RDF Schema is a simple ontology language. However, in order to achieve interoperation between numerous, autonomously developed and managed schemas, richer semantics are needed. For example, RDF Schema cannot specify that the Person and Car classes are disjoint, or that a string quartet has exactly four musicians as members.

One of the goals of this document is to specify what is needed in a web ontology language. These requirements will be motivated by potential use cases and general design objectives that take into account the difficulties in applying the standard notion of ontologies to the unique environment of the Web.

1.2 Why OWL?

The Semantic Web is a vision for the future of the Web in which information is given explicit meaning, making it easier for machines to automatically process and integrate information available on the Web. The Semantic Web will build on XML’s ability to define customized tagging schemes and RDF’s flexible approach to representing data. The first level above RDF required for the Semantic Web is an ontology language what can formally describe the meaning of terminology used in Web documents. If machines are expected to perform useful reasoning tasks on these documents, the language must go beyond the basic semantics of RDF Schema. The OWL Use Cases and Requirements Document provides more details on ontologies, motivates the need for a Web Ontology Language in terms of six use cases, and formulates design goals, requirements andobjectives for OWL.

OWL has been designed to meet this need for a Web Ontology Language. OWL is part of the growing stack of W3C recommendations related to the Semantic Web.

  • XML provides a surface syntax for structured documents, but imposes no semantic constraints on the meaning of these documents.
  • XML Schema is a language for restricting the structure of XML documents and also extends XML with datatypes.
  • RDF is a datamodel for objects (“resources”) and relations between them, provides a simple semantics for this datamodel, and these datamodels can be represented in an XML syntax.
  • RDF Schema is a vocabulary for describing properties and classes of RDF resources, with a semantics for generalization-hierarchies of such properties and classes.
  • OWL adds more vocabulary for describing properties and classes: among others, relations between classes (e.g. disjointness), cardinality (e.g. “exactly one”), equality, richer typing of properties, characteristics of properties (e.g. symmetry), and enumerated classes.

1.3 The three sublanguages of OWL

OWL provides three increasingly expressive sublanguages designed for use by specific communities of implementers and users.

  • OWL Lite supports those users primarily needing a classification hierarchy and simple constraints. For example, while it supports cardinality constraints, it only permits cardinality values of 0 or 1. It should be simpler to provide tool support for OWL Lite than its more expressive relatives, and OWL Lite provides a quick migration path for thesauri and other taxonomies. Owl Lite also has a lower formal complexity than OWL DL, see the section on OWL Lite in the OWL Reference for further details.
  • OWL DL supports those users who want the maximum expressiveness while retaining computational completeness (all conclusions are guaranteed to be computable) and decidability (all computations will finish in finite time). OWL DL includes all OWL language constructs, but they can be used only under certain restrictions (for example, while a class may be a subclass of many classes, a class cannot be an instance of another class). OWL DL is so named due to its correspondence with description logics, a field of research that has studied the logics that form the formal foundation of OWL.
  • OWL Full is meant for users who want maximum expressiveness and the syntactic freedom of RDF with no computational guarantees. For example, in OWL Full a class can be treated simultaneously as a collection of individuals and as an individual in its own right. OWL Full allows an ontology to augment the meaning of the pre-defined (RDF or OWL) vocabulary. It is unlikely that any reasoning software will be able to support complete reasoning for every feature of OWL Full.

Each of these sublanguages is an extension of its simpler predecessor, both in what can be legally expressed and in what can be validly concluded. The following set of relations hold. Their inverses do not.

  • Every legal OWL Lite ontology is a legal OWL DL ontology.
  • Every legal OWL DL ontology is a legal OWL Full ontology.
  • Every valid OWL Lite conclusion is a valid OWL DL conclusion.
  • Every valid OWL DL conclusion is a valid OWL Full conclusion.

Ontology developers adopting OWL should consider which sublanguage best suits their needs. The choice between OWL Lite and OWL DL depends on the extent to which users require the more-expressive constructs provided by OWL DL. The choice between OWL DL and OWL Full mainly depends on the extent to which users require the meta-modeling facilities of RDF Schema (e.g. defining classes of classes, or attaching properties to classes). When using OWL Full as compared to OWL DL, reasoning support is less predictable since complete OWL Full implementations do not currently exist.

OWL Full can be viewed as an extension of RDF, while OWL Lite and OWL DL can be viewed as extensions of a restricted view of RDF. Every OWL (Lite, DL, Full) document is an RDF document, and every RDF document is an OWL Full document, but only some RDF documents will be a legal OWL Lite or OWL DL document. Because of this, some care has to be taken when a user wants to migrate an RDF document to OWL. When the expressiveness of OWL DL or OWL Lite is deemed appropriate, some precautions have to be taken to ensure that the original RDF document complies with the additional constraints imposed by OWL DL and OWL Lite. Among others, every URI that is used as a class name must be explicitly asserted to be of type owl:Class (and similarly for properties), every individual must be asserted to belong to at least one class (even if only owl:Thing), the URI’s used for classes, properties and individuals must be mutually disjoint. The details of these and other constraints on OWL DL and OWL Lite are explained in appendix E of the OWL Reference.

 

2 Protégé (knowledge-based applications with ontologies)

Protégé is a free, open-source platform that provides a growing user community with a suite of tools to construct domain models and knowledge-based applications with ontologies.

Reference: http://www.w3.org/TR/webont-req/#onto-defhttp://www.w3.org/TR/owl-features/http://protege.stanford.edu/