The design process is usually a challenging endeavor that is custom tailored for each client individually. There is no cookie cutter to copy and paste the design scheme from one project to another. Each client has a special user group that can differ vastly between projects. Usually, most clients want to be involved in the design process and observe the progress, there are exceptions to the rule but mostly this is true. It's not like in the good old days where the designer would get specifications, retreat to his "cave" and come out with finished designs. Today's users are much more mutable in their expectations, and the "old way " is too slow and rigid to accommodate to the constantly changing user needs. 

A new process is necessary, easy to understand for everyone included, fast and effective. A modern approach of solving problems that fits into the platform, in our case it’s Sitecore. In an ideal situation the design process is an iterative process of finding the best solutions through constant discussions, improvements and testing different viable solutions. Sometimes, and more than often, it's a more messy situation where anything that can go wrong goes wrong by Murphy's law. 

So what is this different approach and how does it differ so much that can make significant improvement? I'll try to clarify this and shed light on how a comprehensive design process helps us achieve our goals faster and more effective. Depending on the complexity of the project, the time available and the resources, the definition of the design process can differ significantly. Simple one pager applications with a few users don't need to be detailed and well documented processes that are necessary when building full scale applications with tens of thousands of daily users. You can imagine the design process like building a house for one family, or making a building with 20 floors that will maybe need another 20 floors built on top of them in the future. As an engineer and a creative professional you need to take much more factors into equation when designing something so much bigger than the simple solutions for a small number of users.

Simply put, the design process is nothing more than a tool responsible to ensure the consistency of different bricks of the "building", implemented with speed and efficiency. It sounds mechanical and dull for a design process, but this is needed if we want to design not only interfaces but complex systems that work perfectly in harmony. I mentioned in this article how the term design transcends from visual to abstract terms, when you take into account that everything needs to be "designed", even the components that are implemented into Sitecore by developers are designed. It is a slower process but needed if you are building something to last rather than only work for a short period of time without any scalability. 

With this introduction about the importance of the design process, let's jump into what the components of this process are and how they work together to create a flow. As I mentioned, in the ancient times of IT, the designer would get specifications from clients what to create, the output would be a finished design that would be handed out to developers. But what if developers are blocked by a third party, what if the designs need to be revisited when the implementation has already started, what if the users change their mind? The design would usually go back and forth at a great cost of time and money. More often the design would go obsolete before its live launch. The missing part of this practice and why it didn't last were people, the end users. In that past time, we did not fully understand how much and how quick user needs can change and that this needs to be taken into account. Designers, developers, management and the client often played a game of chasing the existing user needs or even long past needs, rather than anticipating what could change in future.  One of the pioneers that figured out this game early on was Steve Jobs. His approach was not to try and catch people and yield them into using what he created, he rather anticipated what people really want now and, more importantly,  will want in the future. The core design of the iPhone interface and the phone shape did not change radically over the years, the premium customer service that is unique to Apple was ahead of its time. Jobs did not create a group of followers, he merely recognized this emerging culture of elite gadget users and invested into the future. The rest is history. 

To go back from Apple to our design process we need something we can use to quickly accommodate the growing user needs, and still have the time for innovation. Most of the companies have processes that are short sighted and oriented on current user needs. This is mostly because there is a pressure of the stakeholders and the competitive market. Imagine if you could scale the projects multiple times without much strain to your resources. That's why the right process needs to be implemented from the start. It's nearly impossible to change things later on.

I mentioned in past articles what  wireframes  are and how to use them, what their benefits are  and which types of wireframes exist. Also in these articles, there is a lengthy explanation of what pattern libraries are and what is the importance of pattern libraries. I think everyone knows what design in general represents and what are the differences between design mockups and wireframes.

The items that are missing from this list are: brand guidelines and the component catalog. Brand guidelines represent an official company document made of branding elements that are unique to a company, such as brand colors, the official logo, fonts, gradients etc. Often times companies have brand guidelines created as a graphic design foundation for their banners, business cards, memo pads etc. Brand guidelines are important later on when creating design mockups.

A component catalog is a list of wireframe parts for each page individually. If you can imagine each page as an organism, the components are molecules that have atoms. For example, the main slider component is a molecule of a landing page organism that has a title, a background, and a subtitle as an atom. The component catalog has a wireframe bare bone look with an additional description that is useful to developers when implementing Sitecore components. So, the component catalog is a document of listed components taken from wireframes that developers can lurk into any time, and use as a foundation for implementation.

Let's connect everything together. We have wireframes that show the bare bone skeleton display of different pages. We have the components catalog created after the wireframes are finalized. This catalog is used by developers and updated by designers in collaboration with the clients. Finally, we have design mockups and brand guidelines. Brand guidelines and wireframes are inputs for a designer when creating design mockups or updating existing ones. The design can be created in parallel with component implementation in Sitecore and frontend and backend development. Developers can implement the bare bone bootstrap looking application that only needs a makeover. This is a much more effective and faster way of doing things than the waterfall model in the predefined phases. Design, development and company marketing can move at the same pace, regardless of how the user needs change and scale over time. Everybody knows, at any time,  where they are and in which phase the project is. And this system represents a process that is a fast, scalable and effective way of developing Sitecore applications.

Feel free to contact us if you have any questions!