We recently launched a new design of the LawHelp platform (managed by Pro Bono Net) to make major improvements to the aesthetic design as well as the overall user interface (UI) and user experience (UX). We first launched the new design on LouisianaLawHelp.org with our pilot partner Lagniappe Law Lab. Since then we have implemented the new design on just about every LawHelp site across the country. You can see other examples at AyudaLegalPR.org, OKLaw.org, LawHelp.org/DC among many others. We call it the LawHelp Refresh.

When we set out to re-design LawHelp, we wanted to meet four main design goals:

1. Mobile-optimized design — A strong mobile design that isn’t an afterthought to the desktop design but rather a primary focus.
2. Refreshed aesthetic — An overall improved aesthetic to bring LawHelp into the realm of contemporary web design including a wider range of color palettes available, all that meet WCAG 2.0 AA guidelines.
3. Decreased reliance on text — Reducing the need for explainer text through intuitive and accessible design.
4. Improved calls to action (CTA’s) — Making it much clearer to users where to go and how to get there.

We have learned a ton during this project across the board and I want to share some of the key things we learned all the way from design through usability testing. In this three-part series, I’ll first describe a bit about our design process. This was a big project spanning more than 20 websites and we learned a lot through it. In Part II I’ll share how we recruited for and structured our usability testing. We’ll dig into what usability testing is, how to structure a usability test script, and pitfalls to avoid. Finally, in Part III, I’ll outline what our results were, how the design succeeded and failed, and what we did next.

Part I

Our design process, with our longtime design partner Ideal Design Co., was rigorous and included extensive input from our LawHelp team, the wider Pro Bono Net team, and of course our state partners across the country. We pored through numerous design iterations and explored several avenues for how to improve the LawHelp design. I can’t count how many rounds of revisions we had but I know it was more than enough! A few things that helped us succeed in the design process:

1. Tiered feedback
2. Centralizing documentation and discussion
3. Folding in technical input
4. Frequent communication with design

Tiered feedback

The LawHelp platform supports over 20 websites across the country and meets the needs of numerous user types and civil legal aid organizations. This means we have numerous stakeholders which makes design difficult! In the past I have worked on platforms where our stakeholders were much more centralized and our user types were more focused which made for a simpler design process.

 

 

We needed to get feedback from the internal LawHelp team at PBN, staff in the wider Pro Bono Net organization with experience developing legal information websites and self-advocacy tools, our state civil legal aid organization partners, and our users. That’s a lot of cooks and our kitchen can’t fit them all. So we set up a tiered system of feedback. The LawHelp team was at the center, spending the most time and going through all of the details, big and small. We would then post our design notes and documents to the wider Pro Bono Net organization for feedback and input.

Then, at regular intervals in the design process, we sent out announcements to all of our LawHelp state partners to review and submit feedback. This included an open invitation for emails but also some drop-in sessions where we presented our progress and opened the mic up for feedback. We also drew on findings from past usability testing on LawHelp sites and other legal resource sites such as TenantHelpNY.org to inform our design process. This process struck a good balance between efficiently progressing on the designs while including valuable feedback and perspectives from outside the team.

This diagram shows how we set this up. The white triangle to the left shows the practices we used to ensure that the perspectives and experiences of each group were able to cut all the way through directly to our product team.

Centralizing documentation and discussion

A key ingredient to any effective tech team is strong project organization and communication. It’s so important that in the past, at every tech company/organization I have worked at, we have taken time out specifically to redesign our file structure in Google Drive. This was key during our design process because we were able to easily store the numerous versions of design files. We used clear labeling systems for each design file so you knew which was the most recent. Those file names then corresponded to a single design review document that we used for documenting discussion.

Let’s say you were on the LawHelp team and on a Wednesday morning, you had set aside time to review the most recent designs. Instead of digging through emails or Slack, you had one Drive folder bookmarked. In this you could find the design review document. At the top of the document was a header “Wireframes V6 (current).” That header hyperlinked to the design file so you could easily pull it up. A week later, when V7 came out, you’d see that header change to drop the “(current)” part of the title and simply say “Wireframes V6” and above that is a fresh new area for discussion called “Wireframes V7 (current).”

Below is a screenshot directly from our review document.

Folding in technical input

A big stumbling block in the software development process can be failing to include the engineering team early on. We included our developers and QA team in the design review process and utilized our project management tool, Jira, to keep track of various discussion points. This was especially helpful when considering new features or major changes to existing ones. This helped prevent some surprises down the road when it came time to code (although you simply cannot prevent all surprises).

Jira is a great tool for software project management. It’s a very powerful tool and requires a large amount of investment in setting up. Its numerous features for organizing projects were a huge help in keeping track of numerous discussion points big and small such as a new Google Maps integration and what dependencies there would be. You may not need a tool as powerful as Jira though depending on the nature of your projects.

Frequent communication with design

Never let design become a game of telephone! It’s tempting to do especially when your designer is not in-house. You hear something from your developer, pass it to your project manager, who then pings the product manager, who then drops a comment in the Google Doc to the designer. This inevitably leads to information loss and your designer then moves forward with only half (or less) of the story.

Since our designer for this project was not in-house, we kept a clear open line of communication. We would easily jump into a video chat if anything was too complex or nuanced to outline in a document. As the product manager for this project, I made sure to utilize active listening skills when centralizing feedback. The key skill here is repeating back to people what you think they are saying and allowing them to correct you. This made sure I was getting it right and allowed for less meetings. It meant I didn’t need to have seven+ people on a call with our designer while still avoiding the game of telephone.

A good phrase to get comfortable using is, “Let me make sure I’ve got this right. What I hear you saying is [X,Y,Z]” That phrase has saved me more time and trouble than I can quantify. I know that because in the times I didn’t exercise that skill, things went in circles.

This lesson on active listening skills applies pretty much everywhere in our lives though, not just work. It’s amazing how much we assume and get wrong. Plus, everyone appreciates knowing that the person they are speaking to is actively working to hear them.

In Part II…

That’s how we structured the design process. Eventually we finished up, went through the development process, and then prepared to usability test as soon as the beta site was complete. Exactly how we usability tested is all in Part II.