A wireframe Design System
A year ago I started working with NetSuite on a business intelligence (BI) product. I know, it’s a pretty broad subject, full of fancy technical terms. Like any new hire would do I started excitedly and cheerfully to put together ideas that would surely revolutionize 2 years of work that a team of 30+ people had done. Needless to say that soon enough I face planked on an Sketch artboard.
The reason for was the mammoth of a product that NetSuite is. We’re a company providing small to midrange businesses with one of the best cloud based CRM and ERP systems out there. Since 2009 NetSuite has been using an iterative user-centric approach to tweak its user experience based on customer research. NetSuite did not start off with a bunch of robust UI elements 20 years ago. It’s been diligently tweaking its interface using research as a driving force to meet customer needs and satisfaction. In my first few months there I was impressed by how much every one of the hundreds of employees knew about users. I quickly turned into a sponge trying to soak up all of that knowledge.
However when I reached a more mature stage in my design process I realized that having a system for behaviors and components would benefit my immediate team and help keep consistent within the whole product. The problem was that there was no such thing. Information was scattered around Confluence, Sketch and Photoshop files, an online dev catalogue and a lot of word of mouth.
I’d like to share with you how I tackled this issue within my team and how designing within a structure at a certain point in the design process proves to be beneficial.
Setting up the stage
Before NetSuite I had a bunch of start-up experiences. I was a wild animal, testing apps in bars offering people a beer for their thoughts, iterating on flows as much as 3–4 times per week, changing brand direction as soon as we discovered more about our users — everything was done fast, we were a small team and had fun putting together stuff and laying it out there.
In a big company things take time. On the bright side you have more time to think about processes and how to make things work better.
BI is complex but design shouldn’t be
After the first few weeks of getting accustomed with the product, I soon found myself staring at a full-blown UI looking for a button to turn on subtitles because what I saw seemed like a distant foreign language. And I’m Romanian, we speak a lot of languages!
The challenges
The project I was part of had quite a long history behind it. The team was scattered over 2 continents, 3 countries and 4 different cities and along the way quite a few designers migrated to other projects. By that point the XD team (as we like to call ourselves at NetSuite) was lacking continuity and since it was supporting around 30+ cross-team developers, the pressure was high and design communication was weak.
Another issue we faced were inconsistencies. There was a lot of pressure for the team to deliver and so the temptation to dive right into wireframes was quite high.
On the bright side…
The part of the product we were developing had the advantage of being new so we were able to start from scratch, ask the business questions and understand the mental models. We were encouraged to come up with behaviors and UI components that would make the experience better for our users and we weren’t restricted by the legacy UX/UI.
By the time I joined the team they had been developing for about 2 years so the product was already thick and juicy. A lot of inconsistencies had naturally found their way into the code. The developers and designers did not speak the same language.
I decided we needed a little bit of structure.
The inventory
First thing I did was to deploy a virtual machine. I diligently made a list of all the UI elements I saw on the page, I documented patterns and behaviors and shared my findings with the team.
After creating an inventory of all the UI components and behaviors I discovered a lot of inconsistencies and duplications in our app: we had two tab selector positions, an undocumented green color, 5 icons for deleting stuff and mostly hacked components, just to name a few.
picture of the inventory coming soon 🙃
My team agreed we had a slight problem that was affecting our VM tests and user researching was bringing back inconclusive results. I took on the challenge to address these inconsistencies and find a better way to define these elements and behaviors with the goal of eventually establishing a stable design process. To do that I needed to understand what issues the new system was going to solve.
What did the system lack?
I decided to meet up with the whole team (PMs, devs, researchers, designers, QA) and find out what each of us thought the product we were building lacked and what we thought should be the focus for a better design.
We did an activity in teams that helped us map out what we thought our process lacked, where the flaws were in our design and development organization.
We ended up with the following common aspiration for our product:
🤙 Affordance
The controls should map to a logical, expected outcome. (Eg. If an arrow is pointing left then by pressing it it should move elements to the left of a page. Duh you might say but oh how easy it is to reinvent the wheel. In fact it is MUCH easier.)
✨ Simplicity
Each step in a flow feels trustworthy and easy. BI is essentially all your company’s intelligence in one place. In our case, the cloud. So a browser. Obviously we aim to not send our users to the ER with a heart attack because they pressed back right in the middle of refreshing a pivot…
🌈 Tolerance
Users must be able to recognize, diagnose and recover from errors. BI can also be heavy and tricky. We needed to come up with a pattern for helping users to easily recover from mistakes. Because they will press that back button 😩
✂️ Consistency
Language use is clear, behaviors, interactions and UI elements are consistent. (Eg. Keep it clean, just one tab selector is fine!)
🤸 Structure
Information hierarchy and content structure are laid out clearly. (Eg. In a building flow users need to focus on different UI elements at different times. Make it clear what those are.
The system
So now that I knew what the system would solve, it was time to iterate.
The natural step to me was to take the inventory and turn it into the system. It had all the components, the inconsistencies had all been documented and… I ended up with a huge Sketch file. That was not going to help the team. I had to break it down into logical, understandable files and for that I went back to the scrum box to see what were the relationships between the elements that created the user flows. This part was going to help the designers. I called it…
The shared libraries
I checked out navigation relationships on pages and UI elements and came up with a few bigger, more general components.
After that, I was able to lay down the foundation of what would become our design team’s shared libraries. By this point I should mention I was the only designer using Sketch. We knew our team would grow and we agreed that it would be great if newer designers had this documentation to refer to.
So I started with one of the biggest components which had most of the inconsistent behaviors and elements since it appeared on almost all pages within the flow of our users. This was called the Left Panel.
Taxonomy
By this point we started naming things. Once components were discovered I’d put a name on them, check it with devs, go back to the file and adjust them where needed and then share the new vocabulary with the team. This is a work in progress and of extreme importance because it facilitates communication.
The panel library consisted of a bunch of components within components. I broke it down into smaller chunks, named these chunks and defined clear states for them. This helped designers on the team for a few reasons — keeping consistent and understanding how the product works and building wireframes faster without needing to spend time worrying about them and spending that time meeting with users and understanding use cases. It also helped facilitate the communication with developers and PMs.
Our process today
Since I started we had another UX designer and a visual designer join our team. Together with Dominika Banik we continued to build our team’s UX system and we are currently approaching each design problem in the same manner. We laid the foundation for how to build shared libraries and prototypes and validate design ideas with our team. This for us means that we can focus on user needs and solving complex design challenges.
We now have a designated team in NetSuite building a UX and visual design system and a UX process for the entire company. My team was a little bit ahead of the game due to the nature of our project. Today our teams work together and feed off of each other’s work. We use the same rules, definitions and terms so communication is easy. PMs started using the new taxonomy in requirements and so understanding problems and focusing on solving them for our users is easier. We don’t need to worry that building a prototype will take ages. We focus on understading the fascinating BI world.
What I learned from this adventure was that being proactive pays off. If you see a problem go ahead and suggest a better way of doing things. Talk to the people you think you’re going to help. I cannot emphasize this more. More often than not you’ll find out that what’s good for you doesn’t work for the person working just next to you. But after all, everything is still a work in progress but the key is communication and structure. I’ll leave you with my guiding quote through this endeavor:
The best way to complain is to make things. — James Murphy
We’re now iterating on the design process that happens before the designer gets to the high-fi prototype phase. Reach out if you have some eye-opening ideas that you’d like to share with us! We’d love to hear back from you!
