The Power of a UI Framework
I was sitting in a meeting recently with several clients and we were discussing how to create a solution for a business need. You know the scenario. I was trying to extract understanding from the clients so I could design a solution. Have you ever started squirming when one of them goes up to the whiteboard and starts drawing little boxes and circles to create a user interface? Do you get that feeling in your gut that this person is trying to do your job and prescribe what you should create? We designers tend to get testy about that sort of thing. We want to ensure we maintain control of the design so that we can enforce quality. It’s a good desire, but the push and pull of client interaction can be distressing at times.
But for me, this meeting was a breeze. There was a tense discussion between the clients, and the complexity of the business rules they were discussing would make the IRS cower. The paint-like smell of whiteboard markers filled the room and there were scribbles of UI layouts strewn across six whiteboards. Me? I wanted to put my feet on the conference table. Everything was going quite well.
The designer-client interaction was working for me because our project team had established a strong UI framework for our app. As the clients were drawing visual constructs of functionality, they were using our widgets, patterns, and themes. They were comfortable enough with the UI framework that they could rely on it to represent their ideas—it made designing the solution much simpler. It was easier for me to decipher what they were attempting to explain because they were designing with the designers’ paintbrushes.
Trust me on this one. If your app is anything bigger than tiny, take the time to create a framework. Here are some pointers.
Create a separate page in your app that showcases constructs and patterns.
Here is part of ours that describes data table models (filled with dummy data, of course). Imagine that the title for each table was something like “Tables that Need X Functionality” and each would have example data to reinforce its intended use.
Hold your peeps to it.
If you’re collaborating with other designers, it’s critical for everyone to own and honor the frameworks. If you need to create an exception or an entirely new construct, run it by the team and do your best to reduce visual deviation. If you’re a small team, consider a weekly design review. If your team is larger, a daily design scrum may be necessary.
Share the framework with your client.
In time, the app you are building will help your clients recognize your design standards. But putting them all in one place gives them (and you) a library of possibilities. For us, our clients began to appreciate the consistency in the application, and became our allies in enforcing it. They began to crave uniformity in app-wide user interactions.
Just try it. Gosh.
This may just sound like more work and an extra chunk of code to manage, but rest assured that it will serve you well. The bigger your project gets, the more critical a framework is. This will reduce the subjectivity of your design discussions and give you something to hold to when a client wants to get crazy with a particular piece of functionality. This has served us well and I’ll continue to put my trust in UI frameworks.