Bringing Order into the Chaos
Design can be a chaotic business. Some believe for creative juices to flow, anarchy needs to be present. I disagree.
Well, at least I disagree when we are talking UX Design, where different parties are involved, deadlines to be made, stakeholders to be pleased, money to be earned and all that good stuff.
What we need is a good system in place.
“Ah, you mean agile”
Well, yes and no. Agile is a form of process management; an approach that is useful when developing digital products. And every design method around can be exercised in an agile environment. A design method is a set of tools. A framework, rather than a set of rules and constraints, within which a design team can do what they do best, create solutions to problems.
There are various cool names floating around; user centered design, goal directed design. I don’t care what you call it, a design systems should be based on four layers:
- Design Principles.
- Design Patterns.
- Design Process.
- Design Practices.
Let’s look at each of these.
Design Principles
These are guidelines for developing solutions under specific circumstances. This last part is important. A design principle will not work in all situations.
When evaluating if a principle is true and useful to the problem at hand, ask yourself:
- Does this principle help my users / customers achieve their goal?
- Does this principle help minimize / reduce the work for my users / customers?
Also, there is no harm in always rethinking the value of design principles. Of course there are differences. Principles like grouping, or whitespace, or color theory, have proven themselves for hundreds of years, serving artists long before the digital age.
But most principles about digital design are young and many of them are shaky. In the late nineties, one of the guidelines for web pages was that it needed to load in a few seconds, or visitors would leave. Actual research on the topic has shown that load times become irrelevant when users are convinced they can achieve their goal on the page.
Needless to say that designing by blindly following design principles is no guarantee for a good result. Principles will only get you so far. “We have no time to do research, we just use design principles and best practices.” The design agency who made that statement to me recently, lost my respect at that very moment.
Design Patterns
Design Patterns are building blocks that have proven themselves useful for solving certain problems.
There are common patterns, which are generally accepted within the design community as being useful. A well known source is UI-Patterns. Patterns are essential in design because they are the vocabulary of your design team. Experienced designers can come up with workable solutions fast, because they can draw from a broader range of ideas.
Above we see a good example of a sign-up form. Why?
- Because it uses the minimum number of fields to complete.
(no, we do not need a name in this case!) - It offers flexibility with alternative ways to sign up.
(positioned on the left to invite usage) - It has a clear call-to-action button colored green.
(we are good to go!)
Compare this with numerous other sign-up forms and you will see the same mistakes over and over again. Paying attention to proven design patterns will pay-off. So does listening to a seasoned designer who will point out the exceptions to the rule…
Add to this the possibility of turning your own patterns into a library, customized with styling and what not, and you are well on your way to building a Design System. Having an ever expanding and evolving design language within your company can be very beneficial.
Design Process
Having a design process in place is essential for allowing a design team to excel at finding optimal solutions. Such a process should include:
- Planning (yes, an agile process does include a lot of planning),
- Doing research (never assume you know it all),
- Creation of personas, use cases, scenarios, maps, and all that good stuff,
- Use all of the above to develop and iterate a solution.
Above we see a diagram of such a process. Of course we sometimes need to adjust it up or down depending on the time, scale and budget available.
Now, let’s look a bit closer at each of these steps and why they are important.
Project Planning
Naturally most executives want to receive at least a rough estimate on how the project will be structured and what they can expect as a final result, before they sign off on a contract.
- It is key to identify the stakeholders and collect their input. They are the ones who will tell you the objectives.
- We draw up an ideal approach and rough schedule to the perfect solution. The very best we can come up with.
- Then we discuss this with the stakeholders and they can decide on the trade-offs to reduce time and cost.
This will give us an initial roadmap to work from.
Research
To solve a problem, you first need to understand it. Sounds obvious, doesn’t it?
Then why ignore it? Good research, before you have done any designing, helps you to put together the optimal product specification and make good decisions later. Having research data also helps the team; different opinions become far less important with data as a reference.
- Interviews with stakeholders provide insight in the business goals and technical limitations. Pay attention to any red flags you need to examine along the way. This side of the coin we call the implementation model.
- Interviews with potential users give insight in their goals, needs and other important factors. This is what we define as the user’s mental model.
- The product you need to design should bring these two together. We refer to this as the representation model.
For now, remember that the closer the implementation model is to the user’s mental model, the better the representation model will be. I will get back to this in detail in later articles.
Modeling
After collecting raw data, we need to visualize it, so it can tell its story. We identify trends, behavioral patterns and goals.
Practically this means developing personas, use cases, user flows, data structures, scenario’s, etc. etc. These are conceptual, abstract representations of the ecosystem. The downside of these is that they will be invisible in the product; however, a product designed without them will make painfully clear something is missing…
Requirements
Often associated with traditional process management, product requirements have taken a bad beat. But, no matter how agile your company is, you still need to include this important step in your design process.
We need to determine the product’s functionality. The personas’ goals and scenario’s, the business objectives and constraints together provide the answer.
This will also be another opportunity for the stakeholders to discuss and decide on critical trade-offs early in the process. In the end everyone should be clear about the focus and parameters of your team’s design efforts.
Framework
Once we have an agreement on who our users or customers will be and what our product needs to do, we can start sketching the actual layout.
Content hierarchies, content models, wireframes are part of this process, but do not forget the copy itself. Labels, headings, and other pieces of text should be explored in the same way as visual layouts. This is an essential part of your information architecture.
In all these cases the design should remain high level. The less detail, the better. Once stakeholders see concrete design proposals, we want them to talk about the strategic implications of changes to the major underlying structure, not the size of the logo. That’s for another day.
This stage is used for refining product focus and parameters.
Detailed Design
Finally! This is what everyone has been waiting for. No more time to waste!
Wait! If you feel we have been wasting time so far, something is wrong. Either back up and read this post again, or start looking for another UX Designer.
From here on we start to develop increasingly detailed user stories, scenario’s and prototypes in an iterative process. Actually this is where the earlier mentioned design principles and design patterns start playing an ever increasing role.
This part of the process is where collaboration between subject matter experts and engineers becomes important. Field research will teach you a lot, but experts will push it to the next level. Engineers will ask questions and raise issues that will help build the product. When we talk about “developers” within a scrum team, we are not just talking about programmers.
At the end you will have a pixel perfect design, ready for implementation.
Implementation Support
Once the product sees the day of light, the design team will need to be on standby to solve any unexpected issues.
Do not make the mistake of having your engineers and programmers make design decisions. That is a recipe for disaster. Programmers will look for the easiest way to code functionality, not the road to bridging the gap between implementation model and mental model.
Make sure there is a good relationship between the design team and the developers. Make sure the developers know how to contact your designers. Make sure your designers take time in addressing any problems that are brought to their attention.
Design Practices
A design process does not live in a vacuum. Whether it is successful depends on a lot of other factors, most of which are outside its scope of influence.
Process Management plays a major role here; these days the focus is all on Agile Management, Lean Processes and Scrum Teams. And while applicable in a lot of projects, keep in mind that they are not one-size fits all solutions.
A design team can be a relative small part of a larger product team. We just need to make sure there is frequent contact between the two. Design should function as a catalyst for making ideas real. Design sprints are very effective for quick, optimal solution finding.
Of course, no design process will lead to success if the environment does not suit it. Some things that can go wrong are:
- The technicians have too much influence and have control over the financials.
- The technicians lack the skills to bring the conceptual design to real life.
- The stakeholders are not the decision makers.
- etc. etc.
But, if you keep an eye out for such issues and use a design process that fits your organization and its culture, great results will follow.
Until next time.
