Design from the Ground Up

The Gist

I was promoted to the product team of RevLocal and was placed as the dedicated product designer for a high priority project. The task was to build a proprietary site building tool that our ops teams would use to create all web assets for our clients. Our primary metric for success was to reduce turn around times for landing pages from 14 days to 2 days and full 10-page websites from 60 days to 30 days.

We used Figma to handle the design, but the rest of our systems were relatively undefined. We were a new department, with only two designers on staff, and limited foundational resources to base our designs. We had a lot of work to do in terms of consolidating designs across projects for consistency. We had no design system, no mockup templates, no user testing platform, and our stakeholders’ deadlines left us little time to focus on these foundational elements.

It became a juggling act. Our focus had to be on the current innovations and features the team needed but at the same time we had to carve time to collaborate, document, and build a design system, research database, and component library. All of this while consistently proving the importance of design and foundational resources to members of leadership.

We had several bumps and bruises along the way but that is the spirit of design! In this article, we will follow one feature to show how my fellow designer and I tried to build our foundations, keep pace with our sprint commitments, and win more resources to create more resources.

The Feature

Our featured guest today was the publishing and unpublishing of our client sites. It quickly became apparent that this was going to be a heavy feature with many patterns that will be reused throughout the rest of the application. Not a bad feature to start the process of setting our foundations.

One of the biggest challenges I encountered during this process was that I entered the project after many of the preliminary design decisions were set and built upon. I had a lot of catch up to do while trying to balance the patterns RevLocal’s other projects were using. It was incredibly hard to keep consistency between projects, or even my own features, with no design system and I’ll admit I did not catch everything.

There is nothing worse than hearing, “I think we did something different to solve this last time,” from the engineers after a card made its way to refinement but these were crucial growing pains as it gave us a foothold to base many of our future arguments. When the engineers start to feel the effects of design inconsistency due to design debt, more attention can be brought to what you need.

These first features required an immense amount of collaboration between project managers, engineers, and our small design team. It was a balance to make sure that everyone was on the same page as we designed, find the most relevant functionality that can be reused, catch inconsistency eary, and find past design patterns. It wasn’t great.

Components

One of the advantages of entering a project mid-development is that I had some build high-pri mockups at my disposal. This sped my onboarding since I could grab full patterns from previous mockups to use in current flows. The problem was that many of these patterns were not broken out into components.

It was here that I started to atomize out our design pattens into components. First, starting with the smallest pieces and then building the larger components from those atoms.

Our team was using MUI components in their react environment so the first order of business was to find an official MUI component library from the Figma community and use that as a basis for our own component library. Luckily the Figma community always delivers.

My fellow designer and I took these elementary components and started to create our larger patterns and components from the shared library. Taking the time to create or update a component as we worked on the current sprint commitments. This slowed us down a bit but the shared components were already paying dividends. There was a renewed consistency across projects and traction laid down form some of the bigger endevours that needed more dedicated time.

Unfortunately, adhocing a component library has many downsides and our organization started to slip as one or both of us grew busy. Components needed rework or to be completely refactored but time was scare to give the library the attention it deserved. It was a great start, though, and was something rather than nothing. If anything, we now had a visual to show the power of atomized design with live, in-call updates which was an important piece to create more buyin for design resources.

Testing

A bigger appetite for testing was harder to build. There wasn’t much thought about testing to begin with and it felt as if the tests were there to check boxes rather than bring insights to a rapidly moving project. This is where I needed to take the lead since my users were internal and my co-designers were external. We needed to build our source of truth, our research hub, and leverage my easy access to my primary users in a way that brought attention to the power of user testing.

Enter Notion. My co-worker had used Notion before and we quickly dove in and started encapsulating everything we could into templates, tables, checklists, and reports. This was a massive win because we now had a resource to show stakeholders the process, results, and value of tests across projects.

These results could also be linked to JIRA cards so the developers could reference key findings when questions arose and tie user research results into the normal flow of work.

To be honest with you, it would have been extremely hard to achieve movement on user testing with external users. Even with the strides we saw on our internal project, other projects at RevLocal struggled with gaining enough acceptance to continuously test features.

We had to kick it up a notch. We used our momentum with the site publish flow feature testing and ideas from the popular book Don’t Make Me Think to pitch monthly, cyclical usability testing to our product manager. I can happily say that we now take one morning a sprint to do general usability testing with our user base. With cyclical additions to our body of research, we can see more improvements to the application with more data. More improvements gets attention and eventually more general acceptance.

Mockups

The final piece we investigated was updating our deliverables. Developers were getting frustrated that they could not find the correct screens amongst massive files with lots of features and pages. Our mockups quickly became monsters as we had no deliverable teampates and no time to truly sit and think about how we could deliver our content better until it was too late.

This took many iterations,and many templates passed between my co-worker and I, as we created prototype deliverable templates based on the size and scale of the features we were working on. Our friend, the publish flow, finally convinced us that we needed to separate major features into individual Figma files with strategic page organization for research, userflows, and feature iterations.

This had a warm reception but we can tell that our work isn’t done yet. We still need to consider Figma’s limited file orgaization as the project continues to grow and adjust accordingly.

This was an overall step in the right direction. The devs were happier when opening our separated figma files containing only the feature that was described in the card. Using better deliverable templates can be a simple yet powerful first step in showing the power of solid design resources. If you can make the engineers lives better, it will get noticed.

Conclusion

Designing without core resources is very difficult. It is even more difficult when appetite to create those resources is scarce. Yet it can be done. In typical design fashion, building things brought most of the answers plus our greatest strides in company attitude came when presenting with a half baked solution that was showing signs of promise.

It is through those small strides and adhoc resources that we, a two-man design team, have won more time for testing, passes to conferences, conversations with leadership, and attention to design debt.

There is always room for improvement, but sometimes you just need a bit of breathing room to get started. If you struggle with some of the same constraints, start small. Build as much as you can within the cracks of your daily work and iterate sprint after sprint. It will take time but you may create the breathing room you need to enact organizational change.