UX Blog

[lima-julia-blog]

Time's (officially) up! :(

Style guides can take many different formsand shapes; they vary in content, and they can be done as a first step of aproject or in the middle of it. In fact, the only thing that every guide has in common is its purpose: to work as a nexus between design and development to achieve a consistent, usable, and user-focused result.

An initial version of Evergreen’s UI Style Guide is finished. It was made with a focus on consistency, usability, and user-centered design concepts. It was not possible to cover all the topics proposed, but the most important were thoroughly considered and developed.

To helps understand the scope, here is the index of the Evergreen  UI Style Guide:

1. Design Principles

Be Simple

Be Concise

Be Consistent

Give permanent Feedback

Being friendly always works

2. Page Layout and Structure

2.1 Metrics

2.1.1 Ranges

2.2 Page General Structure

2.2.1 Without Context

2.2.2 With Context

2.3 Layout template or grid

2.3.1 Metrics

2.4 Popups and Dialogues

2.4.1 Types

3. Visual Design

3.1 Color

3.1.1 Color Palette

3.1.2 Color Layers (Structure)

3.1.3 Color Meaning (Popups)

3.2 Typography

3.2.1 Type Color

3.3 Iconography

4. UI Elements

4.1 Input Controls

4.1.1 Buttons

4.1.2 Checkboxes

4.1.3 Expand/collapse

4.1.4 Dropdown Menu

4.1.5 Date Pickers

4.1.6 Toggles

4.1.7 Text fields

4.1.8 Forms

4.1.9 Radio Buttons

4.2 Navigational Components

4.2.1 Network Indicator Activity

4.2.2 Menu Selector

4.3 Informational Components

4.3.1 Tool Tips

4.3.2 Dividers

4.3.3 Subheaders

4.3.4 Tables

 Next steps

It is important to know how to proceed after defining a style guide. Here are my suggestions:

Make it known to every member of the community. The first thing to do is ensure that the entire community knows of the existence of the new guidelines. This will help everyone be aware of how the application will look when the guidelines are applied. It also creates an atmosphere of unity and participation.

Establish when to start applying the guidelines. When a project begins with a UI Style guide, it is easy to know when to start using the guidelines, but when a project has already begun, is harder to determine this. Discuss this issue with all the people involved in applying the guide to the project, then decide if the guidelines will begin to be applied on a specific date, after a determined sprint, in parallel with the current development, etc.

Complete the UI Style Guide. Once the application is following the guidelines from the style guide, it is a good idea to add some snippets of code or create templates to prevent each developer wasting time with each use of the concepts covered in the style guide. Another possibility is to add comments or thoughts regarding conventions or consensus reached when applying the guidelines.

Maintaining a UI Style Guide

It frequently happens that designers make a UI Style Guide document and forget that it has to be updated once in a while. This is not an easy task (especially when it is recently defined), but it is not impossible to figure out how the situation can be improved to avoid obsolescence.

One good starting point might be finishing the UI style guide by adding more items to it, such as the two left in my initial proposal: Common features and Language. Other possible items to cover could be: design and development processes, interactions, user assistance, etc.

Once the style is applied to the web app, the result can be considered as the initial version. This version will be based on the guidelines made in the existing UI Style Guide, with its colors, structure, and principles. Over time, new features may appear and expand upon the initial version. These changes should respect the guidelines to maintain consistency and not hinder the user experience, since users become accustomed to what they know, and changes can cause dissatisfaction. Minor versions can bring changes at the visual level, like new combination of colors, or different sizes of typography or iconography, but always keep in mind that the structure and interactions shouldn’t be altered.

On the other hand, when new major versions occur, there can then be changes at a deeper level: structure, workflows, locations, etc. This will cause an inevitable modification to the user experience. Transformations can be gradual or radical, but should maintain a clear relationship to what was initially defined. One consideration to make is that a gradual transformation can be easier to handle than a radical one.  Remember that creating something completely new requires completely new guidelines.

Time’s up! - My experience

The experience was absolutely great!

I can’t believe that three months ago I was completely scared because this was unknown for me. The first three or four days I was lost and thinking that I would never adapt, of course I know these are common feelings when you enter a new community, but anyways, I felt confused.

The ramp-up stage was interesting and useful but kind of boring at the same time (another frequent feeling, I know!). I could not wait to get started with what I like: design, mockups, colors, element combinations and learning new things regarding UI design.

Once the UI Style Guide process started, I was happy doing what I like, learning and creating with people from another country. Almost everything was new for me; it was my first time in an open source project.

The whole work was hard, requiring trying too many different things, hours and hours of thinking, searching, and reading lots of concepts. There was also another complication: working at home. At the beginning it seemed impossible, but as the project progressed I could focus even more. I enjoyed the last three months a lot; I wish it had not ended so soon.

Lastly, I want to thank the OPW project for this great opportunity, for letting me know a big new world I didn’t know; it is highly recommended to participate in this project. I also want to thank the Evergreen Community for selecting me to create a UI Style Guide, and for the patience, support, and kindness.

[lima-julia-blog]

Time’s (almost) up!

The time I had to participate in this internship is coming to its end. As sometimes happens in projects, not everything we planned for is finished. The three main topics to approach are done; the stretch goals remain as future to-do items.

In this post I want to show one workflow performed by a user using Evergreen’s web staff client. You will see all the principles, visual design, and UI elements defined in the UI style guide applied to this interaction.

Screen 1

The first screen users see is the one that requires signing into the web application. By completing the form and clicking the “Sign In” button, the user will go to the home page, illustrated with a house icon. The home page will contain the most frequent actions shortcuts.

Screen 2

This post will demonstrate the “edit patron” workflow, which can be done in two ways. Users can access the patron searches through the shortcut on the home page or by opening the dropdown menu of “search” in the module bar. In this case, the second option was selected.

Notice that once the user is logged-in, a “user button” will appear in the right top. This button will allow the user to log out, switch between different accounts, or perform any other action specific to the user.

Screen 3

This screen will display a small search form that requires specific information (“Last Name” and/or “First Name”). One button performs the search, the second one clears the information introduced, and the last one extends the form, showing more options (“Username”, “Barcode”, ”Address”, etc).

Screen 4

Once the user performs the search, a table is displayed with all the results. The table is composed of a “table bar” which contains the table’s title, pagination, and a cog icon – by clicking it, a dropdown menu will show all the configuration options that can be applied to the table. Checkboxes in the table allow one to select all the results, to select one by one, or to perform multiple selection.

An interesting feature to note is the tips toggle in the blue bar (title/action bar). When clicking it, tooltips are activated in the workspace. This means that some tips will be shown when hovering over the UI elements, helping the user to know how to use each component.

Screen 5

Once you open a patron search result, you can perform a variety of actions related to that patron. In this example, we are selecting the “Edit” option. A large form is displayed.  To the right of the form is a table of contents exposing the sections of the form; it can be hidden by clicking the collapse icon. There is also a search form that will help the user to find a specific field easily. There are two radio buttons that will show only the required fields or only the optional fields.

Something that is very noticeable in this screen is the new tall bar. As all the actions in it (in the middle of the bar) are applied to a specific patron (Smith, Alexandra) we can say that are in that patron’s context. A context is understood as an entity with a given state to which a set of actions can be applied and, in consequence, modify its state. So, the new bar is called the “context bar”.

What happens when the user wants to go back to the table results or change the selected patron context? You can see there is an area near the right edge of the context bar that is intended to handle this. It is called the “Results manager”, and it allows the possibility of returning to the search results, going to the next or previous context (i.e. patron) one by one, or to the first or last one directly; and of course searching for a new context by returning to the previous UI.

In conclusion, by applying all the guidelines documented in the UI style guide for the Evergreen Project we believe that the intention of improving the user experience, the interaction, and style of the general web application was reached.

After three months of hard work and thinking, the main objectives were achieved. It is important to recall some of the advice I’ve said in previous posts:

Don’t forget who you are designing for.

Keep in permanent touch with your team.

Be open minded.

Do not stop learning.

And the most important thing: ENJOY IT!

Next post: Time’s (officially) up! :(

[lima-julia-blog]

Redefining guidelines II (colors)

There is a very important thing that designers can’t avoid when performing their work: colors.

Sometimes colors are the essence of a design. Other times they are what’s needed to understand a message completely, or maybe they are just a visual resource.Every design will be different; and, in consequence, the application of colorsvaries too.

There are a large number of variables when thinking about colors:

A color palette of predefined colors created for a brand.

Creating a new color palette from scratch.

Color-vision deficiencies (color-blindness).

Web Content Accessibility Guidelines (WCAG).

Color psychology.

User experience.

The user.

Web vs. mobile vs. desktop.

The number of information/UI elements.

Application of colors in designs

I want to focus on two ways of applying colors in a web app design, using as an example the Evergreen project in which I’m participating.

There are at least two concepts to follow when applying colors:

By hierarchy: establishing a certain amount of hierarchical layers driven by its visual importance. Each layer will have a different color. For example: “The lower layer is gray because it contains the less important information”.

By meaning: establishing that each color has a specific meaning, and should therefore be applied to elements that need to transmit an implicit message. For example, “orange: used to highlight”.

The initial idea for application of colors in the Evergreen web staff client was “colors give meaning to elements”. Here is a mockup applying this approach, where blue means information, green means “Evergreen”, orange is to highlight and gray to guide the user:

After working in my mockups using this approach to create guidelines for the UI style guide, I found that it has a number of problems:

When more and more elements arise in a single UI, it turns way too colorful, and that's unsightly. Personally I don't like having too many colors in the screen. Suddenly I found myself disliking my own designs because of this, which is bad, because if it happened to me it could happen to any designer out there.

A designer, following the color guidelines, could end up in a bad color combination.

 When there are too many elements in a UI, the colors lost their meaning. I can only see the colors' meanings because I know them in advance.

The color palette could get giant if we start adding more "meanings" to the UI. This will worsen the problems mentioned before.

On the other hand, defining colors by hierarchy will have the following issues:

Just by itself, it doesn't assure consistency among the UIs because the visual hierarchy depends on the designer criteria. This isn't good because the main objective of this project is to ensure visual consistency.

It could lead to unsightly and/or boring designs when too many elements are in the same layer (and close to each other) and have to share the same color tone.

After thinking a lot about this, I found a possible solution by using the second approach with some improvements. I think that establishing a fixed and well defined visual hierarchy using colors but only at a structural level should ensure consistency and aesthetics:

You might notice that there are lot of changes in the layout, which result from other guidelines being redefined,  but please focus on the colors only.

As mentioned, colors are applied to logical layers that establish the visual importance of each element, guiding the users' eyes to see what is more relevant in the UI. In this particular case, this is the best solution or choice that can be taken.

It is important to establish that the layers have a limit. Depending on the situation, you can define a color to every component of the UI, continue adding new hierarchical layers, or whatever the case requires. The limit in Evergreen’s user interface will be the workspace, where all the UI elements and texts are located.

In conclusion, there are many ways to apply color to designs. Different variables and conditions will guide you to the best solution. Try all the options you can, discuss with your team, and take into account the limitations you may have.

Next post: Time's (almost) up!

[lima-julia-blog]

UI Elements

UI elements are all the various objects on the screen that allows users to introduce and modify data, as well as those components that give specific feedback to him or her. Once the general UI is defined – or almost defined – it’s time to start documenting UI elements.

One wayto do it can be listing all the elements and defining each specification. However, one interesting piece of advice I would offer is to divide them into different categories according to their functionality or purpose. This way it can be both easier to read and more organized.

There is a great variety of possible elements a UI can contain.  A tentative list of them might include:

Tables

Buttons

Forms

Accordions

Tooltips

Progress Bars

Notifications

Image Carousels

Sliders

Tags

Pagination

Breadcrumbs

Search Fields

Date and time pickers

Text Fields

Toggles

Dropdown Menus

List boxes

Radio buttons

Checkboxes

Dividers

Lists

Sliders

Switchers

And many more…

The name of each one can vary depending on the situation. Many components are known with a particular name; you can continue with the conventional name or change it according to the UI style guide + communication tone + need.

As mentioned before, I suggest dividing them by purpose. There are some elements that are related to input data, others to information, feedback, and content. So, a possible way to separate them could be:

Input controls: These elements involve data input, modifications, and calls to action.

Navigational Components: Elements that help the user to locate and understand the path between the different user interfaces of the application.

Informational Components: Enable the organization and clarity of the information provided on the screen.

Containers: Elements that can contain elements within them and help the optimization of the space in the user interface.

How are elements defined?

One of the most important things to have in mind when defining each element is to determine every detail to ensure designers or developers can understand and apply the guidelines without any doubts or confusion.

Such items may include:

Definition: Every element should be explained. Giving its purpose and the way it is used will help designers and/or developers to know when to apply an element and when not to.

Metrics: Consistency is achieved, partly, by respecting the element’s measurements. Margins, width, height, distance between components (if it is composed of different objects), text size, etc.

Usage: Elements have a purpose. Determine precisely when using an element will facilitate the implementation of that particular element.

Types: An element can take different styles.  A single object type with different style allows variety in designs. Note: Each type should be explained, including specific metrics, usage, state,element combinations and locations.

States: A single element can vary its behavior. Depending the actions users can perform on an element, it can have different states (styles) such as: default, pressed, clicked, on hovered over, etc.

Combination: An element can be combined with others; UI elements can work alone or together. Metrics and usages for each unique situation have to be defined. 

Remember: Defining something in a UI style guide doesn’t mean that style cannot have future tweaks or definite changes.

 Next post: Redefining guidelines II

[lima-julia-blog]

Redefining Guidelines

It isn’t easy to define guidelines. This is because it is necessary to consider all the possibilities that may arise in the future. Keep in mind that a UI style should consider every possible new feature, change or whatever a designer/developer could add to the web app. It should have an internal balance in order to be restrictive enough to ensure consistency but not so restrictive that you inhibit new possibilities.

It is important to always return to what you have done, because when someone is completely focused on the work, there are many details that escapes his or her attention. That is why the designer who is defining the UI style guide should continually solicit the opinions of the users and the other partners in the project/company.

Remember to always:

Keep in touch with the user. The best way to create a perfect UI style guide is to know exactly who the user is, what they want, what their expectations are, and how to satisfy them. 

Keep in touch with the team. Designers need to be in constant contact with developers. Guidelines are going to be defined by designers, but developers will be the real interpreters who apply and make sense of the rules.

A style guide is not going to be written once. Designers need to research, design, try out and think a lot to get a rough idea of the final guidelines; this is called “iteration”. Iteration is the act of repeating a process with the aim of approaching a desired goal, target, or result. Each repetition of the process is also called an "iteration", and the results of one iteration are used as the starting point for the next iteration.

Evergreen´s UI style guide - iteration process:

This is the first mockup made as part of the style guide defining process:

Contrast that with the current mockup of how the user interface might look:

We can notice that there are a lot of changes:

Colors: There are new colors. The shades of the colors are different. 

Typography: Changed from Helvetica Neue to Roboto Normal 400 font.

Layout: The different bars were transformed to conceptual bars.

Buttons: The gradient is subtle in a different green.

Screen size: Minimum resolution was changed from 800x600 to 1366x768.

And more…

There may be times you can define guidelines from the beginning and they will be in the final design, but there are many times in which you need to continue with other items and then return to previous decisions later on. This often results in seeing things from another perspective, because once we focus our attention on a single activity, we can lose sight of many details.

Don´t be afraid of changing everything from scratch if necessary. Defining a style guide takes time.

Do not rush. We always have the opportunity to go back and rethink things.

Be open-minded. Other opinions are always welcome and can surprise you.

Do not stop learning. All projects are different.

Next post: UI Elements

[lima-julia-blog]

Visual Design

This portion of a UI style guide is often defined when the final style is completely decided. This means that once all the UI elements and the different parts of the structure are finished and the team agrees, the person in charge of writing the guidelines is able to make the documentation. That said, visual design isn't always written when the final mockups and decisions are made. Sometimes one of the first guidelines is the definition of color and fonts based in the brand look and feel. In other cases the design team starts designing some mockups and there´s a point in which everyone agrees on a certain color palette. So, the moment in which the visual design portion of a UI style guide is decided will depend on the team decisions, previous definitions, or waiting until everything is designed.

Colors

There are some good items to apply to this area.

Color list. By listing all the colors used, designers and/or developers will know which colors they may use. Just naming the colors may cause inconsistency because they wouldn't know which hue each color should be. Note: Remember to always give RGB or hex values for each color.

Applying names to colors. Depending on the company's messages, tone designers may label each color based on a concept that each color represents. For example, “insecure purple” is a color used only in question alerts, or applied to any message that needs an answer to continue with its purpose. Note: This type of content makes the guidelines funnier and lighter to read for the person is using it.

Color Scale. The style guide can contain a color scale, from dark colors to bright colors – or the other way around – to show the whole variety of colors that the UI will use. This will give a wide notion of the combination of colors. Note: It is necessary to provide a detailed view of each color to know which hue and values a specific color has.

Detailed Color palette. Presenting a detailed view of each color, including a sample and RGB or hex values, is a great way to express the complete palette. Designers and developers will know the exact color without any doubts.

It is important to keep in mind that giving only the color information would be incomplete without remembering to add the usage of each color. This is relevant because anyone could use any color in any situation. Always define when to use a color.

As an example, let's consider some colors from Evergreen´s color palette:

Evergreen's Green: The main color of the project is green. As this is the color of the logo, it will be called Evergreen´s Green. This color will be used in the main menu.

Prominent Orange: This orange is used to highlight some UI elements like buttons or titles.

Wrong Red: This red is used to inform the user that something is wrong.

Fonts

The typography that the UI uses will depend on the brand, the information being presented, and the project itself. This means that the brand style will determine if it is a serif font or a font without serif, if there is going to be only one used (or more), and which. Thechoice of font for a UI should be appropriate for the amount of content being presented. If the UI shows longer texts, the font must be clean and legible; if the UI displays small phrases or single words, the possibility ofusing calligraphic or ornament fonts becomes open. Lastly, if it is an open source project, the suggested typographyshould be freely licensed to prevent distribution issues of the resulting software.

It is useful to show a sample of the typography - how capital and lower case letters, numbers and special characters will look. The guide should also express the colors, size, different weights, and the cases when to use these variations.

Note: Take into account the different ranges of screen size/resolution; different type sizes are sometimes benefitial in different screen resolutions.

Iconography

Icons are an illustrative way to communicate a concept. Sometimes they are used as a shortcut, other times as an additional reinforcement.

Some icons are tailor made to a specific UI, some icons are from public sets. If the iconography used is an icon set found on the Internet, linking the site for demonstration is enough; if it is a singular icon set made for the project, the UI style guide should show a sample of it.

Metrics, colors, usage, types and every explanation needed will be well defined in the guidelines.

Next post: Redefining guidelines

[lima-julia-blog]

Defining Design Principles

Design principles are “rules” that guide developers or designers (or anyone) to create a consistent UI. These principles are written based on design patterns, and this means that design patterns will determine the design principles that have to be followed to create any new content in Evergreen´s web client.

Design principles don´t need to be too extensive, just two or three short sentences should be enough to explain the concept. These principles describe the essence of the product, so the way they are expressed (serious, friendly, etc)should reflect the ptroject´s real quality. A useful resource is to show through images examples of the do´s and don´ts, as this will help those reading it to understand what is allowed and what is not. The quantity of design principles depends on the project’s philosophy and needs.

Let´s look at an initial sketch of Evergreen´s principles:

Be Simple

Simplicity of tasks, white spaces and an intuitive navigation are the perfect combination that users expect from a web application. Reducing extra effort avoids frustration and early abandonment. 

Don´t: UIs become cluttered and complex when too much data is displayed; it can produce confusion and can make the application more difficult to learn.

Do: Design Patterns as Progressive and Staged Disclosure can be applied. Focus is always on reducing user effort.

Be concise

Users need their tasks to be done quickly and effectively when needed. Give brief and precise instructions so users do not waste time completing unnecessary information or thinking too much about how to proceed.

Don´t: The user is discouraged when seeing that too much information must be completed.

Do: Account Registration Design Pattern can be applied. The less information required, the more satisfying the action will be.

Be consistent

Users feel lost when everything changes as they move around a web application. Visual consistency makes UIs easier to use, gives an overall impression of professionalism and reliability, and it reduces the slope of the UI learning curve, which is one of the main “enemies” of the user experience.

Don´t: Changes between screens of the same application are evidence of missing guidelines.

Do: Conventions are made to be followed. Preset guidelines ensure uniformity. The usability heuristic “consistency and standards” explains this.

Give permanent feedback

Feedback is an essential property of a usable product, and necessary to avoid confused or frustrated users. It is critical for the user to naturally flow through the UI without wondering what is happening. Notify the user that all actions he or she is performing are being processed, made, or verified at all times (as necessary).

Don´t: Users need to have control over the application. If it doesn´t respond as expected, they get impatient quickly and can end up frustrated, or simply quiet.

Do: A spinner can be an effective solution to avoid dissatisfaction among users. Suggestion: use visibility of system status (usability heuristic) to prevent  these kinds of unresponsiveness issues.

Being friendly always works

Language is the most important way to communicate between people, but communication channels and codes vary a lot when a system is involved. Show that systems are developed by people; avoid technical words or codes and be gentle in the way things are stated.

Don´t: People who are not involved in the world of coding do not understand technical language commonly used by developers.

Do: Using simple, understandable, and kind language will be welcomed and appreciated by the user. Take into account the usability heuristic called match between system and the real world'.

In conclusion, we can say that Evergreen´s design principles have a friendly tone and are completely focused on users, trying to simplify and make their tasks more bearable. Showing images as examples of what to do and what not to do clarifies much more than mere words.

Next post: Visual Design

[lima-julia-blog]

Staged Disclosure applied to Patron Search

Applying a design pattern to a current task will allow us to both implement new design proposals as improvements in the usability of the web application. This kind of processes are the previous stages to define the “Design Principles” that are going to orient developers to apply the guidelines defined in the future UI style guide.

Current “Patron Search” looks like:

The “Patron search” UI shows an unnecessary amount of features. Therefore this UI becomes very cluttered and complex which can produce confusion to the users and can make the application more difficult to learn, ending up in degradation of the user experience.

There is an entire disabled menu shown to the user. This means that the UI is showing the user features that may be available in the future. A better approach would be to show these features when they are available in order to maintain the UI simple and to keep the user focused on the main task, which is search for a patron.

There is an empty space at the left of the search patron UI. This is actually saving space for the patron information but at this point the UI appears to be left aligned, causing a loss of visual consistency. A better approach would be to show the patron information on demand, this is to say, when needed for the user.

For UI problems of this kind, where it's wanted a very powerful interface, with many features, but it's also wanted to keep the interface as simple as possible, one of the best approaches is to apply the Staged Disclosure design pattern.

This design pattern is useful when you can divide a task into distinct steps that have little interaction. It requires a thorough task analysis to understand which options are used together and which are better thought of as separate stages. The more features you can defer, the simpler your design, but if you divide the task into too many steps, users get bogged down by excess navigation. Staged disclosure is a variant of the progressive disclosure design pattern, in which users step through a linear sequence of options, with a subset displayed at each step.

Patron search can be divided into three steps:

Search for patron: The only UI element that should be displayed on the screen will be the form. User will perform the search.

Results: A table will show all the results. User will choose a Patron.

Patron profile page: The patron profile and a sub menu will be displayed. User will work with the patron´s information.

This proposal would look like this:

Here we can find new redesigned elements:

A User/Library button: This button will drop down the options of “change account” and “log out”, tasks that are completely related to user´s account.

Title: Each section should have a title. It has an orange background.

Orange button: This shows that buttons are not only green.

Sub menu: Similar to the main menu but with its colors inverted.

Patron profile: Shown as a table.

Next post: "Defining Design Principles"

[lima-julia-blog]

Where to start? (UI Style Guide)

As there is already a previous layout design of the Evergreen´s web application, the first decision made is to analyze it and decide which parts should be kept and which parts might be discarded.

This is the current “sign in” UI:

The first observation that can be made is that Evergreen´s logo is not there. On the second screen – once you are logged in - the logo will be shown in a big size. Although frequent users know where they are, new users will not. The logo will guarantee anyone knows that this specific set of user interfaces belongs to Evergreen.

After a thorough analysis of the whole app, it was concluded that the general layout template or structure can be maintained. The only region that will be added is the one containing the Evergreen´s logo at the top of the screen above the main menu. This structure is comprised of a main menu and three main columns. It is a good choice to add a footer with a brief sentence and the current year to show that the app is updated.

When beginning to design a style guide, having something already developed implies that current users are used to current pages. Big changes may cause discomfort because users will have to adapt to it again. So, maintaining some colors, element locations and structure but changing some details will be the next step.

This is my initial proposal:

The gradient background of the current menu has been transferred to the new design button.

Background color of the new main menu will be green as the real color of the logo, trying to refresh its look and feel.

Three columns are still structuring the new design.

footer referring to Evergreen is open source, the license, version and year.

A form aligned at the center of the page.

Orange pointing the field that has to be completed first.

As a conclusion and as an initial sketch of the page general structure, it would look like:

Static header: Is important for the project to locate its logo permanently within the web application so that users know where they are even though it is a tool often used. This section will be always located at the very top of the page. Evegreen´s logo will be located on the left side. It also shows a user/library button that will allow the user to log out, switch between different accounts, or any similar action, located on the right side of this header.

Sections bar: All the actions that can be performed across the web application are divided and grouped into sections. Those sections are located in this bar present in all the web app screens. By clicking the sections a dropdown menu will be displayed. It can contain as many sections as needed.

Action region: The information should be presented consistently in all the different screens of the web application, that´s why content (text, form, list, table, etc) will be shown in this limited area. Margins and grids must be respected.

Briefly informative footer: Being an open source software project involves another type of perception regarding the product / service provided. A brief description about the license used and the current year to show that the software updated will be fine.

Next post: "Staged Disclosure applied to Patron Search".

[lima-julia-blog]

Ramp-up Stage for a new UX Designer in a Company

How do designers integrate into a software company? What should they ask? Where to find the required information?

Being new to a company is not  something nice,  is like people talk in a different language and although others have warned you it wouldn´t be easy everything falls apart in a second. But you must not despair. The ramp-up stage is not funny but is absolutely necessary. These are the first things UX designers (and every proffesional) should do when was hired in a company.

Ramp-up is a phase in which you are supposed to understand the product and the team and also the state of the art. This will provide you valuable information and will help you understand how are you giong to proceed and managed within the enterprise.

The product

Whatever you´re going to design needs to be well thought from the beginning. The most important ones are:

*History: Is good to know where it comes from and where it goes to. History will give you a broad overview of how it started and was brewing the product we know today.

*Purpose: Everyone need to be focus in the same objective to have a successful product.

*Features: They have a reason and a specific intention. Be sure to understand why they are there,  what they do, the flows throughout the software, what need satisfies, etc.

*Users: The most important thing designer should have in mind all the time, users are the objective of a UX designer, designs are for them. Also something relevant is how they use the software, make some research and testing. (You can see more information about how to know your target here).

The team

Not all the teams are the same. You are going to learn new ways to perform tasks, different time cycles, processes, methologies and communication between colleagues.

Be familiar with the role of each professional within the company in general. Is the company split into areas (development, testing, desining, selling)? Is there any IRC channel or mailing list to join? How many companies and people is involved in the project? If is an open source project, how many people are collaborating?

State of the art

It is also important to know the competition. Are there other projects similar to ours? Which are the differences? Do they have the same features? What do users think of the other projects? How is the branding process?

Note the differences, advantages and disadvantages to have a general idea of where the company is standing.

Where to find the information

At the company´s documentation, but mostly in people. Documentation is not always easy to understand because it is written by developers or by people who belong to the specific area in which you are entering and use concepts that are unfamiliar to designers.

Try to join every training, webinar or meeting the company offers. Talk to everyone you can. The only way to know in depth people and work environment is wondering and worrying about understanding everything.

Don´t be afraid of asking, people will help you, after all you are going to be part of the same team and go toward the same objective. Focus in developers, there is a direct relationship between UX designers and developers, try to talk with them and figure out which are their work processes, how are they used to receive information (long or short text, wireframes)? Be sure to reach an agreement, accept their point of view and give your opinion too.

[lima-julia-blog]

Progressive disclosure design pattern

* This content was produced as a contribution for Evergreen as part of the Outreach Program for Women.

* I will refer to a UI that shows an unnecessary amount of features. Therefore this UI becomes very cluttered and complex which can produce confusion to the users and can make the application more difficult to learn, ending up in degradation of the user experience. For better understanding here is a screenshot:

UI analysis

Regarding the points highlighted in the image, it is clear that there is unnecessary complexity added to the UI:

Disabled features (1): There is an entire disable menu showed to the user. This means that the UI is showing the user features that may be available in the future. A better approach would be to show this features when they are available in order to maintain the UI simple and to keep the user focused on the main task which is search for a patron.

Empty space (2): There is an empty space at the left of the search patron UI. This is actually saving space for the patron information but at this point the UI appears to be left aligned causing the loss of visual consistency. A better approach would be to show the patron information on demand, this is to say, when needed for the user.

Progressive disclosure design pattern

For UI problems of this kind, where it's wanted a very powerful interface, with many features, but it's also wanted to keep the interface as simple as possible, one of the best approaches is to apply the progressive disclosure design pattern.

Progressive disclosure is an interaction design technique often used in human computer interaction to help maintain the focus of a user's attention by reducing clutter, confusion, and cognitive workload. This improves usability by presenting only the minimum data required for the task at hand by sequencing information and actions across several steps in order to reduce feelings of being overwhelmed for the user. By disclosing information progressively, you reveal only the essentials and help the user manage the complexity of feature-rich applications. Progressive disclosure follows the typical notion of moving from “abstract to specific”; only it may mean sequencing interactions and not necessarily level of detail (information). In other words, progressive disclosure is not just about displaying abstract then specific information, but rather about 'ramping up' the user from simple to more complex actions.

The great designer Jakob Nielsen describes the progressive disclosure pattern with two simple steps:

Initially, show users only a few of the most important options.

Offer a larger set of specialized options upon request. Disclose these secondary features only if a user asks for them, meaning that most users can proceed with their tasks without worrying about this added complexity.

In its most formal definition, progressive disclosure means “to move complex and less frequently used options out of the main user interface and into secondary screens”.

My proposal

There are several ways to apply the progresive disclousure pattern in a UI. Based on the actual UI I consider that the best approach is to use the dynamically-growing UI technique. By applying this approach the UI will progressive discover the features to the user by expanding itself. This approach has the following benefits:

The users can form a correct mental model of the task quickly and easy.

There are none of the awkward context switches that separate screens impose.

Since the UI is kept together on one page, the user can very easily go back and change their mind about earlier choices;

The users immediately see the effect on subsequent steps.

Below I show an image with my proposed designs:

This image shows a general idea about how the progressive disclousure pattern could be applied in the UI. I am not considering a full UI design with all the possible options or cases in it.

Additional comments

This kind of low level interaction design patterns applied to specific but central features are often specified in UI Style Guides. This highlights again the importance of having a well defined complete UI Style Guide for an organization.

[lima-julia-blog]

System Feedback Loops

In this post I will talk about System Feedback Loops. All of this content was produced as a contribution for Evergreen as part of the Outreach Program for Women.

What are feedback loops?

The premise of a feedback loop is simple: Provide users with information about the result of their actions over the UI in real time. This information can be vital to the users because they can accommodate their future actions based on the feedback of actual actions, pushing them toward better behaviors.

Actually, feedback loops are not only a user experience design concept. They are a natural human process studied for decades and used in many fields. There are many natural feedback loops. They reveal to people whether they are making good or bad choices, and people learn from them. If someone eats something bad, they get sick. If they eat something good, it is delicious. If a person is nice to someone, and that someone responds in kind, the person feels good. If someone damages their body, it hurts. The brain has systems of reward and punishment that support basic survival.

In user interface design, feedback loops consist of a few simple steps:

A user takes an action over the UI

The action has one or more effects over different actors (like system itself, other users, etc)

The important effects of this action are presented back to the user in the UI

This loop is repeated regularly

Different actors who could produce feedback

A user performs an action over a UI, and that single action could produce different effects over different actors, just like:

The system itself: For example, when a user clicks a button to save his work this action has a direct effect over the system itself. Then, the feedback showing the action's result should be given from the system to the user, closing the loop (user→system→user). This kind of feedback loops are also known as “system feedback loops”.

Another users: For example, when user “A” post content on a social network, this action has an effect over other users who will comment, share or like on that post, giving feedback to the user “A” and therefore closing the loop. Everything happens through the system, but the feedback is given from a user “B” to the user “A” (userA→system→userB→system→userA). This kind of feedback loops are also known as “social feedback loops”.

The physical world: For example, given a UI which controls a robot, a click on a button could be seen on a robot movement. The feedback is given from the physical world to the user, closing the loop (user→system→physiscal world→user). This kind of feedback loops are also known as “physiscal feedback loops”.

Note: In this post I am only refering to system feedback loops (user→system→user).

The importance of system feedback loops

Feedback is an essential property of a usable product and necessary to avoid confused or frustrated users; it's critical for the user to naturally “flow” through the UI. For example, let’s say a user filled out a form in a web UI and hit submit. Nothing happens. The user hit it again. Nothing happens. The user proceeds to hit it multiple times and look around for some sort of message, but finds nothing. Maybe the page was just loading but there was no feedback to the user pointing that out, like a simple spinner. So now the user thinks that the application doesn’t work and gets frustrated. In this case a simple spinner could’ve corrected the user behavior by indicating him to wait for the page to load instead of keep hitting the submit button. The system feedback loop will guide a user pushing him toward better behaviors.

This concept is so important in design that great designers and organizations have taken it and converted it in a design principle:

Don Norman’s design principles:

Taken from his book: Preece, J., Rogers, Y., Sharp, H. (2002), Interaction Design: Beyond Human-Computer Interaction, New York: Wiley, p.21

You can see the principles here

Android design principles:

The “Sprinkle encouragement” principle.

You can see the principles here

Apple OS X design principles:

The “Feedback and Communication” principle.

You can see the principles here

Human factors standards, like MIL-STD 1472, require feedback and specify when and what types should be used.

How good system's feedback should be?

On time: Nor after, nor much before the action's effect. The feedback must not confuse the user, quite the opposite it must clarify things. In such way it must be seen by the user as a reaction of his action.

On target: It has two meanings. It means spatially associated with whatever input the user made, and it means wherever the user is attending. Usually these are the same thing, since users tend to attend to wherever they made their last input. However, when response times are slow, the user may have shifted attention elsewhere. In this case you may need two feedback signals, each with its own level of proportionality.

Proportional: The feedback must be proportion to the user action. You generally do not want something obtrusive like a message box to tell the user everything worked fine. However the absence or loss of a signal or visual indication is generally not acceptable feedback