Business Needs

Our client had a need for a custom designed dashboard with multi KPIs in presentation. This dashboard was designed to meet the needs of higher management. The main guidelines of the dashboard were to keep buttons and navigation factualities to a minimum, designed to flood a lot of crucial key performance indicators in a single page.

Work Guideline

As a first-time analytical dashboard at the client’s company, , the product manager defined the need for as few buttons as possible for the busy company's CEOs whom the product was design for. One more important request was to create an impressive look that would make the user feel as though they were a part of a worldwide organization.

Final Product

The dashboard’s final result had a modern look and feel with multi KPIs that met the need for a large point of view on a single page. A few features were added in order to give the “worldwide organization feeling” such as the map, the world clocks, and coin exchange rates at the top of the screen.

Description

The idea for this interface was, "make it simple". This interface was the solution for the technology savvy retail players such as CEO’s, buyers, etc. This e-commerce interface shows a real company product instead of dry serial number identifiers.

Research

The inspiration for this solution came from combination between the customer "collection notebook" (Each season has a notebook with the relevant items) and e-commerce sites (The natural work environment of the buyers).

BPERSONAS

The target audience for this type of interface were the CEO, Buyers, Logistic workers, etc. who had a daily interaction with the company merchandise, but did not know how to use the current complex business intelligence system, unlike the CFO, Accountants, Economics, etc. who enjoyed the current system but had almost no interaction with the merchandise.

Solution

The solution was an up-to-date “image oriented” interface [Left] that had similarities to common e-commerce websites that the target users were already familiar with instead of the current old elaborate operational logistic system [Right].

Description

Mobilibuy is an award winning young startup who offer unique shopping experience using the mobile camera. Mobilibuy needed a backside management solution to their business users who was affectionate called “Mobiliback”.

Personas

As part of intensive Preliminary research, a vast Target audience had been exam. The final personas that had been agreed to represent the backend interface users, include the administrative users and the operational users.

Due to the fact that the system will offer a vast amount of functionality option, it was decided that the personas should include mobilibuy own Service providers (colored in purple), this way the interface will serve the needs of the people that provide an administrative support that is part of the product itself.

Final Product

Two main business goals led to two main UX features that pleased the client (developed with Axure) :

Goal 1#

In response to the need for real time B2C relationship, a top “shelf” was placed on the top side of the screen. The small screen icons represent the user’s screens. Those icons ware defined to flash when a purchase was made, allowing the user to be in total control [Image 1].

Goal 2#

In response to the need of an intuitive and easy store building, a simple drag & drop graphical wizard was designed [Image 2].

Close Project

Description

As a self challenge, I was asked to design an application that runs on PCs and allows users to capture (copy) any rectangular section of their PC screens, and then share it with others as an image. For example, user can mark a rectangle over an interesting part of a web page, click some “Capture” button and then get a popup that allows her to specify whom to share with.

Design Scope

My Task was to design the popup that appears after clicking “Share”, assuming that user is currently logged-in to Facebook, Twitter, or LinkedIn. I chose to do it as an Invision prototype that offered a straightforward and fast operating interface, which allow quick publishing of the captured rectangle.

Close Project

Description

The demends regurding this dashboards ware very clear: high level view to the comapny's top exequtives, a mid level view to the account manegers and CFO, and a low level (detailed) view to the opperational Functionaries. Plus, after using an old fashion information system, the need for eye catching designed system was a mendatory.

Final product

The final resualt offered a sutable solution to the customer's demands. The structure of the screen support the view level hirarchi through first showing a digested information to high level exequtive, the other screen structure offer a mid-level view with the option to further drill down to the lower-level data.

MMy Trip: A Travel Planning App • codepen

As a self-challenge, I tried to design my own idea for a trip-planning app. I encoded only two screens from the rest of the project, which are the landing page (left) and the vacation timeline page (right). I focused mainly on coding the small details in order for it to look clean and clear.

Nearby: A To-Do List Proximity Reminder • codepen

For a while now I have had this cool idea of developing an app that will alert you whenever a friend/coworker/anybody passes you by and reminds you to do/say/give something to him or her. So I designed a few screens that presented the reminders list (left), allowing you to add reminders for a particular person (middle) and letting you set the content and deciding how important that it is for you (right). I added small hovering effects as well.

Smart House: An IOT Management App • codepen

Following the trends of this IOT age, I tried to define my own house IOT management app. I designed a horizontal scroll dashboard with minimal mandatory controls for each Internet-connected device (left), and a full screen operative page for each connected device (right – the "water boiler" example).

DoList: Two Approaches to Handling Tasks • codepen

As I see it, tasks can be managed both within subject variations and within a timeframe. I designed two screens that support this approach. One shows the subject variation (left) while the other supports the timeframe (right).

Description

This project was a special one. The challenge was to design a dashboard that provided a high-level view of the company’s customer income for each of her five different divisions (and for the total as well). This dashboard was targeted to serve the company’s customers and the high-level executives, meaning that it needed a clear and understandable interface while also keeping it simple to use.

Functionality

Unlike a traditional dashboard that contained filters and buttons for drill down purposes, this particular one contained only the most needed buttons at the most clear and expected locations on the screen. The idea was to allow the users to see only the highlights of their measures, which included their revenue in total and their distribution for each one of their investment divisions (branded by color and icon).

Mobile

Like any other customer-oriented system, the need for mobile accessibility was a must. It was important to assure the look and feel as well as the simplicity and functionality of the dashboard would be the same as the web version. The outcome was a similar interface for a mobile structure, where the large division buttons served well for this target by being intuitive and relevant.

Close Project

Description

“Wakee” is the vision of an entrepreneur and a friend name Erez Narotzki. The app was aimed to help negotiate between a business (B2B) and their customers (B2C) with what defined as “lost opportunities,” which are cases where customers cancelled appointments and created income losses for the business (B2B) or cases where customers were interested in “hard to get service” and want to be informed when it became available (B2C).

Business Personas (B2B)

When we got into the business personas definitions, we understood that this Wakee service could especially help businesses that were within the range of very small (a single person) up to small-medium businesses (up to six employees). We assumed that the rest of the business ranges would have the resources to deal with their lost opportunities.

Consumer Personas (B2C)

Here it become a bit more complex mostly because of the early stage of the app evolution. After some field research that include mostly talking to friends and family (as a potential target audience), we understood that the user can be a person that interested in an appointment and find it hard to squeeze himself into a wanted business provider (Random user), or a person who used many services and always looking for the best, cheapest and readily available purchase opportunity (massive user).

Final Outcome

The final product was an holistic UX design that include clickable Axure prototype for the B2B Mobile users and B2C Mobile users and a series of PowerPoint mockups to the B2B and B2C web users. Most of the effort was given to the mobile platforms due to the app mobile accessibility needs.

Close Project

Description

For this case I was asked to design a dashboard for a product company that developed an information system for traveling agencies. The dashboard was defined to be adjustable for the company's brand color. The outcome was a high-level view of the company's income vs. expense by time period, a hive of multi top/worst measures for the company's most important functions, and a geographic income distribution.

Description

"SCRT" is a concept app that tries to collaborate between private content (e.g “Secrets”) and the social community (who you want to share your secrets with). For this project, an Axure prototype that included a log-in page and a home page was made.

Log-in Page

For privacy assurance, a password was required to enter the home page. An option to eliminate the password for quicker entry (next time) was provided below the control. On the lower part of the page, there was another element (a security announcement) that aimed to provide another security filing for the user.

Home Page

The screen splits vertically into two sections. On the top part, some new “Shared Secrets” appear on a horizontal scrolling area. On the second part, a timeline of the user’s own secrets spreads from top to button. A special designed icon that hints to “add a secret” sticks while scrolling.

“My Secrets” Structure

The “Secret” structure is built from 3 parts: 1. An icon for suggesting a “secret” type. (For example: text, voice recording, image, or video.) 2. The content of the secret appears in the middle, and a tap required for extra details. 3. A privacy status appears on the right section.

“Friends’ Secrets” Structure

The “Friend’s secret” is also built from 3 parts: 1. An avatar of the friend who sent the secret on the left side with his name appearing right next to him. 2. Some of the content of the secret appears in the middle, and a tap is required for extra details. 3. On the right side there is a hint of another friend’s secret, and horizontal scrolling is required.

Close Project

Description

Chrome extension for VIZRT’s social solution named Feed Streamer. This tool was designed and developed to improve the users capability to extract social media posts directly from the feed (Twitter, Facebook, Instagram, etc. )

Research

This tool was a product of vast research throughout our exist customers. We found out that our users look for an easy and intuitive way to extract content from the web. We took inspiration from similar product like Hootsuite, Buffer that already offer an extension in order to enhance their workflow.

Prototyping & Design

The design process have been made using PowerPoint for the basics mockups, Axure for interactivity needs and finally photoshop. The final design was tested and picked as the best solution.

CODE

The final design have been executed by using pure CSS for the usage of the development team. The development team used this HTML/CSS template and insert the logic into it.

Solution

The solution had to be as similar as possible to the native tool. The extension’s structure was a direct replica (structure wise) of the native tool panel, the similarity provided successful learning curve.

Miliarium Design System: ClickSoftware case study

Design system is one of the most effective tools for minimizing the gap between design deliveries and the actual outcome in large organizations. It serves as an effective communication tool for designers and developers in the same organization and as a single source of truth for multi-interface products.

In this post, I will share the experience of establishing a design system at ClickSoftware. The purpose of the article is to encourage the establishment and implementation of such a system in other companies, thus improving one of the most significant factors in the development process: the communication.

Background

ClickSoftware is a global product company engaged in field service management and has been around for 30 years. Currently, the company has about 700 employees, 130 of whom are developers and 10 of whom are product managers. In addition, the company employs three outsource development centres (India, Russia and other centres), with about 40 developers.

Two years ago, it was decided to migrate the company’s flagship product to the cloud, to what is nowadays called Field Service Edge (aka FSE). Therefore, most parts of the product were essentially redesigned by an external design agency. In addition, ClickSoftware has been making a move into an Agile development process, which meant rapid development rates with frequent releases.

Over the years that followed, in the absence of a single maintainable style guide, many modules and features were added without being crafted according to a single source of truth. The implications were noticeable: prominent inconsistency across the system; mixed and incompatible colour palettes; different patterns for the same usage; multiple font systems and so on.

The research

We had to come up with a solution that would support the needs of a company of such a magnitude and the Agile environment it was shifting to. The solutions examined ware diverse and included the use of Invision Studio, which supports code exposing and design management solutions; the use of Zeppelin for exposing the code from Photoshop or Sketch files; the use of Figma; and many more. All of these solutions were abandoned because they did not support real code production infrastructure, limited the flexibility of self-development and created dependency on third-party providers. We decided to explore the use of a self-built design system.

We gained most of our knowledge about design systems from web research by reading material developed by leaders in the design system field. The greatest inspiration came from Brad Frost, author of “Atomic Design”. In his book and articles, Frost compares the user interface to a modular entity made up of atoms (colours, fonts, buttons), molecules (input box with label, page header), organism (forms, primary navigation, search form), templates (page parts) and pages (full pages).

In addition, we learned about existing frameworks such as Twitter’s Bootstrap, Salesforce Lightning Design System, Marvell Design System, GE Design System Predix and many more.

Our pain point

The purpose of the design system was to facilitate and optimize Click’s development process. By developing it, we succeeded in coping with the following challenges:

• Size and distribution: The number of developers (~120) and their distribution (Israel, India, Russia) made communication a real challenge. Basic UX guidance and UI interactions, such as buttons and checkboxes, had to be carefully discussed upfront in the development process and carefully tested after. Multiple meetings were held to guide basic UI behaviours, and this occupied many team members each time.
• Inconsistency: Due to the lack of a clear and orderly Style Guide, the product reached a state of multiple variants of the same UI elements, such as buttons of different sizes and shades, many versions of dialog windows, fonts of various sizes and weights, and a general feeling that the product consisted of dozens of products incorporated into one. Needless to say, this inconsistency was very damaging to the product experience and mentioned as one of the Nielsen Norman Group’s 10 Usability Heuristics for User Interface Design.
• Continuous delivery: The transition to the cloud and the use of an Agile methodology, which enables the release of versions and bug fixes at a higher rate than ever, put substantial pressure on the design and development teams.
• Accessibility: Due to the need for accessibility support, according to the WCAG accessibility standards, and the substantial time invested in making our products accessible, this was a good opportunity to integrate accessibility into our product in both the design and the behavioural levels (Contrast, Keyboard Navigation, Screen readers, etc).

Architecture and strategy

Technically, we had to write a central CSS library that would be supported by many browsers and contain the code that defines the visibility of each element in the interface, in addition to its behaviour during different user interactions. Moreover, the library had to be available for downloading and embedding in the development environment.

Strategically, due to the fact that the design system had to serve an existing product, rather than a futuristic one, we decided to follow the existing product design language in order to avoid more inconsistencies. We marked all the existing components and patterns we found useful and which we believed we should stick to.

The design and development process

The development turned out to be much more complex than we expected, with elements such as dropdown menus and date pickers requiring careful consideration of both the functional level (JavaScript integration) and accessibility aspects (keyboard navigation, tooltips, etc.). Due to the complexity of developing such UI elements, in parallel to the urgency of developing additional features, it was decided to focus on elements that did not require a significant amount of work. The first elements were the buttons, the checkboxes, the radio buttons, the toggle buttons, the loaders and a number of dialog window types.

We also created a robust sketch file that contained the UI elements on all states for designers and product managers for rapid wireframing. Those elements could be very useful when trying to deliver requirements and stay aligned to one experience. We used Zeplin to communicate the exact specifications for each UI element.

Colour palette

Our product’s current colour palette was a combination of two libraries (Flat Colour and Material design). A uniform colour palette was selected to avoid abnormal changes in the existing system. Out of this logic, we determined our primary brand colours (blue and yellow), a palette of grayscale for backgrounds and text and a varied palette for data visualisation.

Font system

Prior to the font selection, FSE used two font families, depending on the OS it was running in (Ariel for Windows and Helvetica for MacOS). This separation caused a great deal of inconsistency and usability issues, such as different font weights that led to readability problems, text swiping and so on. We chose Roboto to be our primary font family and Ariel and Helvetica as the fallbacks. Roboto is a well-known web font family that supports multiple languages (which was a mandatory requirement) and can be used in any OS.

Icons

FSE icons are a combination of the widely used Font Awesome library and icons made by Click’s UX team. Each font system implementation and update method is different, so we chose to preview the two separately in order to support the developers’ way of using them. Each icon includes the class name, as used in the production environment.

UI elements

The UI elements were selected in the same way as the colour palette. The elements were designed so they would not look much different from the overall look and feel of the system (so as not to create another inconsistency). In order to improve the current look and feel we provided a bit of a design twist; for example, the buttons received an order-radius of 2px in their new design, compared to sharp corners in the previous version; dropdown menus were designed in a slightly different shape, and radio buttons were also updated.

Templates and pages

As mentioned above, we followed “Atomic design” methodology and issued what we considered to be the template section. We decided upon the structure of the main dialog window and issued a consistent set of templates for representative and diverse needs. We chose to focus on the most common and basic patterns in the system, in order to provide the most essential ready-to-use templates.

Code

Without diving into much technical detail, the system’s purpose is to ensure consistency, so the code should also support it. The colour palette mentioned above was designed according to the UI needs, which means that each colour was carefully included in the SCSS custom property list. by following this method, we increased the chances of consistency, as long as developers embrace the use of variables instead of hard-coded Hex values.

Micro Copy

Language and tone of voice are critical parts of building a positive user experience. Every element that includes textual content has been reviewed by a technical writer, who ensures that the written language is in line with the company’s voice guidelines. Examples of this can be seen in the validation content in the various forums, in the use of capital letters in the dialog window titles, and even in the explanations of each UI element across the system.

How to get resources for such a project

A project of this magnitude cannot be done alone, especially in conjunction with ongoing work on new features, maintenance of old features, endless distractions and “more urgent” things that require immediate attention and support. In order to carry out the project, a number of colleagues that were familiar with the urgency of establishing such a system joined forces for research work in parallel to ongoing tasks. The goal was to illustrate the problem clearly to the management, to explain the chosen solution and the reasons for its selection and to integrate the development as a defined time during future sprints.

As a prelude to convening with all the decision-makers, personal meetings were held with each one, so that the kick-off meeting would be practical and achieve its goal (development hours) rather than presenting the idea in a meeting with multiple participants and creating confusion among some. The kick-off meeting included an organized presentation of the problem, the reason for its creation, presentation of the suggested solution, evaluation of the hours and resources required for the development of the system and a PRD (Product Requirement Document) according to our company’s accepted format.

Miliarium?

Miliarium, which means milestone in Latin (miːllɪˈaːrɪʊm ˈawrɛʊm), a monument in the Roman Empire, relative to which all distances were measured. It was erected by Emperor Caesar Augustus near the Temple of Saturn in the central Forum of Ancient Rome.

We take the establishment of Miliarium, ClickSoftware’s first design system as a substantial milestone in the ongoing effort to establish ClickSoftware as a customer experience leader for FMS (Field Management Software).

Advocation

As an opportunity to share with the local tech community what we learned from the process, we hosted a design meetup, called "Scaling Design". Among other lectures, I told our story of achieving our goals.

Conclusions

There is much to consider when building a design system, from the level of the technical architecture to its design challenges and limitations. On projects such as this, I strongly recommend designating one person to act as a product manager to be responsible for the implementation of the system and ensuring that awareness is raised for it among the decision-makers in the organisation. It’s very important to allocate stakeholders within the company who will contribute to the realization of the project from all parts of the process (designers, developers and product managers).

Special thanks to all of those who contributed to the realization of the Miliarium: Lior Gershtain, Peter Shershov, Omer Gabay, Reut Brill and any Clicker out there.

Business Needs

The Clicksoftware product suite offered wide coverage for field service management needs. Among new requirements, was a need for a tool that provided a way to manage shifts (for people and equipment). The tool needed to be able to synchronize with the central database and be used as an additional tool.

Work guidelines

The requirements that were carefully formulated by the product manager included, among other things, the need for a tool that would allow the editing of shifts (by technician, shift or role) In the most visual way possible.

Research

Due to the product complexity and the implementation of new patterns, usability tests were conducted on approximately 7 users who represented potential users, in order to confirm assumptions that were accumulated through the UX phase (made with Axure).

Final product

Although the product is still under development, beta experimenters who have experienced using the product suggest it is an intuitive and simple interface. The decision to design the interface to be consistent with the rest of the company's products has proven itself to be the main contributor to its success.

Description

Severe weather throughout certain parts of the US has brought to light the need for an alert system that will fetch weather data from qualified suppliers and will trigger graphics live from the broadcast directly to the viewer’s home TV screen.

Structure

Each rule contains three main parts: IF-THEN-WHEN & WHAT , which are the three parts targeted to provide a flexible way of automating what kind of nature event triggers what kind of graphic on air.

IF

The ”IF” stands for the kind of event that will trigger the rule (for example, a tornado warning or heavy rains). The user can decide what the relevant source of data is (for example, AccuWeather, Wsi, etc.).

THEN

The “THEN” stands for the kind of alert that will be displayed onto the triggered graphic on top of the TV screen. The options are divided into three: the first is a particular event that is deemed the most important by the user, the second is the same event that triggers the rule, and the last is a customized list.

WHEN&WHAT

The “WHEN” stands for the time period that the rule will be active. The "WHAT" stands for the type of graphic that will be allocated to the TV screen.

Execution (WPF)

The development process was a cooperation of both me and the developers team, I implemented the UI using XAML (a combination of HTML and css) and synced with the development team who used c# on the back-end.

Final Outcome

The generated output of the "Alert Rule Automation" is a broadcast scene which usually serves the broadcast networks and content creators for animated bursting "Lower third", "Squeeze scene", etc.

Description

VIZRT's company flag tool Story (video editor) needed a complementary tool for maps editing. An inline frame within the editor wasn't possible to implement due to technology restrictions, so a popup window was found to be the best solution.

Research

The research was mainly based on a similar product that served the company's older tools. For the current product a great deal of inspiration has been drawn from "My maps" of Google (The hovering controls of the map), "Prezi" (The jump between the scenes), "Photoshop" of Adobe (The expandable menu buttons).

In General

The map UI was designed to enable adding and removing labels, choosing a basemap style, adding labels from a custom location on the map and providing “fly through” animation.

Menu

In order to provide as much “map area” as possible, a special control was formed. This control needed to be both intuitive and scalable for maintaining a large real estate for the actual map.

Label

The label editing needed to be fast and clear with as few as possible clicks. The provided solution allowed both name and label editing.

Bird's Eye View

A special feature that served as a summary for the scene was the “Bird's eye view” which provided a detailed view of the entire content.

The Output

The generated output of the map UI is a broadcast scene which usually serves the broadcast networks and content creators for animated interactive maps.