This is our story of rebranding, redesigning, and reimplementing 7 actively used Mendix tools, with only 3 people, in 6 months! Reading this piece is great if you’re planning to do a rebranding yourself soon, to get started and to get some advice on a structure.
Mendix is a “low-code platform” that empowers those who aren’t so ‘tech savvy’ to build fully functional applications, with the use of things like visual modeling tools and reusable components.
Our job was to rebrand, redesign, implement and release the Community platform of Mendix.
The Community platform consists of 7 tools that are all interlinked and fully integrated with the Mendix Platform:
Redefining The Brand (3months)
Our first step was figuring out the best way to describe the Mendix brand.
The main pain point was that there was a branding gap between the main Mendix website (aimed at decision-makers of large companies that are buyer personas) and the platform (aimed at Mendix makers that use the product).
This also meant that we had 4 stakeholders, the marketing management team, the community manager, the marketing art director, and the UX product team. To make it even more convenient, these were also allocated in different regions- both the US and the Netherlands.
This process took longer than expected due to:
- Stakeholders with different visions, tastes, and opinions.
- Trying to make everybody happy, which sometimes it isn’t possible
- Wanting to say “yes” to all stakeholders.
After 3 months, we finally settled on a design style, which allowed us to move on to the next phase.
Redesigning The First Tool (1 week)
The first tool to get a redesign was the Documentation.
It is the most isolated of the tools, allowing us to gauge feedback, go live with the new designs without other application components breaking.
Most of the community tools were developed in isolation to each other, creating an incoherent experience. The UX was created by the person who built the tool, which in many cases seemed logical from their point of view but not from a user perspective.
For example. To help create order, the technical writers had created a landing page with 80+ links to all the most important documents so that users had an apparently easy and fast way to navigate to the desired documents. In reality, this was overwhelming to any new users visiting the Documentation.
Documentation created a solid starting point for redesigning the community tools because of its text-heavy nature, allowing us to create a stylesheet determining text styles.
Images, Lists & Reusable Elements.
After docs launched we slowly started working on other more complex tools such as the Forum where there were avatars, lists, icons, different states, mouse over, and other visual elements.
User profiles were also redesigned to incorporate a growing number of stats and information.
Academy (1 month)
Academy was its own beast. Academy is a platform on its own.
Because of this, the stakeholders wanted it to have more personality than the other platforms but still be part of the whole.
Another challenge was visually communicating the hierarchy and the nesting of the lessons. Lessons are called Units, a bunch of Units makes up a Module, a compilation of Modules are a Path. Confusing right, let me draw you a little diagram:
We settled on going for the Explorer Archetype (what are archetypes), which shaped the use of language and themes such as “paths”. From a design perspective, we used cards because of how easy they are to move around (and also super trendy in the design space at the moment.)
Emergence of Design Systems
Design systems started to organically emerge. For example symbols in Sketch, all had the same bounding box to ensure consistency and easy implementation.
The benefits of having a design system are:
- It’s easier to have discussions with non-designers because they are able to let go of the aesthetics and start thinking more about “user-centered design problems”.
- Design systems can be implemented as a set of rules in the Sass Stylesheet, making development quicker.
Pro Tip: in Sketch you can nest symbols by using “/”
(for example. “ICN24 / Social-Active”)
Being a skeptical designer, I wasn’t sure if using Mendix would be a smart choice for implementing these updated designs.
I was more familiar with the pros and cons of traditional web development processes.
But using Mendix gave our team incredible speed that the traditional coding process would not allow for. We could utilize business developers instead of pulling a front/back end developer off of other projects. I could walk over to a colleague and tell him what needed to change, and 3 clicks later with a push to server and an update on my end, I could start implementing the front end.
Don’t Be Scared to Release.
Release it! Everyone says release fast, release often, and fail fast, fail often. But for the people held accountably, it must be scary to release anything that hasn’t gone through at least 100 checks
We were lucky enough that the community manager is a maverick that plays by his own rules allowing us to release fast and keep moving forward.
It was amazing to see how happy the community was to see changes, and even though things might break, the community felt like part of the conversation, giving feedback, and actively voicing cool new features.
Sketch is Awesome for Scaling and Collaboration
When we started we didn’t release how important it would be to have an application that would scale with design systems. I’m glad we have programs like Sketch that help funnel the workflow.
Mendix is Awesome for Implementing UX
Like how Sketch improved the design workflow, being able to use Mendix helped maintain speed and work iteratively when implementing changes.