Desktop HD Copy 34.png

Peerlyst

 
 
 

Introducing Peerlyst

Peerlyst is a social network for security professionals.

Peerlyst serves as a platform for security professionals to write posts, share knowledge and build reputations. It is also a place where security vendors can post and promote their products to the users. 

 

cONTENTS

  • My role 
  • The Monetization Project 
  • Process 
    • Design the Product Wizard 
    • Redesign the company page 
    • Mobile responsive site
  • Learnings 
 
 
 
 

My role

Since September 2016, I have been the sole UX Designer.

As the only designer at the company, I work on major monetization features as well as small improvements of the existing experience. Since I’m still a senior at RISD, I work remotely. I keep close contact with the San Francisco office through daily Skype calls with the PM and weekly calls with the CEO and the developers. 

 

Learning by doing. Grow as fast as possible. 

I was offered the position after winning Peerlyst's design Hackathon. At the time, I was finishing up my 10-week UX Design program at General Assembly. I was honored and humbled that Peerlyst believed in my ability to carry on the work previously done by a much more experienced designer. This experience pushed me to learn and grow as fast as I can. 

 
 
 

The Monetization Project

How might Peerlyst attract more paid vendors to promote their products on Peerlyst?

The major project I worked on was the monetization. Before the project, even though vendors could show their products on Peerlyst to attract potential customers, there were not many vendors who were doing it. To invite more vendors to the website and pay for the product promotion service, many pages have to be updated and new features needed to be built.

 
 
 
 
 

Elements of the project: 

 
 
 
 

With only 4 weeks to design, we had to iterate quickly and effectively.

The project started in mid-November and the designs needed to be done by mid-December for beta test. Because we only have one front-end developer and one back-end developer, the new designs need to reuse the existing elements as much as possible to eliminate unnecessary development efforts. In the four weeks, I had daily Skype calls with the PM and frequent meetings with the developers and the CEO. 

 
 
 

 
 
 

Redesign company page

For vendors to be proud to say "That's my page!" 

To invite more vendors to the site, the vendor page has to look good. In the redesign, we focused on making the vendors feel powerful and proud of their pages.

 
Desktop HD Copy 45.jpg
Desktop HD Copy 46.jpg
 
 

When the style guide didn't work.

To our surprise, the biggest challenge in designing the company page was in the buttons. Since Peerlyst has a style guide, most of the design I do follow the style guide. However, in this case, because of vendors’ request to make the “Contact vendor” button a call to action button, it conflicts with the toggle state of the “Follow” button right next to it. Both buttons will be oranges if we just follow the style guide. 

Because both the “Follow” button and the style of the call to action buttons are used in many cases across the site, we have to think carefully if we want to change the styles or make exceptions for this case. 

 
 
 

 
 
 

Process to design the product wizard

The product wizard allows vendors to add products and promote to Peerlyst users.

It was a brand new feature that was added. Since the point of the whole monetization project was to invite more vendors to promote their products, the design of the product wizard was extremely important. 

Snippet of the wizard:

Group.jpg
 
 

Start by asking questions to understand the goals.

I learned to ask questions early and communicate often with the PM. When I first started working with Peerlyst, there were times when I dived into design too quickly without really understanding why we are building the feature, which resulted in unnecessary designs.

When I got to the monetization project, I’ve realized that there is nothing more important than understanding the project goals. All the designs and decisions have to be made based on the goals.  Therefore, I started by asking questions to truly understand the goal of this feature. 

About the wizard:

  • Why are we building the product wizard?
  • How does it fit into the bigger picture?
  • What are the necessary elements?
  • Which element is the most important for Peerlyst vs. for the users?

About the users:

  • What do vendors care most about?
  • Which parts of the wizard might vendors find the most annoying vs. most rewarding?
  • What device will they mostly likely to use for this wizard? 
 
 

List and categorize the necessary elements

By listing out all the necessary elements and categorizing them, we had a sense of how the wizard should be structured before we go into the actual design. This step turned out to be very helpful.

However, I wish I had spent even more time in this step. While we had a general sense of the structure, we still ended up going back and forth many times with the breakdown of the steps. In the future, I will try to stay in this preparation stage and low fidelity stage for as long as possible, because it will end up saving more time in the long run. It is a lot easier to make changes at this stage than after we go into high-fidelity stage. 

 
 
 
 
 
 
 
 

Sketch out rough layouts.

 
 
 
 
 
 
 
 

Explore ways to break the process into digestible steps. 

The biggest challenge in designing this wizard was to figure out how to categorize all the necessary elements into small and reasonable steps. There are many info that need to be filled out by the vendors. It is very easy for the vendors to feel burdened by the process. It was our priority to make the process feel as effortless as possible. 

There were many back-and-forth in the designs. Below are some of the progress bar/tabs that we tried. The bar/tab styles changed, but more importantly what goes into each step changed many times.

 
 
 
 
 

Iterate. Iterate. Iterate

The first design I came up with was an overlay which was quickly eliminated. My initial idea was that an overlay would make it look like a quick action so vendors would be willing to complete it. However, I quickly realized that what we really want is for the vendors to focus on adding products. An overlay is not good for focusing their attentions at all. 

The changes that come after the overlay one was mainly in the structure of the whole process. We had to decide whether we want to combine “Add product” and “Promote product” into one flow so vendors are encouraged to go through the “Promote” flow, or we separate them, so vendors feel less burdened? 

 
 
 
 
 

Ask myself "why" in every decision.

The importance of asking “Why” has been the biggest lesson I have learned from working for Peerlyst. When I showed my mockups to the PM and the developer, I was always questioned “why you made that decision” “Why that...?” “Why not that…?" In the beginning, I sometimes couldn't answer those questions because I didn’t think through all the details when I designed. In fact, often times, when I was asked about the “why” is when my decisions didn’t look logical.

I realized that I have to have reasons for every decisions, even if it’s the smallest details. From the whole layout, to a thin divider, there are all endless options. It’s the “why” that makes one option better than the other.  

 
 
 
 
 

Consider the details and edge cases.

While figuring out the overall structure of the pages, we also thought about the edge cases and the details at the same time. For me, I found that the biggest difference between working on a real product vs. on a class project is how much more attention to details that is required for a real world product. 

In a class project, if we are to make a flow, all we need to do is to design the main pages. For a real product, it is all about the details. Every thing: the error message, the tooltips, the hover states, the edge cases… all needs to be carefully thought through. All the “What if” questions have to be answered. Nothing can be left unaddressed.

 
 
 
 
 
 
 
 
 
 

 
 
 

Mobile responsive site

30% of the Peerlyst users are on the mobile site. Therefore, when designing all the pages, we need to make sure that the solutions for the desktop site can also work for the mobile site.

 
 
 
 

Sketches for mobile:

 
 
 

 
 
 
 

Learnings  

 
 

The best solution is at the intersection of business, design and technology. 

Working closely with the CEO, the PM and the developers, I learned that a UX designer has to understand business goals and technical limitations. I can have the most beautiful mockups, but if it does not bring anything useful for the business or take way too long to develop, the designs are useless.

As I worked on more tasks, I learned to ask questions about the goal of the task in the beginning, and to check with engineering often to see what is doable and what is not.

 
 
 
 

Peerlyst's trust motivated me to do better work. 

Working with Peerlyst allowed me to experience how a fast-paced start-up works. I realized at a start-up, I can have a lot of impact on the product. However, with the impact also comes the responsibility.

With all the trust from the company, I can not be the weak link, especially during the monetization project when everyone was busy. The PM, the developers were all working late at night. Even though I work remotely, I need to keep up with the speed so everyone else can have less to worry about. 

 
 
 
 

Working 8 hours a day while finishing up the school semester pushed me to work efficiently. 

The monetization happened at the same time when the fall semester was ending. It was a challenging time but also a great opportunity for me to improve my time management skills and pick up my working speed. Because the developers couldn't start working until I finalized the designs, I made sure that I finished Peerlyst's work first and then work on my own school works.

There are still many parts of the design that need to be improved. I'll continue to revise, learn and grow.

 
 
 

More Works