Crystal Juarez joined the Liferay North American Product Design team for a three month internship. The design internship’s purpose is to help sharpen early career designers’ skills, offer them real-world experience and provide value to our team. Crystal previously worked at Liferay on our recruiting team for a brief period, but discovered a passion for design and completed the General Assembly UX Design Immersive program. We asked Crystal some questions about her internship experience at Liferay.

What did you like most about the experience?

Moments of learning something new in Figma were really rewarding! I would tell friends and former classmates because I was so excited. Along with that, I knew I had a lot to learn. This internship paired me with the type of manager (shout out Ryan) that sat with me to map out what and how to learn it.

What did you find most surprising?

I had just finished school, but I feel like I was introduced to a whole new world. There is more to design than I had originally thought. There is so much you can learn and so many different directions you can go in. As conversations took place and I heard more about all things related to design — different places designers got inspo from, watching youtube videos, etc — it was so interesting and eye opening to see everything that is design.

What was the most difficult part of the internship?

Reminding myself that I am still learning and keep a growth mindset. “I don’t know this yet and I am going to learn” instead of getting frustrated and self critical. That, along with the pandemic hitting and events that occurred due to the political climate we’re living in were all things that made my experience unique. I wouldn’t say these things made my experience difficult, but there’s just no way you can think of this period of time and not mention these events. Everything going on reminded me that the reality is, some things are out of your control (help where you can, but don’t get lost in it) and ultimately, you still need to show up and put in work.

What kind of tasks did you do?

When I was not working on my research project, I helped Designers with:

• Wireframes for a consulting project that were presented to stakeholders
• Our insurance solution
• Our Figma component library created for Designers to customize for their projects

Tell us about your Internship Project.

My internship project revolved around user research here at Liferay. I went through the entire design process from conducting research to creating mockups for a prototype of an app to help designers decide what research methods to use.

What were the results?

User research at Liferay is a growing department and we have areas of opportunity where we can implement it more strategically. I’m excited to see how user research grows at Liferay and happy to have contributed to it.

What was the biggest challenge during the project?

Deciding on what problem to work on and how to address it. I remember telling my mentor (shout out to Chris!) that I had gotten lost in the sauce. Thankfully he was there to dig me out and help me relish in the process of it all (get it, get it?).

Can we see any of the deliverables?

Was there anything you learned here that you didn’t in school?

Where do I start? School was an overview of research and design. Here at Liferay, I learned everything I know now on Figma, about the software world, working with Product Management, and a lot more. Since day one I was exposed to new ideas, which prompted me to do research and talk to my team. Through conversations with them, I was able to see how other Designers think. I can say I am more integrated in the design community and overall a lot more knowledgeable than I was when I first began.

What piece of advice would you give design applicants looking to work at Liferay?

As cliché as this sounds, my advice is to simply be yourself. Liferay has a unique culture with people of all backgrounds and personalities. If it’s the right fit, it’ll happen. On a more general note, get experience, build your network and reach out to other designers. I’ve found that designers here at Liferay, and in general, are more than willing to help.

How can we get in touch with you or see more of your work?

Add me on LinkedIn

Follow me on Dribbble

Send me an email!

Originally published at https://liferay.design.

3 Months at Liferay was originally published in Liferay Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’ve followed me for any length of time on Twitter, you’ve probably seen multiple professions of love for Gatsby. When I saw they were hosting a one-day, single-track conference about 20 miles (only 2 hours in LA traffic!) from my house, I couldn’t not attend.

Liferay.Design has been running on Gatsby since early 2018, and despite not having a “real” dedicated web developer, we’ve managed to build a fairly large site including (but not limited to):

1. Multiple “post” types — blogs (with tagging functionality), event listings and recaps, job listings, team profiles
2. Multiple documentation-style sites — Lexicon (our design system), Blueprints (our brand style guidelines — with basic auth capability), and our department handbook
3. Landing pages — for our annual reports and most recently for our upcoming Design Week
4. Integrating 3rd Party Data sources — like Mailchimp for our Newsletter archive and Google Docs for our career paths and job descriptions
5. More stuff, probably

This is largely in part thanks to Gatsby’s incredible ecosystem — they really hit the sweet spot with amazing technology, thorough docs and examples, and a welcoming, helpful community.

Anyway, if you’re still with me and haven’t lost your lunch over my fawning yet — you’ve more than earned a decent event recap.

The Venue

Convene has a great space — big enough where you can fit 200+ people, but not so big where you got lost or feel isolated when you stand by yourself in a corner.

Something interesting that I had never seen before is mouthwash in a soap dispenser — despite Linda’s earlier warning about this, I still pumped a healthy serving of Scope into my hands.

The Talks

Note — there is a complete recording of everything on YouTube, it looks like they’ll be splitting it up into individual videos, but at the time of this posting haven’t gotten to it.

Opening Keynote — Kyle Matthews

Starts ~4:16

Kyle began with Gatsby’s origin story, and brought that into where they are now, shared about the new release of Gatsby Cloud and then talked about the future of Gatsby.

Particularly exciting was the focus on #nocode and live demo of blocks-ui.

He concluded with awesome shoutouts, recognizing Rachel Cherry, Nick DeJesus, Khaled Garbaya, and the 25 other Gatsbytes (I learned from Shane Thomas the official way to refer to people who work at Gatsby).

Gatsby Cloud: What’s New and What’s Coming — Dustin Schau

Starts at ~26:37

Dustin started off his talk with a bold statement:

We plan to make Gatsby the definitive way to build for the web.

He then put his money where his mouth was by giving a live demo improving the accessibility of his wedding website and showed off the Gatsby using Contentful as a CMS deployed with Gatsby Cloud.

What separates the fastest Gatsby sites from everybody else — Grant Glidewell

Starts at ~51:06

Gatsby is insanely fast out of the box (OOTB for you acronym lovers) — but Grant shared a couple extras that help make it even faster that will help you get the coveted Lighthouse 💯 fireworks gif (Note that Grant pronounced ‘gif’ correctly).

The takeaways for me — use Gatsby Image and Link. These might seem obvious, but as Grant pointed out, when you’re just getting started in a new framework it’s very easy to miss these things. Especially since Graphql queries for images can be complex. Thankfully they do provide a lot of examples and fragments.

How Tinder creates Wordpress blogs in React instead of PHP — Kyle Boss

Starts at ~1:43:20

Kyle Boss (no relation to Wes) gave a thoroughly entertaining and informative introduction to how Wordpress and Gatsby work together.

It was really cool to learn about how Gatsby really empowered Tinder’s teams by allowing them to focus on what they do best. Allowing developers and content creators to use the tools they love — and also have a high quality user experience as the end result.

Highly Dynamic WordPress Sites with Gatsby — Zac Gordon

Starts at ~2:10:10

This being the second consecutive WP + Gatsby talk, I’m beginning to wonder why I never looked more deeply at Wordpress. Zac’s presentation made it seem very straightforward to connect the two.

Comments and forms are a challenge in the JAMstack — Zac briefly went through three approaches:

1. Native — use OOTB features to trigger builds when things like comment forms are submitted.
2. SaaS — pay for a solution, Commento was very interesting!
3. Custom — a lot of ways to do this, one approach is to create a custom form, have data sent “somewhere”, moderate somewhere else (Slack?), then trigger a new build in Netlify or Gatsby Cloud. Easy peasy.

Sell Things Fast with Gatsby and Shopify — Trevor Harmon

Starts at ~2:30:20

I definitely highlighted this session before coming to the conference, we’ve been tinkering around with the idea of liferay.design/store and I really wanted to see what Trevor’s approach was.

Shopify and Gatsby seem to be a great match — there’s a gatsby-source-shopify plugin, so you can access all your store data and do things like create product pages fairly easily. There’s also a plugin that makes the checkout experience easier to develop.

Plus, the fact that Gatsby open-sourced their store code means you’ve got a great place to go see how they did it.

Smoothly inclusive: React component library documentation with Gatsby and MDX — Kathleen McMahon

Starts at ~2:56:11 — Slides available on Kathleen’s site

Kathleen’s talk was also one I had metaphorically circled, as we’re using the same stack for our various documentation sites ( Lexicon, Blueprints, Handbook), and I was excited to see what lessons I could take from the O’Reilly team and apply for our context.

I loved that she started with their goal of making documentation more inclusive — in terms of structure as well as for authors — the parallels between our organizations are starting to get eery.

Her demo of their system using react-live was very cool and I’m sure something that is the envy of design systems everywhere.

Lunch

The second most important meal of the day — the spread was amazing and healthy. The butternut squash soup and tri-tip salad were :chefs-kiss:.

Unconference Sessions

There were a number of great topics on the board for the Unconference portion of the day — accessibility, testing, ecommerce to name a few — I spent the first session discussing what makes websites beautiful with Lennart and Shannon and others.

It was really cool meeting LekoArts in person (he was the one who merged my request for adding liferay.design to Gatsby’s showcase). I am a little embarrassed to say I didn’t realize who Shannon was at the moment, so I missed out on the chance to meet her.

The Gatsby team is still working on making notes from all these sessions available, I’ll continue to add to this list as I find them — comments welcome!

Gatsby in East Africa — Gatare Libère

Starts at ~5:56:30

This might have been my favorite session, unfortunately Gatare couldn’t join in person due to Visa issues (so much for “land of the free”) — but the video was great.

He shared about the status of Gatsby in East Africa, and how he got started using Gatsby. It was a great testament to Gatsby’s community marketing efforts. Much like myself, Gatare loves swag hunting — so after finishing Hacktoberfest, he saw that Gatsby gives swag to show their appreciation for open source contributions.

He listened to the Syntax.fm episode on Gatsby vs Next (shoutout @wesbos and @stolinski!) and was sold.

All in all it was really cool to hear about the positive impact that open source projects like Gatsby can have across the globe.

Empowered Workflows with Gatsby.js — Josh Comeau

Starts at ~6:11:22 — Slides available at gatsby-days-josh-talk.netlify.com

My connection with Josh started during his introduction when Linda said he was a cat person. It deepened when he went explained why “content is more than just copy” and how we can use the mental models and technology of reusable components and share them with people who aren’t full-time web developers.

His talk was particularly exciting for me, because we’re actually doing this at Liferay with our new site building features! It’s not often that companies building software for large enterprises get to be working on the same “bleeding edge” as cool startups like Gatsby 😊.

Teaching Web Development to Beginners with Gatsby.js — Daniel Kim

Starts at ~6:52:56

This was Daniel’s first ever tech talk — so I guess we have to cut him a little slack for the mom bashing, but never do it again Daniel! PSA — being a mom is really hard, I only know secondhand, but lets not bash moms, they’re great.

Daniel did a great job explaining the myriad of difficulties surrounding teaching people new technology and the advantages of starting with a framework like Gatsby. Because you get so much OOTB with Gatsby, a simple file structure, hot-reloading, routing, and simple deployments — it gives people a head start so they can get quick wins which builds confidence and makes learning more fun.

TL;DR for Accessible Components, Yuraima Estevez

Starts at ~6:48:42 — Slides available at tldr-a11y.yuraima.com

Even though it was the last talk of the day, I was really excited to learn about how we can improve the accessibility in our components — and Yuraima delivered!

She gave three easy steps:

1. Write semantic HTML
2. Use ARIA attributes
3. Ensure keyboard navigation

Another huge takeaway she gave was that semantic HTML is accessible by default, so we can get so much of this stuff for free, as long as we don’t do silly things like turn links into buttons.

Overall

Gatsby knocked this Day out of the park. Everyone had a great time and learned a lot! Not only did the Gatsby team do a great job on the macro level, I really appreciated their attention to detail and how accessible they made the conference for everyone. From scholarships, to live captions (shoutout to Linsday Stoker for doing a great job on that!) and ASL translators, it was great to see them backing up all the accessibility talk with action.

Now, if you’ll excuse me I need to get started on fixing some of the accessibility issues on liferay.design 😬.

Originally published at https://liferay.design.

Gatsby Days LA: A Love Story was originally published in Liferay Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

How Liferay Analytics Cloud designers prepared for a second year design leap

User: Click, click *long pause* click? click?

Me: Anxiety level = Maximum

I wish I had more time to finish this feature.

Ugh the requirements weren’t comprehensive enough.

I thought QA, ran through it with no issues…

We didn’t test this?!

Product teams are almost always constrained by tight timelines and ambiguous requirements. It’s a balancing act that often results in suboptimal delivery with mounds of design debt.

In our case, the segment criteria builder feature in Liferay Analytics Cloud’s MVP release stood out above the rest. This was the result of lofty release ambitions meets back-against-the-wall scope cuts. Our most powerful feature lacked a clear purpose and had major usability flaws.

Segmentation

A quick search of “importance of segmentation” tells us that reaching consumers with targeted messaging is critical to success in this highly personalized age of digital transformation.

Segmenting, at its most basic, is the separation of a group of customers with different needs into subgroups of customers with similar needs and preferences. By doing this, a company can better tailor and target its products and services to meet each segment’s needs.

— from What You Need to Know About Segmentation by Gretchen Gavett

This aligns perfectly with our promise of delivering the right content to the right people at the right time. Because segmentation was playing such a central role in the product’s vision, our feature had to be a differentiator.

Minimum Viable Product

The MVP satisfied basic requirements of grouping people based on their behaviors and properties. However, we noticed right away the friction users were having while creating a segment.

They were able to complete their tasks, but we found many pain points:

1. The UI left users guessing whether the correct assets were selected (Partly due to naming conventions)
2. It was tedious to select multiple assets related to a behavior
3. Segment creators and editors had difficulty understanding what was built
4. Drop downs hid the available criteria categories, which made it difficult to plan

Timing is Everything

It can be tempting to go all in on a redesign when you see users struggling with the intended task. But it was more important for us as a product team to add new features to continue our forward progress.

Designers, don’t feel defeated — while product excellence is certainly a top priority, providing value to the business is also our primary objective.

As you work to deliver your new features, invest your spare time in recalibrating, discovering the unknowns, and talking to people to better understand the problem space. There is a certain freedom of working on something without a timeline. Eventually, an opportunity will come and you’ll be ready to capitalize on this investment.

Gathering Feedback

After reviewing our initial feedback — we designed 2 low-fidelity interactive prototypes for testing. The goal was to start a conversation with would-be users, validate concepts, and generate new ideas to take our criteria builder to the next level.

We tested using the System Usability Scale. This score, in combination with the time to complete a task, would serve as a success indicator of each prototype’s unique interactions, information organization schemes, and efficiency/scalability.

While setting an aggressive target SUS score of 77, the average results were 83.5 and 81.5 respectively. Quantitatively both prototypes passed our benchmark and were independently usable. However, each design was made better by combining elements of the other and including some feedback from users.

Some post-test interview qualitative insights:

• Exposed properties for drag and drop made it easier for navigation and segment design
• Live view of members were not useful, and added unnecessary friction
• It’s hard to set a benchmark for behaviors, in the context of segment building, without a point of reference
• People wanted to create criteria using mathematical operators
• Improvements related to visuals cues and information proximity. Prototype B had user’s eyes jumping around, which caused some confusion (A great resource about Gestalt principles)
• Writing queries (a requested feature) was only beneficial to the most technical users

Waiting for an Opportunity

Once we completed and documented the tests, the feature requests sat in our backlog for a couple of months. It wasn’t until a whole release later that opportunity struck.

The convergence of personalization features and new account criteria requirements stemming from the recent release sparked renewed interest in the segmentation feature.

Personalization would finally give the big purpose to segmentation that we always had in mind, while the requirement of additional criteria gave us the excuse to fix our usability flaws.

The final product would be a marriage of the interactions and elements that worked well from each prototype along with the qualitative feedback we received from the interviews.

Delivered Design

Exposed Criteria for Effortless Planning

With all available criteria now exposed, segment creation is easy as selecting criteria from a list. This gives the ability of the user to explore the available criteria without expecting them to know them all prior to arriving to this screen.

Supportive, Scalable, and Scannable

We changed asset selection from a drop down to a modal. With this change it affords us more display space for names, urls, and metrics. The use of these 3 data points, supports the user in finding and selecting the correct asset.

The modal also now allows the user to be able to select multiple assets of the same type. This is to help reduce repeated behaviors to make for more efficient segment design.

Nestable Criteria

Nestable criteria was a hypothesis that proved to be useful to our users when creating segments. This is a case where building a query might be easier for the advanced users, but we wanted our product to be used by the average business user.

To make nesting easier to read and manipulate, the UI clearly shows the nested groups, color codes differentiate criteria types, and introduced a drag and drop functionality.

We also spent some time making each criteria as semantic to the reader as possible. This effort was so that our users, under different contexts, would be able to understand the criteria easily.

Forward Looking

Redesigns are inherently costly for the company. It requires redoing something that already exists and for our user might need to relearn how to use your product. So to make this one count, we had to accommodate to scale for more future (unknown) criteria. Once we understood this, it was an easy fix in the UI which we handled with a dropdown.

Final Thoughts

First of all, big shout out to everyone on the Analytics and DXP segmentation feature for an excellent delivery. It was a great joint effort and I’m very proud of our team.

There isn’t a perfect design workflow and sometimes things can slip through the cracks, especially in large teams. If there are areas needing improvement in your product, work closely with your product manager to align the redesign with the roadmap.

Once you have a sense of priority, you can get to work planning and researching. Remember, not all design work has to be sprint related. Preparation will give you the edge you need to deliver a great solution when you are sprint bound later.

Originally posted by Chris Jeong at liferay.design/articles on October 3, 2019.

The Right Time for Redesign is Now was originally published in Liferay Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Liferay Design team made regular use of Liferay’s developer-centric deployment platform, WeDeploy. Static sites like our primary domain and Lexicon, as well as standalone apps like our NA team dashboard and our Career Path tool (a work in progress), and small pages like our web assets repo page (very much a #wip) were hosted and managed there. It was great to have a single place to handle these projects, which were all built with different tech stacks.

When the WeDeploy team announced that they were shuttering the service, we were at a loss for where to move everything. We did a little research, compared a few services, and thought that it might help other teams who were using WeDeploy (and even people who are just trying to decide between existing services) choose from one of the many options available.

Disclaimer

By “research” we mean “talking with a few resident experts, listening to some good podcasts, and doing a fair bit of Googling” — by no means is this a comprehensive survey of all the available services, we are not sponsored by any of these services, nor are we receiving any kickbacks (…yet, @netlify we love socks… or anything!).

Results

For a Gatsby Powered Static Site

One of the first results when searching for ‘static site hosting’ is Sebastiaan Deckers’ list of ‘Static site CDNs’ — this, and the other lists linked to it, formed a pretty comprehensive, albeit slightly dated (last edited 10 months ago), overview of all the options.

Talking with the aforementioned experts, Ryan and Zeno, it seemed like the two standouts were Netlify and Zeit. After testing out the setup and deployment for each, Netlify was the clear winner for Liferay.Design — it took literally less than one minute to go from setup to deployment, and we were able to see a branch deployed in less than 3 minutes. Previously, we had deploys running through Travis CI, and they could take anywhere from 5 to 15 minutes.

Netlify also handles DNS management — previously we had to use Cloudflare (which was great — but yet another service to log into and manage), moving that to Netlify was pretty painless.

All-told, it took less than an hour for us to set up everything, and 45 minutes of that was waiting for the https certificate. If we had to describe Netlify in one word, it would be “fast and easy” — just say that really fast and it sounds like one word. Our Google Lighthouse score went from hovering around 70–80, no matter how much we tuned performance with our old host, to straight up 100.

Thank U, Next (js)

Yes, the whole reason for this post is so that I could make that incredible pun.

Our career path evaluator tool (forked from Medium Engineering’s Snowflake App) is a small Next.js app. It seemed logical to check out Zeit, as they are the ones who open-sourced Next.js, we figured that Now would play pretty nice with it.

It hasn’t been as smooth as Netlify — a lot of that is probably attributable to ID-10-T errors on the user-side, but deploying with Now is very reminiscent of deploy -p.

Github Pages

Old-reliable — gh-pages is not as flashy or fun to use as Netlify or Zeit, but it’ll get the job done. It doesn’t support continuous deployment, and using custom domains with it can be a bit of a pain — but if you only have one or two pages, then it can be nice to stay completely in the GitHub ecosystem.

Special thanks to @abelfhancock for doing a bunch of preliminary research and testing on his personal site — check it out, it’s pretty cool.

Further Reading

• Where should I host my static website? by Yacine Rezgui
• Github Pages vs. Netlify by Netlify
• Netlify.. Any competition in the market? discussion on Dev.to
• Static site CDNs list by Sebastiaan Deckers

Originally posted by Paul Hanaoka at liferay.design/articles on April 7, 2019.

Netlify vs. Zeit vs. Github Pages was originally published in Liferay Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Look at all these buttons!

If you’re new to Figma, or the atomic model, you might be thinking…okay 1 button x 4 states x 4 levels x 3 configurations…carry the 3…for those of you keeping score at home, that’s 48 components per size!

If you need to change the padding, and it takes you 15 seconds to do it per element…you need to budget 12 minutes for that. Okay thats not so bad…but how many of you only have buttons in your mockups (not looking at you, landing page marketers)?

48 mockups for a single component is not exactly what we in the industry would call ‘maintainable’. In the old days of Photoshop or Sketch, this is why mockups could take days or weeks to do!

Hopefully you get the point — that’s a lot of time for something that’s probably not going to deliver a measurable return on investment. Plus, it’s a really, really, really mind-numbingly repetitive task.

Thankfully, the fine folks at Figma took Sketch’s ‘symbols’ to a whole new level.

Introducing…the component!

Something that differentiates this component from others, is that you can override properties on a child component, and then create a new master component, but the un-overridden properties will still be tied to the original master.

This is great and all, but what are some ways we can practically apply that in more complicated places than icons?

So glad you asked!

Step 1: Evaluate

Back to the buttons —

The first step is to take a long look at these things, and see they are more similar than different. I find it helpful to start listing the similarities:

1. Font size
2. Padding
3. Border-radius
4. Content positioning

and the differences:

1. Color
2. Text-color
3. Border-color

So really, most of the differences are quite superficial. See, just like you and me, there’s more in common than different. What a heart-warming life lesson.

Step 2: Audit

Let’s get a little Platonic — what is the essence of a button? Well, in this case, there is a colored rectangle and some combination of text and an icon. Add a few more colors to the mix and you’ve got the magic that makes lead generation teams drool.

Let’s list out what exactly goes into a button:

Background colors:

1. primary
2. secondary
3. tertiary
4. none

Content elements:

1. Text
2. icon
3. text + icon
4. icon + text

States

1. default
2. hover
3. active
4. disabled

These things will make up the quarks for our atoms.

Step 3: Construction

Previously, you might have started drawing boxes and adding text and icons straight away — this would be wrong. Instead, once you accomplish the first two steps we outlined, and we start to make components from each of these.

Your next components will be the content:

Take note of the icon component naming convention — this will come in handy later.

Next, duplicate and start combining these components to make slightly more complicated components.

Now, you can start to see why nesting can be so powerful — I only need to change the color of the text in one place for that change to cascade to the other two components (sorry for the crappy video):

These are now the quarks that we’ll use to begin construction of the buttons:

You will now start to see the true power of the nested component:

You can see that we can now adjust a number of properties in one place, and have those changes take effect across all of the children. Lets speed it up…and here we go, most of the main buttons are built out:

Now that we’ve built all of the buttons using the quarks, you can witness the full power of this battlestation:

So — what have we learned?

1. Evaluate what you’ve built, listing all of the pieces and properties
2. Audit what you need, and how you want everything to work together
3. Construct things smartly, re-using as few elements as possible

Take a look at the file and leave a comment in Figma if you have any ideas for making it even less work to change some of these things. I know I already have a few ideas!

If this is all a bunch of crap and you hate it, please be sure to let me have it on twitter — but also check out our careers page and help me out!

Originally posted by Paul Hanaoka at liferay.design/articles on March 22, 2019.

Creating Atomic Components That Will Blow Your Mind was originally published in Liferay Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey friends. No time for chit-chat today. You are trying present slides in Figma and your clicker isn’t… clicking. Good news, this is an easy fix!

If you’re more of a visual learner, skip straight to the video.

Here’s how this is gonna go down

We are going to use Karabiner — Elements to hijack the incoming keystrokes from your clicker and translate them to ←left arrow and right arrow→ to toggle Figma slides.

You will need:

• A Mac with Figma (works with or without the app installed)
• A Clicker (we use the Logitech R400)
• Karabiner — Elements (free)

Step 1: Setup your Figma presentation/prototype

If you need help setting up a prototype in Figma checkout their documentation

Tip: If no prototype is setup slides will play from TOP TO BOTTOM, LEFT TO RIGHT

Step 2: Download and install the Karabiner-Elements

Available here

Karabiner installs both their Elements and Event Viewer apps by default. In this case, we will only be using Karabiner — Elements to map the clicker keys.

Step 3: Map the keys of your clicker to left_arrow and right_arrow

This is where the magic happens! Open Karabiner — Elements and:

1. Select your device from the “Target Device:” dropdown
2. Determine what keys your clicker is… well… clicking. If you have trouble with this the Karabiner — Event Viewer app comes in handy to show what keys are being triggered

• Tip: Logitech R400 arrow keystrokes are page_up and page_down

1. Map the clicker key (From key) to the corresponding arrow direction (To key)

(optional) Choose an arbitrary clicker key to map to “r” for restarting your presentation

That’s it!

You should be all ready to use your clicker or remote with a Figma presentation.

Video Demo

If you run into problems or have questions hit me up on twitter

Originally posted by Abel Hancock at liferay.design/articles on March 27, 2019.

How To Use Any Clicker With Figma Presentations (mac) was originally published in Liferay Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

For me, being a UX designer is like going on a long distance bike ride. I can’t wait to begin because I know how enjoyable it is to cycle through scenic trails and how rewarding it feels to finish. However, I don’t think about the hills to climb or the unexpected obstacles that can occur. What I’m trying to say is, designing isn’t always as you expect it to be, but that shouldn’t stop you. It’s in the struggle where we grow and evolve.

Alongside experienced teammates, I’ve had the opportunity to ship software at an enterprise level. Now that I’ve gone through a few product life-cycles with the addition of some small side projects, I’ve learned a lot about what to do and what not to do. For designers getting ready to start their career, here are some life learning experiences from my journey to becoming a more well rounded UX designer.

Redesigning Liferay’s Partner Portal

The first UX project I worked on was the Liferay Partner Portal redesign which launched this year in July. It was the perfect stepping stone to begin working on a cross-collaboration team involving people from sales, marketing, technical writing and development. It demonstrated how vital communication is in the early stages of a product life-cycle.When everyone on a team is working together to achieve the same end goal, each person will have specific needs to get there. The designer must listen carefully and ask questions.

A clear understanding is key to translating needs into a design successfully.

I’m continually trying to improve my communication, but it’s not a natural skill you obtain overnight. I had the opportunity to work under the leadership of a seasoned Liferay veteran who demonstrated these abilities very well. In the beginning phases, the program manager organized and facilitated group workshops where we collaborated on technical specifics, design decisions and workflows. Clear goals and requirements were set and then followed up with concise documentation.

The documents kept the team focussed and made a crucial difference in the success of the outcome. From this experience, I learned it’s critical to communicate effectively with one another for proper project alignment.

More importantly, I discovered you could gain a lot by observing how the people around you think, communicate and make their contributions to the team.

Designing the user interface for Partner Portal was challenging because I didn’t have many sources to draw inspiration from. This challenge forced me to be more innovative throughout the ideation phase. Although this may sound like a dream to some creatives, for product designers it can be intimidating because you can ship designs that aren’t completely proven yet.

We did a great job rising to the challenge, but I fell into the trap of adding more features on the fly than needed. I was disappointed that some of these ideas didn’t make it through to the end, but once I look back at the whole picture, it’s easy to understand why.

In my experience, those add-on features are usually “nice to have” but can cause more problems than they solve. Everything matters and even the smallest elements can add technical complexity, visual clutter and usability problems. They also impact everyone’s work on the team which can lead to longer development times and missed deadlines. Therefore, its best to stay focused on the necessities.

Dieter Rams’ 10th principle of good design is, “Good design is as little design as possible. Less, but better — because it concentrates on the essential aspects, and the products are not burdened with non-essentials. Back to purity, back to simplicity.”

Redesigning Liferay’s Customer Portal

After Partner Portal, it was time for me to work toward my next goal. Liferay customers were submitting support tickets more regularly than using the available self-service solutions and customers were complaining about the feature they use most: ticket creation.

Trying to solve the problem for customer support, I worked closely with the lead project manager, content strategist, my design manager and other key players from the Liferay support team to redesign the customer portal and home built ticketing system.

To prepare for the challenge, I completed an online course through the Interaction Design Foundation about User Research. In addition to self-learning, I expressed to the team that it would be my first time applying some of the UX methodologies we had planned on using.

By being transparent early on, it allowed my team to make adjustments to their work and provide extra support where I needed it.

In addition to telling my teammates about the areas I needed more help in, I expressed my determination to produce a great user experience. I explained that we are all designers and I would educate them on best practices as we carried out the UX process. Having more UX exposure increases the chances of success because it empowers us to make better design decisions.

“Focus on helping every contributing influencer of your designs become a consciously competent designer themselves.” — Jared Spool

While in the design phase, the company made a final decision to use a third party software for the support ticketing system and product documentation. The software benefited the company in many ways but also presented other challenges we didn’t expect. For example, to organize content on the documentation side of the site we had to follow the organization hierarchy tree:

Home > Categories > Sections > Articles

Liferay’s product user guides can go five levels deep, which is more than we had available. Not having enough organization levels broke the original sitemap and information architecture we crafted at the beginning of the ideation phase. I started to feel worried the issue would take away from the seamless user experience we envisioned.

Fortunately, I had support from the content strategist who worked hard on the case as we pulled through. To solve the hierarchy problem, we explored many options and weighed out the pros and cons of each. We ended up settling for a less ideal solution, but it got the job done.

Even though it wasn’t what we had in mind, it taught me that there’s always a solution. Don’t give up, a little outside the box thinking can get you to the place you need to be.

In addition to the limitations the third party software introduced, it also didn’t offer some features Liferay needed for the ticketing system. We needed to build a solution that would enable Liferay’s support engineers to access large files and environment details from customer projects.

We decided it was best to work closely with the leaders of the implementation team early on. The lead project manager and I quickly sketched paper prototypes and presented our ideas to the development team. They gave us great feedback and even improved upon the ideas we had. We ended up with a better solution and the amount of time it took to produce it decreased.

It’s been a humbling experience working with the development team, notably collaborating with the front-end engineers. There are best practices to follow when working with developers such as having design documentation, verbally communicating details and being easily accessible to answer questions. Applying these conventions to the workflow will make code development more efficient and will reduce the number of refinements.

Although it’s best to keep changes to a bare minimum, sometimes they can become more necessary. New improvements may come to mind, or another department can introduce new requirements later on in the process. For example, the marketing team updated the company branding right after we implemented the styling for the help center. We made the necessary changes to reflect the new branding. Despite the positive visual impact, it was a time-consuming process.

Understanding the inconvenience of doing work over again helped me be more mindful when requesting changes or updates throughout the implementation phase.

I’ve realized that it’s best to embrace developers’ skills in the beginning stages and to support them to the end as they bring the design to life.

Liferay’s new Help Center released this month, December 2018. It’s been an incredible experience, and I’m proud of all the work everyone on the team has done. I’m excited to move forward as we keep improving the user experience.

Improving Web Pages for Liferay’s Training Program

My next objective was to collaborate with Liferay’s training department to refine the existing web pages in place for marketing, sales and operations. The training department was receiving feedback that customers found some of the pages on Liferay’s main website confusing.

Trying to solve the customer confusion problem, I collaborated with a six-person team. We analyzed customer feedback, researched best practices, evaluated the competitors, empathized with the primary persona and audited the current user experience. Based on our findings we designed wireframes and presented our proposal. Overall, the team was happy with the direction and it was off to a good start.

As we continued to design the hi-fidelity mockups we started to run into some problems. The training systems are composed of a few different sites, including third party software and Liferay’s main website. Since the pages we redesigned live on liferay.com we needed to follow the website’s design guidelines.

The liferay.com team has done a great job creating a modular system with a library of pre-built and tested components. This modularity enables them to produce web pages more efficiently with fewer errors and makes code easier to maintain. Therefore, we made the necessary changes, but it became an issue when presenting the hi-fidelity mockups.

Long story short, it came down to the benefits of visual impact versus the benefits of scalability and took a few more iterations to get everyone on board. From this experience, I learn it’s best to gain a full understanding of the design system in place before presenting an idea.

Scalability and maintainability are aspects to consider in all projects no matter how big or small, especially when producing at the enterprise level.

My Most Impactful Takeaway

I began to lose motivation after we delivered the final solution to the training department. Frustration was built up from all the times I needed to provide more than a few iterations before receiving approval.

I expressed my feeling to my mentor and my advisor. They explained that frustration was common in our industry considering the many needs designers are expected to meet. However, it still comes down to how the designer handles the situation, not anything else. Ultimately, I was the common denominator in all my scenarios. If I wanted to change the outcome, I need to be more confident when presenting and be more assertive when making design decisions.

I wasn’t expecting the advice given, but it’s usually in the feedback you don’t want to hear that will help you move forward. This conversation gave me a new perspective. When frustration starts to take over, take a deep breath, figure out why, and then ask yourself what you can be doing better to improve the situation.

Take frustration an opportunity to progress in life or take it as another UX problem to solve since designing solutions based on user pain points is what product design is all about.

Going Forward

At the beginning of my journey, I thought to become a more well-rounded designer meant that I needed to sharpen my abilities in user research, visual design, information architecture and interaction design. Although I did, I believe this year was more about growing into a better teammate and leader.

Moving forward I plan to take the knowledge I gained this year and apply it as I navigate through the future. My goal is to work hard on becoming a more effective communicator by being transparent, empathetic and assertive. I will continue my UX learnings, sharpen my skills and do my best to produce excellence.

Originally posted by PJ Pentz at liferay.design/articles on December 06, 2018.

Reflecting on My First Year Designing at Liferay was originally published in Liferay Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

During my first year at Liferay, I had the pleasure of contributing to taking Analytics Cloud from an idea to reality.

During this period, we’ve had anywhere between 3 to 8 designers at various design stages attending brainstorming sessions, providing countless comments over Invision and Figma, and at times flying thousands of miles just to be in the same room together. We did all of this in the name of taking an abstract idea to a concrete product.

But as our design team starts to scale in size and across borders, I find asking myself, how can we be more effective and impactful? These are my reflections from this past year.

Have a guiding star

The agile manifesto prescribes every effective agile team to embrace change, but only when it provides meaningful customer value.

When I look back to roadmap from the inception of this project and compare it to where we are now, the initial requirements seem like a world away. The features and functions that were initially laid out have been stripped to the fundamentals of the product and we are happy with where it stands now.

The idea is that we’ll provide the high value parts and let our customers guide the direction to take. This means, going forward, we need to be more proactive in finding our customer’s voice with research and support.

Avoid designing by committee, at all cost.

Early in the design process, we engaged in divergent brainstorming and ideation sessions which generated in tons of great ideas, but weren’t prepared to execute those ideas.

Divergent thinking challenged us to explore many possible product directions by leveraging:

• Unique viewpoints
• Varying levels of understanding
• Disparate teams with differing goals

This was the easy part.

However, when the designers got together to build on these explorations, I found we lacked a process for converging and distributing the work. This invariably resulted in design by committee, which was a huge drain on resources and resulted in a lot of overlap of work.

Eventually we were able to reorganize. We can Slack all day, but nothing beats being in the same room together. A short 20 hour flight to Brazil and a few discussions later, we were able to resolve these incongruences almost immediately.

The lesson here for us was that freeform creative exercises are an invaluable part of the design process, but they are only as effective as the execution strategy. Going forward after each exercise we must determine:

• An agreed set of requirements
• Explicit ownership to the different parts of the product’s design
• Setting design goals and milestones — with some expectation of change

Design-Ops

UX Design has come a long way from proving the ROI of a great user experience and discussing designer/developer collaboration.

Design-ops has been a hot topic sparking conversation within our organization over the past year. As our department enters a new phase of maturity, we are looking beyond the design tools:

• Design processes are a constant work in progress, learn to accept that and build on what works
• Design Systems help us work faster and focus on the problems that matter
• Digital Asset Management, just do it…
• User research MUST be socialized, or it’s useless
• A centralized database for User Research “nuggets” — currently being developed with Juan Hidalgo Reina on Airtable
• Collaboration during designing (tools like Figma help)
• Don’t hide behind a screen — talk to EVERYONE

Product Management

When product and design goals align — the focus naturally turns towards the users

I look to our product managers to provide me a with a strong vision and strategy, so that I can synthesize that vision in to a design customers will find valuable. However, that’s not to say designers don’t have a say in how to steer the ship. The designer/product relationship share tons of overlap in resources and goals, which make us designers the perfect partners to our product managers. (Tom Hagen/Don Corleone anyone?)

• Sit in on customer calls to get context in to the decision making for the product vision and strategy
• Sharing user research and competitive analysis, allows us to refer back to a single reference point to anchor our positions
• Surface discrepancies of customer needs and product strategy to spark discussion
• Engage in high level design activities such as customer journey mapping and concept wireframes together, for alignment

Conclusion

2018 was a big year for us here at Liferay. We went from being a single product company to having 3 new products to go along with our new and improved portal offering. With the lessons from a whole year of working together, I’m excited how our design team and product will evolve in the coming year.

Originally posted by Chris Jeong at liferay.design/articles on November 29, 2018.

Retrospective of My First Year at Liferay was originally published in Liferay Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

The beginning of November marked my first year as Liferay’s UX Design Manager for North America. As Design organizations are wont to do, we restructured and consolidated some designers from marketing and engineering into a fledgling User Experience team based out of our office in ̶D̶i̶a̶m̶o̶n̶d̶ ̶B̶a̶r̶ Los Angeles.

Spoiler alert: I made a lot of mistakes, but also learned a lot and thought it might be helpful to share some of these things.

Mergers & Acquisitions

(If you read that heading in Christian Bale’s voice — that’s interesting, please continue — this will be my last film reference. Yes, I said film.)

Let me preface this by repeating — I made a lot of mistakes — it took about eight months for our team to get healthy enough to jog. In retrospect that sounds like a really long time and believe me, it was.

Two things I would recommend to managers undergoing a similar process are to “rehire” all prospective teammates and establish a short “onboarding” period to use as a milestone for a team health evaluation.

“Rehire” all teammates that aren’t currently reporting to you

Provide time for a series of interviews, give your colleagues the opportunity to learn about you and your expectations for the team. You should also interview them as you would a new employee, learn about them, identify their strengths and opportunities for growth, and have an open discussion to see if you are the best person to help them and if they are going to be a good fit for the new team. Make the decision together — either party should have the ability to opt-out and explore other possibilities within the organization.

Give yourselves a 60–90 day probationary period

Evaluate and have discussions with each teammate around this time, ideally you’ll be having regular one-to-one’s with them anyway, but now is the time to really figure out how everything has been working out. If there are issues, take immediate steps to resolve them — if you or someone joining the team have any misgivings, this period should provide enough time to address those concerns. It will be much easier for someone to change teams early instead of waiting and allowing potentially bad fit to fester.

Team Culture

There are plenty of far more experienced and knowledgeable people you can read regarding the finer points of strong culture-building, but for starters my recommendation is to do three things regularly:

1. Know your teammates personally — have weekly walks or chats with them. Don’t talk about work, don’t ask for a progress report, use the time to learn about them — their families, their passions, what they’re doing outside of work, etc. Investing in your team in this way will help you serve them in a more effective way.
2. Listen more than you talk — in one-on-ones, in reviews, in team meetings, be slow to give your opinions — ask questions to clarify and guide the conversation, but you’ll learn a lot by talking less and helping your colleagues discover their own voices.
3. Get an outsider’s perspective — have a mentor or coach that you don’t report to. This can be someone at your company but preferably outside of your business unit. Having a calm ear to vent to and a neutral voice of wisdom will help you discover your blind spots and provide an impartial point of view.

Grow and Get Better

Once you’ve successfully merged teams, it’s important to focus on growth. This can be in hiring, but it’s more important to help your current teammates grow personally and professionally.

Conduct regular evaluations to help understand the needs of both individual colleagues and the team as a whole. Being conscious of your company’s business needs and goals, and how well your team is equipped to support them, will help you in creating a case for hiring new teammates.

Creating a growth plan for your team is one of the most important ways to serve them and the business. If your teammates know where they are and where they need to go, they’re more likely to stick around and provide more and more value to the team and the company.

Having industry-relevant positions and goals will help you stay competitive in hiring, but it will also help your teammates stay relevant in the market. If you define your roles and goals solely based on your team’s past achievements, you won’t grow as fast (or quite possibly at all) because you’re only comparing yourself to the past and maybe to others who are a little bit ahead of you, instead of looking at the outside and setting a high bar that is difficult to hit.

Looking Ahead

2018 was a long year. I haven’t even finished all the things mentioned above, but we’re working hard and continuously improving. We’re almost always hiring, so if any of this sounds good and you want to join, check out our careers page (yes, we know it sucks, but the API is kind of hard to work with)!

If this is all a bunch of crap and you hate it, please be sure to let me have it on twitter — but also check out our careers page and help me.

Originally posted by Paul Hanaoka at liferay.design/articles on November 27, 2018.

New team, assemble! was originally published in Liferay Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

With Liferay releasing new products such as Analytics Cloud and Commerce we decided to cover the need for charts by providing an open source library.

The technology

Clay, our main implementation of Lexicon, created Clay charts. These charts are built on top of Billboard.js where many contributions have been done by Julien Castelain and other Liferay developers. Billboard.js is an adaptation layer on top of D3.js, probably the most known and used for data visualization these days.

The issue

Although Billboard.js is a very good framework, it was not covering all our needs in terms of interaction design and visual design. Therefore, we have been working on top of it, contributing some work and keeping the rest of it inside Lexicon and Clay.

Improving accessibility

Improving the accessibility aspect for different charts was one of our first contributions to Billboard.js. We provided 3 different possible properties that help to differentiate the data before having to include colors.

• 9 different dashed strokes styles for the line charts that helps to follow the shape of each line.

• 9 different shapes to use as dots inside the line charts and the legend that helps to read the points in each line.

• 9 different background patterns to be used on shaped charts like the doughnut chart or the bar chart, adding this property to a chart background helps to recognise the different shapes even if the colors are similar.

Here is a clear example so you can see how the user would perceive, read and follow the different data from the line chart, without the direct use of colors.

Creating a color palette

Color is one of the first properties that users would perceive along shapes and lines, making it our next priority. We needed a flexible color palette that allowed us to represent different types of data.

This set is composed by 9 different and ordered colors that are meant to be used in shaped charts as background or in line charts as borders.

Each of these colors can be divided into 9 different shades using a Sass generator. It is useful to generate a gradient chart to cover all the standard situations for charts.
Here’s an example using the color blue:

Ideally, to take advantage of these colors use the charts over a white background.

Warning: using these colors for texts won’t reach the minimum contrast ratio requested by W3C. Using a legend, tooltips and popovers to provide text information is the best course of action.

Introducing a base interaction layer

The idea behind the design of these interactions is to provide a consistent and simple base for all charts. This increases predictability and reduces the learning curve.

These interactions are based on the main events (click/hover/tap) applied to the common elements in our charts: axis, legend, isolated elements or grouped elements.
We also reinforce the visualization, with highlights, between related information and extended information, displayed through popovers.

As you can see in the example below, the Stacked bar and the Heatmap share the same interaction of the mouse hover to create a highlight on the selected data. This is done without any change to the main color when focusing on an element, but instead decreasing the opacity of the other elements.

In addition to this, each designer can extend these interactions depending on their products as well as working on advanced interactions. So, if they need specific actions such as a different result on hover, data filters, or data settings they can add them to the chart as a customization.

Conclusion

Working with D3.js allowed us to focus on our project details such as accessibility, colors and interaction, adding quality to the first version of Charts and meeting the deadline at the same time.

Thanks to the collaboration with Billboard.js we were able to help another open source project and as a result, share our work with the world.

You can find more information about Clay, Charts and other components directly inside the Lexicon Site.

Building charts for multiple products was originally published in Liferay Design on Medium, where people are continuing the conversation by highlighting and responding to this story.