Hectic Client Portal Design

The Client

Hectic is a freelance management software that gives freelancers and contractors control over their business. Through project management tools, invoicing and proposal templates, and time-tracking features, Hectic gives freelancers a way to organize their work with ease and efficiency.

Summary

In this 3-week design sprint, my team and I designed the client portal feature of Hectic’s web app. I supported this project by synthesizing user research, competitive and comparative analysis, and conducting usability testing, as well as collaborating on design decisions based on my research. In addition to creating screens for the first version of this portal, my team and I ideated on and designed for future versions of the product and presented these designs to the Hectic team as potential options for future build outs. While this project lasted 3 weeks with Hectic, I am continuing to work with their team as a UX researcher.

Scope and Goals of the Client Portal

While Hectic was a very robust project management tool for contractors and freelancers when my team was brought on, there was not a client-facing side to their system. Adding a client-facing element to the Hectic tool would not only give freelancers a way to communicate with their current clients through the Hectic system, but it would also help them promote and expand their business with public visibility for potential future clients. 

Understanding Clients’ Needs

While Hectic did have user personas created to understand freelancers’ needs for the product, there was no user research done to understand clients’ needs. My teammate Chris and I set about interviewing potential users of a client-facing portal. We started by brainstorming how to source people to talk to, so that we were able to collect accurate and thorough data. Communities that we mined for participants were:

• People who have recently been married or hired contractors for an event, such as photographers, makeup artists, and hair stylists

• Agencies that hire freelancers on a regular basis, both design agencies and modelling or acting agencies

• Platforms like NextDoor, where contractors potentially post to advertise their services (lawn care, babysitting, housecleaning)

• LinkedIn

After reaching out through these networks, we were able to gather 7 participants to talk to about their experiences working with contractors. We asked them questions to better understand what tools they use when working with a contractor, how they typically communicate with the hired employee, how they organize contracts and invoices, and what pain points or frustrations typically come up in these client/freelancer relationships.

We reviewed and synthesized the data collected from these interviews through affinity mapping. Our top takeaways were:

1. Having a high-level overview of the project status, costs, and estimated time of completion was important. We learned in interviews that clients measure success based on timeliness and quality of the product, as well as it being on or under budget. The questions they need answers to are: is the project on time? If not, what does it cost to get it on time? Do we need more resources? Based on this, we decided that a dashboard could help them make informed decisions faster and can identify disconnects & issues down the line.

2. Clients are frustrated with the amount of time they spend checking in on what’s been done by the freelancer and telling them what needs to be done. We learned that it was important for the client portal to have a quick and easy way for clients and freelancers to communicate.

3. Clients give feedback via email, phone conversations, and video calls. But based on the participants’ feedback, we learned that this can get messy for the freelancer, making them miss the mark on meeting expectations. Because of this, we knew it was important to offer a quick and easy way to communicate within the client portal.

Once we knew the key frustrations and needs of clients, we were able to create a user persona and draft a problem statement for this user.

This client is motivated to work with those who are dependable and communicate well. When they do free up time, they like to see the big-picture. All of the users interviewed have had bad freelancer experiences, freelancers who overpromise and underdeliver, deadlines being missed, freelancers going MIA, etc. all of which can hinder the client’s trust. 

In addition to understanding user needs, we did competitive and comparative benchmarking so we could draft a blueprint that was in-line with market trends.

Understanding the Market

Initially, we looked at other client portals to get a direct comparison of other competitors. When looking at these portals, the questions we asked ourselves were:

1. Does this portal improve transparency and help clients help themselves?

2. Can users communicate and collaborate effectively within the portal?

3. Can freelancers decide what, when, where, and how they want the portal to be displayed?

After conducting user interviews, we fully understood the value a dashboard could give to clients. Dashboard design is tricky, and we knew that; it takes a lot of work to display information that balances function and delight. We looked at project management tools that we felt do this well. 

What we saw was that the dashboards from these companies showed great use of widgets, so that users could have all the tools and information in one view and make informed decisions faster with straightforward data visualizations. These visuals included displays that capture problems in advance, such as budget concerns or time tracking.

Once we had analyzed our user data and c&c analysis as a team, we began the design ideation process.

Using Research to Design

Design studio was an opportunity for us to combine our creative energies all together. By sharing our concepts with each other, we built trust, communication, and honed in on how to apply everything we learned in research to the layout of the site. 

Within our design studio, there were 3 key things we focused on:

These initial sketches outlined the look and feel we wanted for the portal. Once we understood how individual screens might look, we went about understanding the user’s journey through the portal.

The Path of the User

We knew that the movement and flow of the client portal should not be simply one-sided – at least two distinct types of users will interact with the product, and use it to communicate with one another. This is slightly more complicated than designing two different sides of the same coin. There is a relationship between the client and freelancer that needs to have a seamless transition, for handing off deliverables, paying the freelancer, and even ending the business relationship with a sense of accomplishment. We had to imagine what it would look like for not only a client to walk through the portal, but how the freelancer would interact with it as well, and how their paths would intersect. We utilized a swimlane user flow to do this. 

A swimlane user flow is a type of flowchart that delineates who does what in the process of moving through a product experience.

Like the lanes of a pool, it shows the path of users as well as the connections, communications, and handoffs between them. This shows you the task flow for both the freelancer and the client, as well as potential friction points for each user within the process.

We used this built-out swimlane user flow to imagine not only the key screens for the MVP, but all the portal could accomplish.

This shows the actions taken by the freelancer or client to reach their task goal, possible emotional friction points for the user, points of intersection between the client and the freelancer, and the user navigating to different pages of the portal (outside of the ‘lane’ of their task flow) to solve these friction points.

This user flow helped us map out many more potential screens within the client portal. But, given the scope of our 3-week sprint, we scaled this flow down to the ‘happy path’, to simplify for version 1.

This helped us understand the clickable elements we needed to build, the screens we needed to design, and the timeline of the journey for the freelancer and client. This user flow shows the journey of the freelancer, from uploading the first version of a deliverable, to reviewing the client’s comments and iterating, to uploading the final asset and ending the project. For the client, this shows what the process looks like for a client to receive a new deliverable, leave feedback on it, view the final asset and approve, and end the relationship with the freelancer. 

Now that we could visualize the path of the users, we could build our screens with a flow.

Designing Client-Facing Screens

We started by designing the client side of the portal. We went as simple as possible, with a sidebar navigation with 3 main pages: ‘what I need from you’ to house tasks for the client to complete, ‘for your information’ to show the client a overview of the project, and ‘what’s ready for you’, to house final deliverables for the client to view and download.

1. ‘For your information’ dashboard

• Project progress card: Gives the percentage of the project that’s complete, tasks that are not started, in progress, or complete, and provides alerts for tasks that require the client’s attention.

• Updates card: Notifies the client when the status of a project changes.

• Invoice and budget card: Where the client can view the hours billed, the amount owed, the amount paid, and if they are over, under, or on track with their budget.

2. ‘What I need from you’ page

This screen lists out tasks that the contractor needs for the client to complete before they can finish the project. There are CTAs prompting the client to complete the task, and once the task is complete, that CTA becomes a check mark ✅.

3. ‘What’s ready for you’ page

Contractor-Facing Screens

These initial screens were well received by Hectic, but left everyone wondering how exactly information that the contractor inputs into the web application translates to the client portal. We didn’t really know what was possible to build on the back-end, so our initial explorations of the contractor’s interactions with the portal were completely manual.

Another one of our goals was for the contractor to be able to customize the client portal appearance according to their branding guidelines.

This idea for customization was based on our initial competitive benchmarking as well as our user interviews. It was important to use to give Hectic designs that were informed by this initial research and screens that integrated seamlessly into the client-facing side of the portal, so that, when they were able to apply these designs to their product, the transition was as streamlined as possible.

Testing the Designs

Because our main goal for this design sprint was to create a client portal that is efficient and effective for clients to use, we utilized the client-facing screens and prototype in usability testing.

I compiled all the observations and insights from this testing using the rainbow spreadsheet method. This thorough examination helped me pull out patterns across all users, and see underlying problems to our designs that we could fix.

My key top takeaways from this testing were:

Users wanted to be able to preview documents or deliverables before they downloaded them, especially if they needed to comment on them. One user said, “if there’s nothing for me to click on to see, it forces me to read...and I don’t like reading”. This desire for more visual references to documents came up with every participant, so we knew we should try and implement it in our designs.

1. Users wanted to be able to preview documents or deliverables before they downloaded them, especially if they needed to comment on them. One user said,

   “…if there’s nothing for me to click on to see, it forces me to read...and I don’t like reading”.

   This desire for more visual references to documents came up with every participant, so we knew we should try and implement it in our designs.

2. Almost all participants were confused by the term ‘for your information’ in the navigation. Some users didn’t expect high-level summaries to be there, and figured they would be in ‘what’s ready for you’. Others weren’t sure where to go for that information, because they started in the portal on the task screen. So we learned that it may be more useful to start on the dashboard, and possibly rename the navigation.

3. 3 of 5 users tested had difficulty reading the copy – some mentioned it was really small, some mentioned it was really condensed. 

4. Everyone enjoyed the ‘FYI’ screen, once they got there. They loved being able to see the project progress quickly, and to be able to see communications from their freelancer quickly. Some users even spoke to wanting to download or view documents straight from the dashboard screen. This gave us feedback that we should build the dashboard out to be more clickable and delightful, from a UI perspective.

After sharing these takeaways with my team, we started iterating.

Iterations

First, we addressed the navigation.

We had wanted the sidebar to be as simple as possible, but based on user research, it seemed it was almost too simple, which ended up being confusing. So we changed the language -- ‘FYI’ became ‘dashboard’, ‘what i need from you’ became ‘your tasks’, ‘what’s ready for you’ became ‘deliverables’, and we added dedicated pages for agreements and invoices, so they were more accessible and housed in one place.

Next, we addressed the dashboard.

• We added a budget progress bar, for quick access to financial updates.

• We included calendar and contact information for reference, so clients could communicate with their freelancers with ease.

• We added downloadability to deliverables, and condensed task details to reduce information overload for clients.

We also updated displays for deliverables.

This builds in the ability for the freelancer to upload a static image of their document that the client can reference as a preview before they download. We iterated in this way to meet the needs of the user, while still staying in the scope of MVP that Hectic is currently working and building within.

These iterations applied what we learned from testing, and strengthened the portal format for Hectic’s future buildout.

Additional Screens

Once we had conducted usability testing, we realized that we needed to create additional screens that existed outside of our original user flow. These screens we added based on our iterations to the navigation, as well as insights we gained from talking to users in testing.

Invoices and Agreements

Once we changed the sidebar navigation to include pages for invoices and agreements, we knew we needed to design those screens.

• The agreements page is very similar to the deliverables screen – the client has the ability to download business documents, view if they have been signed or completed, and see the file type and size.

• The invoices page implements similar features to the dashboard, incorporating budget trackers at the top, then listing downloadable invoices below.

Event-Based Contractor Dashboard

One of the insights we gained from testing was that different contractors may have different needs, depending on their relationship to their client. While we initially designed for project-based freelancers, we realized we needed to account for event-based freelancers, as well as contractors who may be on retainer.

On this screen is an example of a wedding photographer’s event-based dashboard, where we can see some differences from the project-based contractor dashboard:

Folding these screens into our iterated designs rounded out the client portal capabilities and effectiveness for users.

Imagining Future States

Giving these additional screen designs to Hectic helped outline what the portal should be able to do right away, and what the portal could expand to be later down the line. However, we still had design ideas that were out of the scope of development for Hectic in the first version. These future states were still screens we wanted to give to the Hectic team, so that they could use them as inspiration for future build outs, when they had the ability. These designs were crafted based on our initial user research, as well as the trends we saw in competitors and other successful dashboard tools. 

Deliverables Preview

One of our first designs for the client to leave feedback on a deliverable looked like this.

Selecting the deliverable would bring up this preview screen, where the client could then leave feedback and change requests directly on the image or document. We learned early in our process that the way files are currently stored on the back-end doesn’t support this design. Regardless, we created this to show a possible future design that supports the needs of clients and freelancers in the editing process.

Connected Applications

We learned in user interviews that customization of the portal was integral for a lot of clients and contractors. We also learned that communication is often a frustration point in the client/contractor relationship.

To help solve for this, we ideated on the possibility of connecting other apps through widgets in the client portal, so that contractors and clients could continue using their favorite methods of communication, and access them through the Hectic portal, instead of going outside of the portal site. This way, communication would be documented all in one place.

Public Contractor Profile

Part of our vision also includes creating a public facing profile for the contractor as an additional resource to find new clients.

Based on user interviews with freelancers (see my Hectic mobile user persona case study), we knew that client churn and maintaining workload is a stressor for many freelancers. With the implementation of a public contractor profile, freelancers could post reviews, recommendations, contact information, and a few examples of their work. This way, contractors could have a way to advertise their services through Hectic, and have a landing page for clients to contact them, see their work, and see their availability.

While my team and I knew these screens would not be usable right away in the first version of the client portal, designing them honored the data we collected from research. Even within a startup that may not have the capability to build these screens immediately, crafting them showcased the vision we had for this product, and gave us a goal for the evolution and future of the portal.

Assessing the Success of the Product

At the end of this 3-week sprint, my team and I felt this client portal even blossomed into a product that could be marketed and sold on its own. And, as an added cherry on top, Hectic told us they believe these designs accomplish their business goals, too – which makes the process even that much more fulfilling!

What I Learned

Working on a dedicated team that often presented our work to the entire company was such a great learning opportunity; it taught me how to defend my design ideas based on research, and to really integrate business goals with design choices. I also learned how to use some very valuable tools, such as a swimlane user flows and the rainbow spreadsheet method of research synthesis. Lastly, while it was sometimes frustrating to realize that not all of our designs could be implemented by developers, I learned that presenting future goals for the product can not only be valuable from a design perspective, it can also demonstrate dedication to the longevity and evolution of the product. I’m excited to see this client portal come to life when Hectic integrates it into their product design.