For a long time, responsive design dominated the web as the format of choice for business and personal sites. Now, however, mobile optimization has begun to gain credence as a potentially preferable strategy. Mobile optimization refers to optimizing a website specifically for mobile devices. Instead of simply compressing and slightly rearranging the content on the screen, you design the entire experience for smaller screens. You’ve probably heard the term “mobile-friendly.” It’s a bit outdated, so even though it sounds like a good thing, it’s not enough. People are using their mobile devices more and more, as I’ll explain in a…
UX Your Life: Applying The User-Centered Process To Your Life (And Stuff)
Everything is designed, whether we make time for it or not. Our smartphones and TVs, our cars and houses, even our pets and our kids are the products of purposeful creativity.
So why not our lives?
A great many of us are, currently, in a position where we might look at our jobs — or even our relationships — and wonder, “Why have I stayed here so long? Is this really where I want or even need to be. Am I in a position where I can do something about it?”
The simple — and sometimes harsh — the answer is that we don’t often make intentional decisions about our lives and our careers like we do in our work for clients and bosses. Instead, having once made the decision to accept a position or enter a relationship, inertia takes over. We become reactive rather than active participants in our own lives and, like legacy products, are gradually less and less in touch with the choices and the opportunities that put us there in the first place.
Or, in UX terms: We stop doing user research, we stop iterating, and we stop meeting our own needs. And our lives and careers come less usable and enjoyable as a result of this negligence.
Thankfully, all the research, design, and testing tools we need to intentionally design our lives are easily acquired and learned. And you don’t need special training or a trust fund to do it. All you need is the willingness to ask yourself difficult questions and risk change.
You might just end up doing the work you want, having the life-work balance you need, and both of those with the time you need for what’s most important to you.
I’d be remiss if I didn’t admit, the idea of applying UX tools to my life didn’t come quickly. UX design principles are applicable to a much wider range of projects than the discipline typically concerns itself, but it was only through some dramatic personal trials that I was finally compelled to test these methods against my own life and those of my family. That is to say, though, I’m not just an evangelist for these methods, I also use them.
So how do you UX your life?
Below, I’m going to introduce you to four tools and techniques you can use to get started:
Your Life In Weeks A current state audit of your past.
Eisenhower Charts A usability assessment for your present and your priorities.
Affinity Mapping A qualitative method for identifying — and later retrospecting on — your success metrics (KPIs).
Prototyping Life Because you’ve got to try it before you live it.
Business As Usual: The User-Centered Design Process
Design thinking and its deliberate creative and experimental process provides an excellent blueprint for how to perform user research on yourself, create the life you need, and test the results.
This user-centered design process is nothing new. In many ways, people have been practicing this iterative process since our ancestors first talked to each other and sketched on cave walls. Call it design thinking, UX, or simply problem-solving — it’s much the same from agency to agency, department to department, regardless of the proprietary frame.
The user-centered design process is, most simply:
Phase 1: Research The first step to finding any design solution is to talk to users and stakeholders and validate the problem (and not just respond to the reported symptoms). This research is also used to align user and business needs with what’s technically and economically feasible. This first step in the process is tremendously freeing — you don’t need to toil in isolation. Your user knows what they need, and this research will help you infer it.
Phase 2: Design Don’t just make things beautiful — though beauty is joyful! Focus on creating solutions for the specific needs, pain-points, and opportunities your research phase identified. And remember, design is both a noun and a verb. Yes, you deliver designs for your clients, but design is — first and foremost — a process of insight, trial, and error. And once you have a solution in mind…
Phase 3: Testing Test early and test often. When your solutions are still low-fi (before they go to development) and absolutely before they go to market, put them in front of real users to make sure you’re solving the right problems. Become an expert in making mistakes and iterating on the lessons those mistakes teach you. It’s key to producing the best solutions.
Most design-thinking literature illustrates how the design process is applied to products, software, apps, or web design. At our agency, J+E Creative, we also apply this process to graphic design, content creation, education, and filmmaking. And it’s for that reason we don’t call it the UX design process. We drop the abbreviated adjective because, in our experience, the process works just as well for presentations and parenting as it does for enterprise software.
The process is about problem-solving. We just have to turn the process on ourselves.
Expanding The Scope: User-Centered Parenting
As creatives and as the parents of five elementary-aged kiddos, one of the first places we tried to apply the design process to our lives was to the problems of parenting.
In our case, the kids didn’t clean up their Legos. Like, ever. And stepping on a Lego might just be the most painful thing that can happen to you in your own home. They’re all right angles, unshatterable plastic, and invariably in places where you otherwise feel safe, like the kitchen or the bathroom.
But how can you research, design, and test a parenting issue — such as getting kids to pick up their Legos — using the user-centered design process?
We’re far from the first parents to struggle with the painful reality of stepping on little plastic knives. And like most parents, we’d learned threats and consequences were inadequate to the task of changing our kids’ behavior.
So we started with a current-state contextual analysis: The kid’s legos were kept in square canvas boxes in square Ikea bookcases in a room with a carpeted floor. Typically, the kids would pour the Legos out on the carpet — for the benefit of sorting through the small pieces while simultaneously incurring the pain-point that Legos are notoriously hard to clean up off the carpet.
We also did a competitive analysis and were surprised to learn that, back in 2015, Lego appeared to acknowledge this problem and teamed up Brand Station to create some Lego-safe slippers. But, sadly, this was both a limited run and an impractical solution.
Lastly, we conducted user interviews. We knew the stakeholder perspective: We wanted the Legos to stay in their bins or — failing that — for the kids to pick them up after they were played with. But we didn’t assume we knew what the users wanted. So we talked to each of them in turn (no focus groups!) and what we found was eye opening. Of course, the kids didn’t want to pick up their Legos. It was inconvenient for play and difficult because of the carpet. But we were surprised to learn that the kids had also considered the Lego problem — they didn’t like discipline, after all — and they already had a solution in mind. If anything, like good users, they were frustrated we hadn’t asked sooner.
Remember when I said, your user knows what they need?
One of our users asked us, “What about the train table with the big flat top and the large flat drawer underneath.”
By swapping the contents of the Lego bins with the train table, we solved nearly all stakeholder and user pain points in one change of platform:
Legos of all sizes were easy to find in the broad flat drawer.
The large flat surface of the train table was a better surface for assembling and cleaning up Legos than was the carpet.
Clean up was easy — just roll the drawer closed!
Opportunity bonus: It painlessly let us retire the train toys the kids had already outgrown.
No solution is ever perfect, and this was no exception. Despite its simplicity, iteration was quickly necessary. For instance, each kid claimed the entire surface of the top deck. And the lower drawer was rarely pushed in without a reminder.
But you know what? We haven’t stepped on a Lego in years. #TrustTheProcess.
The Ultimate Experience: User-Centered Living
Knowing how to apply the design process to our professional work, and emboldened from UXing our kids, we began to apply the process to something bigger — perhaps the biggest something of all.
The Internet is full of advice on this topic. And it’s easy to confuse its ubiquitous inspirational messages for a path to self-improvement and a mindful life. But I’d argue such messages — effective, perhaps for short-term encouragement — are damaging. Why?
Vague phrases or platitudes.
Disingenuous speakers, often without examples.
The implication of attainable or achieved perfection.
Calls for sudden, uninformed optimism.
But most damning, these messages are often too-high-level, include privileged and entitled narratives masquerading as lessons, or present life as a zero-sum pursuit reminiscent of Cortés burning his ships.
So let’s take deliberate control of our lives using the same tools and techniques we use for client work or for getting the kids to pick up their damn legos.
Content Auditing Your Past: Your Life In Weeks
The best way I’ve found to get started designing your life is to take a look back at how you’ve lived your life so far. It’s the ultimate content audit, and it’s one of the most eye-opening acts of introspection you can do.
Tim Urban introduced the concept of looking at your life in weeks on his occasional blog, Wait But Why. It’s a reflective audit of your past reduced to a graph featuring 52 boxes per row, with each box representing a week and each row, a year. And combined with a Social Security Administration death estimate, it presents a total look at the life you’ve lived and the time you have left.
Your Life In Weeks maps the high points and low points in your life. How it’s been spent so far and what lies ahead.
What were the big events in your life?
How have you spent your time so far?
What events can you forecast?
How do you want to spend your time left?
This audit is an analog for quantifiable user and usability research techniques such as website analytics, conversion rates, or behavior surveys. The result is a snapshot of one user’s unique life and career. Yours.
Start by looking back…
Where and when did you go to school?
When did you turn 18, 21, 40?
When did you get your first job? When did your career begin?
When and where were your favorite trips?
When and where did you move?
When were your major career changes or professional events?
What about relationships, weddings, or breakups?
When were your kids born?
And don’t forget major personal events: health issues, traumas, success, or other impactful life changes.
What can you look forward to…
Where do you want your career to go and by when?
What are your personal goals?
Got kids? When is your last Spring Break with them? When do they move out?
The perspective this audit reveals can be humbling but it’s better than keeping your head in the sand. Or in the cubicle. Realizing your 40th really is your midlife might be the incentive you need for real change, knowing your kids will move out in a few years might help you re-prioritize, or seeing how much time you spent working on someone else’s dream might give you the motivation to start working for your own.
When I audited myself, I was shocked by how much time I’d spent at jobs that were poor fits for me. And at how little time I had left to do something else. I was also shocked to see how little time I had left with my kids at home, even as young as they are. Suddenly, the pain of sitting in traffic or spending an evening away at work took on new meaning. I didn’t resent my past — what’s done is done and there’s no way to change it — but I did let it color how I saw my present and my future.
Usability Testing The Present: Eisenhower Charts
Once you’ve looked back at your past, it’s time to look at how you’re spending your present.
An Eisenhower chart — cleverly named for the US president and general that saved the world — is a simple quadrant graph that juxtaposes urgency (typically, the Y-axis) with importance (typically the X-axis). It helps to identify your priorities to help you focus on using your time well, not just filling it.
Put simply, this tool helps you:
Figure out what’s important to you.
Most of us struggle every day (or in even smaller units of time) to figure out the most important thing we need to do right now. We take inventories of what people expect from us, of what we’ve promised to do for others, or of what feels like needs tackling right away. Then we prioritize our schedules around these needs.
Like a feature prioritization exercise for a piece of software, this analytical tool helps separate the must-haves and should-haves from the could- and would-haves. It does this by challenging inertia and assumption — by making us validate the activities that eat up the only commodity we’ll never get more of — time.
Start by listing everything you do — and everything you wish you were doing — on Post-Its and honestly measure how urgent and important those activities are to you right now. Then take a moment. Look at it. This might be the first time you’ve let yourself acknowledge the fruitless things that keep you busy or the priorities unfulfilled inside you.
What’s important and urgent?
Taxes (at the end of each quarter or around April 15)
Rent (at least once a month)
What’s important but not urgent?
Something you’re passionate about but which doesn’t have a deadline
A long-term project — can you delegate parts of it?
Telling your loved ones that you love them
What’s urgent but not important?
Texts and Slacks
Neither important or urgent
TV (yes, even Netflix)
The goal is to identify what’s important, not just what’s urgent. To identify your priorities. And as you repeat this activity over the course of weeks or even years, it makes you conscious of how you spend your time and can have a tremendous impact on how well that time is spent. Because the humbling fact is, no one else is going to prioritize what’s important to you. Your loving partner, your supportive family, your boss and your clients — they all have their own priorities. They each have something that’s most important to them. And those priorities don’t necessarily align with yours.
Because the things that are important to each of us — not necessarily urgent — need time in our schedules if they’re going to provide us with genuine and lasting self-actualization. These are our priorities. And you know what you’re supposed to do with priorities.
Identifying what your priorities are is critical to getting them into your schedule. Because, if you want to paint or travel or spend time with the kids or start a business, no one else is going to put that first. You have to. It is up to you to identify what’s important and then find time for it. And if time isn’t found for your priorities, you only have one person to blame.
We do these charts regularly, both for family and business planning. And one of the things I often take away from this exercise is the reminder to schedule blocks of time for the kids. And to schedule time for the thing I’m most passionate about — writing. I am a designer who writes but I aspire to become a writer who designs. And I’ll only get there if I prioritize it.
Success Metrics For The Future: Affinity Mapping
If you’ve ever seen a police procedural, you’ve seen an affinity map.
Affinity maps are a simple way to find patterns in qualitative data. UXers often use them to make sense of user interviews and survey data, to find patterns that inform personae or user requirements, and to tease out that most elusive gap.
In regards to designing your life, an affinity map is a powerful technique for individuals, partners, and teams to determine what they want and need out of their lives, to synthesize that information into actionable and measurable requirements, and to create a vision of what their life might look like in the future.
You don’t need a template to get started affinity mapping. Just a lot of Post-It notes and a nice big wall, window, or table.
How to affinity map your life (alone or with your life/business partners)
Write down any important goal you want to achieve on its own Post-it.
Write down important values or activities you want to prioritize on its own Post-it.
Categorize the insights under “I” statements to keep the analysis from the user’s (your!) point of view.
Organize that data by the insights it suggests. For instance, notes reading “I want to spend more time with my kids” and “I don’t want to commute for an hour each way” might fall under the heading “I want to work close to home.”
Timebox the exercise. You can easily spend all day on this one. Set a timer to make sure you don’t spend it overthinking (technical term: navel gazing).
This is a shockingly quick and easy technique to synthesize the insights from Your Life In Weeks and your Eisenhower chart. And by framing the results in “I” statements, your aggregate research begins speaking back to you — as a pseudo personae of yourself or of your partnership with others.
Insights such as “I want to work close to home” and “I want to work with important causes” become your life’s requirements and the success metrics (KPIs). They’ll form the basis for testing and retrospectives.
Speaking of testing…
Prototype Or Dive Right In
Now that you’ve audited, validated, and created a vision for the life you want to live, what do you do with this information?
Design a solution!
Maybe you only need to change one thing. Maybe you need to change everything! Maybe you need to save up some runway money if the change impacts your income or your expenses. Maybe you need to dramatically cut your expenses. No change is without consequence, and your life’s requirements are different from anyone else’s.
When my wife sat down and did these activities, we determined we wanted to:
Work from home, so we don’t have to commute
Start our work day early, so we’re done by the time the kids come home from school
Not check email or slack after hours or on weekends
Make time for our priorities and our passion projects.
Central to this vision of the life we wanted was a new business — one that met the functional and reliability needs of income, insurance, and career while also satisfying the usability and joy requirements of interest, collaboration, and self-actualization. And, in the process, these activities also helped us identify what services that business would offer. Design, content, education, and friendship became the verticals we wanted to give our time to and take fulfillment from.
But we didn’t just jump in, heedless or without regard to the impact a shift in employment and income might have on our family. Instead, we prototyped what this new business might look like before committing it to the market.
Using after-hours freelance client work and hackathons, we tested various workstyles, teams, and tools while also assessing more abstract but critical business and lifestyle concerns like hourly rates, remote collaboration, and shifted office hours. And with each successive prototype, we:
Some of the solutions that emerged from this were:
A remote-work team model based on analogue synchronous communication and digital statuses (eg. phone calls and Slack stand-ups).
No dedicated task management system — everyone has their preferred accountability method. My wife and I, for instance, prefer pen and paper lists and talking to each other instead of process automation tools (we learned we really hate Trello!).
Our URL — importantshit.co — is a screener to filter clients for personality and humor compatibility.
Google Friday-style passion project time, built into our schedules to help us prioritize what’s important to each of us.
And some of the problems we identified:
We both hate bookkeeping — there’s a lot to learn.
Scaling a remote team requires much more deliberate management.
New business development is hard — we might need to hire someone to help with that.
So when we finally launched J+E Creative full time, we already had a sense of what worked for us and what challenges required further learning and iteration. And because we prototyped, first, we had the confidence and a few clients in place so that we didn’t have to save too much money before making the change.
The ROI For Designing Your Life
Superficially, we designed a new business for ourselves. More deeply, though, we took control of variables and circumstances that let us meet our self-identified lifestyle goals: spending more time with the kids, prioritizing our marriage and our family above work, giving ourselves time to practice and grow our passions, and better control our financial futures.
The return on investment for designing your life is about as straightforward as design solutions get. As Bill Burnett and Dave Evans put it, “A well-designed life is a life that is generative — it is constantly creative, productive, changing, evolving, and there is always the possibility of surprise. You get out of it more than you put in.”
Hopefully you’ll see how a Your Life In Weeks audit can help you learn from your past, how an Eisenhower chart can help you prioritize the present, and how a simple affinity mapping exercise for your wants and needs can help you see beyond money-based decisions and assess if you’re making the right decisions regarding family, clients, and project.
It’s always a give and a take. We frequently have to go back to our affinity map results to make sure we’re still on target. Or re-prioritize with an Eisenhower chart — especially in a challenging week. And, sometimes, the urgent trumps the important. It’s life, after all. But always with the understanding that we are each on the hook when our lives aren’t working out the way we want. And that we have the tools and the insights necessary to fix it.
So schedule a kickoff and set a deadline. You’ve got a new project.
Down For More?
Ready to start designing a more mindful life and career? Here are a couple links to help you get started:
At J+E Creative, you can download to try all three of our research methods on yourself and on your life. You can also see a version of this article presented at Connect.Tech.
On the other hand, the last time you shopped on eBay, you may have noticed the use of multiple design elements encouraging you to buy an item (“last item”, “3 watched in the past day”). While these design techniques are used to persuade users, they are usually not deceptive and are considered white hat techniques.
A third example comes from Google I/O 2018 last month when the world heard Google Duplex make a call to a salon for an appointment and carry out a fluent conversation mimicking human mannerisms so well that the person at the other end did not realize she was talking to a machine. The machine did not misrepresent itself as human, nor did it identify itself as a machine, which, in my book, puts it in a gray area. What’s stopping this from being used in black hat design in the near future?
As you see from the three examples above, the use of persuasive tactics can fall anywhere on a spectrum from black hat at one extreme to white hat at the other, with a large fuzzy gray area separating the two. In today’s world of online and email scams, phishing attacks, and data breaches, users are increasingly cautious of persuasive tactics being used that are not in their best interest. Experience designers, developers, and creators are responsible for making decisions around the ethical nature of the tactics we use in our designs.
This article will present a brief history of persuasion, look at how persuasion is used with technology and new media, and present food for thought for designers and developers to avoid crossing the ethical line to the dark side of persuasion.
History Of Persuasion
Persuasion tactics and techniques are hardly new — they have been used for ages. Aristotle’s Rhetoric, over 2000 years ago, is one of the earliest documents on the art of persuasion. The modes of persuasion Aristotle presented were ethos (credibility), logos (reason), and pathos (emotion). He also discussed how kairos (opportune time) is important for the modes of persuasion.
Fast forward to today, and we see persuasion methods used in advertising, marketing, and communication all around us. When we try to convince someone of a point of view or win that next design client or project, chances are we are using persuasion: a process by which a person’s attitudes or behavior are, without duress, influenced by communications from other people (Encyclopedia Britannica).
While Aristotle first documented persuasion, Robert Cialdini’s Influence: The Psychology of Persuasion is more commonly referenced when talking about modern persuasion. According to Cialdini, there are six key principles of persuasion:
People are obliged to give something back in exchange for receiving something.
People want more of those things they can have less of.
People follow the lead of credible, knowledgeable experts.
People like to be consistent with the things they have previously said or done.
People prefer to say yes to those that they like.
Consensus (Social Proof)
Especially when they are uncertain, people will look to the actions and behaviors of others to determine their own.
We have all been exposed to one or more of these principles, and may recognize them in advertising or when interacting with others. While that has been around for ages, what is relatively new is the application of persuasion techniques to new technology and media. This started off with personal computers, became more prominent with the Internet, and is now pervasive with mobile devices.
Persuasion Through Technology And New Media
Behavior scientist B.J. Fogg is a pioneer when it comes to the role of technology in persuasion. Over two decades ago, he started exploring the overlap between persuasion and computing technology. This included interactive technologies like websites, software, and devices created for the purpose of changing people’s attitudes or behaviors. He referred to this field as captology, an acronym based on computers as persuasive technologies, and wrote the book on it, Persuasive Technology: Using Computers to Change What We Think and Do.
Interactive technologies have many advantages over traditional media because they are interactive. They also have advantages over humans because they can be more persistent (e.g. software update reminders), offer anonymity (great for sensitive topics), can access and manipulate large amounts of data (e.g. Amazon recommendations), can use many styles and modes (text, graphics, audio, video, animation, simulations), can easily scale, and are pervasive.
This last advantage is even more pronounced today, with mobile phones being an extension of our arms, and increased proliferation of smart devices, embedded computing, IoT, wearable technology, Augmented Reality, Virtual Reality, and virtual assistants powered by AI being embedded in anything and everything around us. In addition, today’s technological advances allow us to time and target moments of persuasion for high impact, since it is easy to know a user’s location, context, time, routine, and give them the ability to take action. This could be a reminder from your smartwatch to stand or move, or an offer from the coffee shop while you are a few blocks away.
Ethics And New Technology And Interactive Media
The use of persuasion in traditional media over the past decades has raised questions about the ethical use of persuasion. With new media and pervasive technology, there are more questions about the ethical use of persuasion, some of which are due to the advantages pervasive technology has over traditional media and humans. Anyone using persuasive methods to change people’s minds or behavior should have a thorough understanding of the ethical implications and impact of their work.
One of the key responsibilities of a designer during any design process is to be an advocate for the user. This role becomes even more crucial when persuasion techniques are intentionally used in design, since users may be unaware of the persuasion tactics. Even worse, some users may not be capable to detect these tactics, as may be the case with children, seniors or other vulnerable users.
BJ Fogg provides six factors that give interactive technologies an advantage over users when it comes to persuasion:
Persuasive intent is masked by novelty
The web and email are no longer novel, and most of us have wizened up to deceptive web practices and the promises of Nigerian Princes, but we still find novelty in new mobile apps, voice interfaces, AR, VR. Not too long ago, the craze with Pokémon Go raised many ethical questions.
Positive reputation of new technology
While “It must be true — I saw it on the Internet” is now a punchline, users are still being persuaded to like, comment, share, retweet, spread challenges, and make fake news or bot generated content viral.
Would you like a used car salesman following you around after your first visit, continually trying to sell you a car? While that thankfully does not happen in real life, your apps and devices are with you all the time, and the ding and glowing screen have the ability to persistently persuade us, even in places and times that may be otherwise inappropriate. This past Lent, my son took a break from his mobile device. When he started it after Easter, he had hundreds of past notifications and alerts from one mobile game offering all sorts of reminders and incentives to come back and use it.
Control over how the interaction unfolds
Unlike human persuasion, where the person being persuaded has the ability to react and change course, technology has predefined options, controlled by the creators, designers and developers. When designing voice interfaces, creators have to define what their skill will be able to do, and for everything else come back with a “Sorry I can’t help with that”. Just last month, a social network blocked access to their mobile website, asking me to install their app to access their content, without an escape or dismiss option.
Can affect emotion while still being emotionless
New technology doesn’t have emotion. Even with the recent advances in Artificial Intelligence, machines do not feel emotion like humans do. Back to the Google Duplex assistant call mentioned at the beginning, issues can arise when people are not aware that the voice at the other end is just an emotionless machine, and treat it as another person just like them.
Cannot take responsibility for negative outcomes of persuasion
What happens when something goes wrong, and the app or the technology cannot take responsibility? Do the creators shoulder that responsibility, even if their persuasion strategies have unintended outcomes, or if misused by their partners? Mark Zuckerberg accepted responsibility for the Cambridge Analytica scandal before and during the congress hearings.
With these unfair advantages at our disposal, how do we, as creators, designers, and developers make ethical choices in our designs and solutions? For one, take a step back and consider the ethical implication and impact of our work, and then take a stand for our users.
AIGA, the largest professional membership organization for design, has a series on Design Business and Ethics. Design Professionalism author Andy Rutledge also created a Professional Code of Conduct. Both are very detailed and cover the business of design, but not specifically ethics related to design that impacts or influences human behavior.
Other professionals who impact the human mind have ethical principles and codes of conduct, like those published by the American Psychological Association and the British Psychological Society. The purpose of these codes of conduct is to protect participants as well as the reputation of psychology and psychologists themselves. When using psychology in our designs, we could examine how the ethical principles of psychologists are applicable to our work as creators, designers, and developers.
Principles And Questions
Using the Ethical Principles of Psychologists as a framework, I defined how each principle applies to persuasive design and listed questions related to ethical implications of design. These are by no means exhaustive but are intended to be food for thought in each of these areas. Note: When you see ‘design’ in the questions below, it refers to persuasive techniques used in your design, app, product or solution.
Principle A: Beneficence And Nonmaleficence
Do no harm. Your decisions may affect the minds, behavior, and lives of your users and others around them, so be alert and guard against misusing the influence of your designs.
Does your design change the way people interact for the better?
Does the design aim to keep users spending time they didn’t intend to?
Does the design make it easy to access socially unacceptable or illegal items that your users would not have easy access to otherwise?
How may your partners (including third-party tools and SDKs) or “bad guys” misuse your design, unknown to you?
Would you be comfortable with someone else using your design on you?
Would you like someone else to use this design to persuade your mother or your child?
Principle B: Fidelity And Responsibility
Be aware of your responsibility to your intended users, unintended users and society at large. Accept appropriate responsibility for the outcomes of your design.
During design, follow up answers to “How might we…?” with “At what cost?”
What is the impact of your design/product/solution? Who or what does it replace or impact?
If your design was used opposite from your intended use, what could the impact be?
Does your design change social norms, etiquette or traditions for the better?
Promote accuracy, honesty, and truthfulness in your designs. Do not cheat, misrepresent or engage in fraud. When deception may be ethically justifiable to maximize benefits and minimize harm, carefully consider the need for, the possible consequences of, and be responsible for correcting any resulting mistrust or other harmful effects that arise from the use of such techniques.
Do you need users’ consent? When asking for their consent, are they aware of what exactly they are consenting to?
What’s the intent of the design? Is it in the best interest of the user or the creator? Are you open and transparent about your intentions?
Does your design use deception, manipulation, misrepresentation, threats, coercion or other dishonest techniques?
Are users aware or informed if they are being monitored, or is it covert?
Is your design benefiting you or the creators at the expense of your users?
What would a future whistleblower say about you and your design?
Principle D: Justice
Exercise reasonable judgment and take precautions to ensure that your potential biases, the limitations of your expertise does not lead to, or condone unjust practices. Your design should benefit both the creators and users.
Does your design contain any designer biases built in (gender, political, or other)?
Does your design advocate hate, violence, crime, propaganda?
If you did this in person, without technology, would it be considered ethical?
What are the benefits to the creators/business? What are the benefits to the users? Are the benefits stacked in favor of the business?
Do you make it easy for users to disconnect? Do users have control and the ability to stop, without being subject to further persuasion through other channels?
Principle E: Respect For People’s Rights And Dignity
Respect the dignity and worth of all people, and the rights of individuals to privacy, and confidentiality. Special safeguards may be necessary to protect the rights and welfare of vulnerable users.
If you have been designing with white hat techniques, you may appreciate the ethical issues discussed here. However, if you have been designing in the grey or black area, thank you for making it all the way to the end. Ethics in persuasive design are important because they don’t prey on the disadvantages users have when it comes to interactive technology. As creators, designers, and developers, we have a responsibility to stand up for our users.
You’ve heard the marketing mantra a bazillion times: people do business with people they know, like, and trust. Nowhere is this truer than on your About Page. When people click on your About Page, they want to get to know you. It’s a golden chance, and possibly your only chance, to impress them. You must strive to woo them so they fall in love with you and your brand. And, once they do, like and trust you enough to do business with you. But that’s easier said than done. The plain truth is most About Pages suck. They’re so bland and…
Form design matters more than you might think. A poorly designed form can turn off prospects, whether you’re asking them to sign up for your email list or buy your latest product. Web forms are used on nearly every website on the Internet, but some feature extremely poor design. If you don’t want to fall into that trap, this article will teach you how to design forms that boost conversion rates. Feel free to jump around if you’re interested in a single a particular topic covered in this article: What’s a web form? Why do you need a web form?…
There has been a surge of conversations about the tech industry lacking diversity. Companies are therefore encountering barriers in innovation. The current state of technology faces inequality and privilege, a consequence of having limited voices represented in the design and product development process. In addition, we live in a challenged political and socio-economic state where it’s easier to be divided than come together despite differences.
Design’s role in companies is becoming less about visual appeal and more about hitting business goals and creating value for users. Therefore, the need to build teams with diverse perspectives is becoming imperative. Design will not only be critical to solving problems on the product and experience level, but also relevant on a bigger scale to close social divides and to create inclusive communities.
Creating a team who can work well together across different disciplines can be hard. Rachel Andrew solicits some suggestions from the speakers at our upcoming SmashingConf in Toronto. Read article →
What Is Diversity And Why Is It Important?
Diversity is in perspectives and values, which are influenced by both inherit traits (such as ethnicity, gender, age, sexual orientation) as well as acquired traits that are gained from various life experiences (cultural influences, education, social circle, etc.). A combination of traits shape people’s identity and the way they think.
In particular, conflicts and adversities experienced by people have a significant influence on how they develop their values. The more an individual has stepped outside their comfort zone, the more unique of a perspective they bring to the table and an expanded capacity to be compassionate towards others.
Diversity is important because it directly affects long-term success, innovation, and growth. Advantages of working on a diverse team include increased collaboration, effective communication, well-rounded sets of skills represented, less susception to complacency, and active efforts for inclusivity are made earlier in the process.
What Is The Competing Values Framework?
The positive correlation between diversity and innovation are undeniable. So how exactly does it work? Having differing and oftentimes clashing perspectives on a team seems to hinder progress rather than drive it. But with the right balance of values, this dynamic is extremely advantageous. Design, as a problem-solving discipline, uses insights to drive innovation, which can only manifest between differences, not commonalities. When different perspectives and values are represented, blind spots become more apparent and implicit biases are challenged.
This is illustrated in the Competing Values Framework, a robust blueprint that was devised by Quinn and Rohrbaugh, based on researching qualities of companies that have sustainably produced a steady stream of innovative solutions over the years. This model for organizational effectiveness shows how different perspectives translate into business values, as well as show where their weaknesses are.
These are categorized into “quadrants” as follows:
People with characteristics from the Collaborate quadrant are committed to cooperating together based on shared values. They foster trust with each other and with their audience through compassion and empathy. Their priorities are long-term growth of communities and commit to learning and mentoring. While a sense of unity might help a team be more purpose-driven, this can discourage individuals who think differently to bring new ideas to the table because they are averse to taking risks. People here also lose sight of the realities of constraints because they look too far ahead.
While most people are hesitant to change and innovation, those in this quadrant embrace it. They’re extremely flexible with a shifting landscape of user and business goals and aren’t afraid of taking risks. Creatives see risk as an opportunity for growth and embrace different ways of thinking to come up with solutions. Trends are set by creatives, not followed. In contrast, however, those in this quadrant aren’t as logical and practical with the execution needed to bring ideas to life. Their flexibility can become chaotic and unpredictable. Taking risks can pay off significantly but it’s more detrimental without a foundation.
As the name implies, people here are competitive and focus on high performance and big results. They’re excellent decision makers, which is why they get things done quickly. They know exactly how to utilize resources around them to beat competitors and get to the top of the market. Competitors stay focused on the business objectives of increasing revenue and hitting target metrics. On the other hand, they’re not as broad of a visionary in the long run. Since they prioritize immediate results. Because of this, they may not be as compassionate towards their audience and not consider the human side of company growth.
People in this quadrant focus on creating systems that are reliable and efficient. They’re practical and can plan strategically for scaling, and they constantly revisit their design processes to optimize for productivity. They are extremely detail oriented and can identify areas of opportunities in the unexpected. They’re also experts at dealing with multiple moving parts and turn chaos into harmony. But if there are too many Control qualities on a team, they become vulnerable to falling into complacency since they depend on reliable systems. They are averse to taking risks and fear the nature of unpredictability.
People and their values don’t always neatly fit into categories but this framework is flexible in helping teams identify their strengths and weaknesses. Many individuals have traits that cover more than one quadrant but there are definitely dominant qualities. Being able to identify what they are on an individual level, as well as within a team and at the company level is important.
How Do We Use The CVF To Build Diverse Teams?
There are already many great design processes and frameworks that takes aspects of the CVF to help teams take advantage of diverse perspectives. The sprint model, developed by the design partners at Google Ventures, is an excellent workflow that brings together differing values and skill sets to solve problems, with an emphasis on completing it in a short amount of time. IDEO’s design thinking process, also referred to human-centered design, puts users at the forefront and drive decisions with empathy with collaboration being at the core.
The CVF complements many existing design processes to help teams bring their differing perspectives together and design more holistically. In order to do this, teams need to evaluate where they are, how to fit in the company and how well that aligns with their priorities. They should also identify the missing voices and assess areas for improvement. They need to be asking themselves,
What has the team dynamic been like for the past year? What progress has been made? What goals (business/user/team) are the most important?
The Competing Values Framework assessment is a practical way to (1) establish the desired organizational outcomes and goals, (2) evaluate the current practices of teams within the organization/company and how they manage workflows, and (3) the individual’s role and how they fit into the context of the team and company.
For example, a team that may not have had many roadblocks and disagreements may represent too much of the Collaborate quadrant and need people who represent more of the Compete quadrant to drive results. A team that has taken risks has had failures, and has dealt with many moving parts (Create) may need people who have characteristics of the Control quadrant for stability and scaling on a practical level to drive results and growth.
If teams can expand by hiring more, they should absolutely onboard more innovators who bring different perspectives and strengths. But teams should also keep in mind that it’s absolutely possible to work with what they already have and can utilize resources at their disposal. Here are some practical ways that teams can increase diversity:
Hire For Diversity
When hiring, it’s important to find people with unique perspectives to complement existing designers and stakeholders. Writing inclusive job descriptions to attract a wider range of candidates makes a big difference. Involving people from all levels and backgrounds within the company who are willing to embrace new perspectives is essential. Hiring managers should ask thoughtful questions to gage how well candidates exercise their problem-solving skills and empathy in real-life business cases. Not making assumptions about others, even with something simple like their pronouns, can establish safe work environments and encourage people to be open about their views and values.
Step Outside The Bubble
Whether this would be directly for client work or for building team rapport, it’s valuable to get people out of the office to experience things outside of their familiar scope. It’s worthwhile for design teams to interact with users and spend time in their shoes, not only for their own work as UX practitioners but also to help expand their worldview. They should be encouraged to constantly learn something new. They should be given opportunities to travel to places that are completely different from their comfort zone. Teams should also be encouraged go to design events and learn from industry experts who do similar work but in different contexts. Great ideas emerge when people experience things outside their routine and therefore, should always get out and learn!
Drive Diversity Initiatives Internally
Hosting in-house hackathons to get teams to interact differently allows designers to expand their skills while learning new approaches to problem solving. It is also an opportunity to work with people from other teams and acquire the skills to adapt quickly. Bringing in outside experts to share their wisdom is a great way for teams to learn new ways of thinking. Some companies, especially larger organizations, have communities based on interests outside of work such as the love for food or interest in outdoors activities. Teaching each other skills through internal workshops is also great.
Foster A Culture Of Appreciation
Some companies have weekly roundtable session where each person on the team shares one thing he or she is appreciative about another person. Not only does this encourage high morale but also empowers teams to produce better work. At the same time, teams are given a safe space to be vulnerable with each other and take risks. This is an excellent way to bond over goals and get teams with differing perspectives together to collaborate.
What Should Diverse Teams Keep In Mind?
Acknowledging that while different ideas and values are important, they can clash if conversations are not managed effectively. Discrimination and segregation can happen. But creating a workspace and team dynamic that is open to discussion and a safe space to challenge existing ideas is crucial. People should be open to being challenged and ask questions, rather than get defensive about their ideas. Compromise will be necessary in this process.
When diversity isn’t managed actively, or there is an imbalance of values on a team, several challenges arise:
Communication barriers — How people say things can be different from how others hear and understand them. Misunderstandings could lead to crucial voices not always being heard. If a particular style of communication is accepted over others, people fear speaking up. They might hold the wisdom to make design decisions that could impact the business. If a culture of openness doesn’t exist, a lot of those gold mines never get their opportunities to see the light of day.
Discrimination and segregation — As teams become more diverse, people can stray away from or avoid others who think differently. This can lead to increased feelings of resentment, leading to segregation and even discrimination. People might be quick to judge one another based on stereotypical references, rather than mustering the courage to understand where they come from.
Competition over collaboration — People on design teams need to work collaboratively but when different perspectives clash and aren’t encouraged to use their perspectives to create value for the company, they become competitive against each other rather than have the willingness to work together. It’s important to bring the team back to the main goal.
Embracing different perspectives takes courage but it’s everyone’s responsibility to be mindful of one another. Being surrounded by people with different perspectives is certainly uncomfortable and can be a stretch outside their comfort zones. Design teams are positioned advantageously to do so and be role models to others on its impact. Conversations about leveraging differing perspectives should happen as early in the process as possible to limit friction and encourage effective collaboration.
Conclusion And Next Steps
Rather than approach it as an obligation and something with a lot of risk, leaders should see it as a benefit to their company and team’s growth. It is often said that roadblocks are a sign of innovation. Therefore, when designers in a team are faced with challenges, they are able to innovate. And only through the existence different perspectives can such challenges emerge. Assessing where the company, teams, and individuals are within the CVF quadrants is a great start and taking steps to building a team with complementing perspectives will be key to driving long-term innovation.
I’d like to personally thank the following contributors for taking their time to providing me with insights on hiring for and building diverse design teams: Samantha Berg, Khanh Lam, Arin Bhowmick, Rob Strati, Shannon O’Brien, Diego Pulido, Nathan Gao, Christopher Taylor Edwards, among many others who engaged in discussions with me on this topic. Thank you for allowing me to take your experiences and being part of facilitating this dialogue on the value of diversity in design.
As designers, we know that research should play a pivotal role in any design process. Sadly, however, there are still a lot of organizations that do not see the value of research and would rather jump straight into the visual design stage of the design process.
The excuses given here tend to be:
“We already know what our customers want.”
“We don’t have the time/budget/people.”
“We’ll figure out the flaws in BETA.”
As designers, it is important that we are equipped to be able to have conversations with senior stakeholders to be able to sell and justify the importance of the so-called “Design Discovery” within the design process.
In this article, I’ll demystify what is meant by the term “Design Discovery” to help you better establish the importance of research within the creative process. I’ll also be giving advice on how to handle common pushbacks, along with providing various hints and tips on how to select the best research methods when undertaking user research.
My hope is that by reading this article, you will become comfortable with being able to sell “Design Discovery” as part of the creative process. You will know how to build a “Discovery Plan” of activities that answers all the questions you and your client need to initiate the design process with a clear purpose and direction.
Design With A Purpose
Digital design is not just about opening up Photoshop or Sketch and adding colors, shapes, textures, and animation to make a beautiful looking website or app.
As designers, before putting any pixels on canvas, we should have a solid understanding of:
Who are the users we are designing for?
What are the key tasks those users want to accomplish?
Ask yourself, is the purpose of what you are producing? Is it to help users:
Maintain a healthy lifestyle,
Or something entirely different?
Understanding the answers to these questions should inform your design decisions. But before we design, we need to do some research.
Any design process worth its salt should start with a period of research, which (in agency terms) is often referred to as a “Discovery Phase”. The time and budget designers can allocate to a Discovery phase is determined by many factors such as the amount of the client’s existing project research and documentation as well as the client’s budget. Not to mention your own personal context, which we will come to later.
Business And User Goals
In a Discovery phase, we should ensure adequate time is dedicated to exploring both business and user goals.
Yes, we design experiences for users, but ultimately we produce our designs for clients (be that internal or external), too. Clients are the gatekeepers to what we design. They have the ultimate say over the project and they are the ones that hold the purse strings. Clients will have their own goals they want to achieve from a project and these do not always align with the users’ goals.
In order to ensure what we design throughout our design process hits the sweet spot, we need to make sure that we are spending time exploring both the business and user goals for the project (in the Research/Discovery phase).
Uncovering Business Goals
Typically, the quickest way to establish the business goals for a project is to host a stakeholder workshop with key project stakeholders. Your aim should be to get as many representatives from across different business functions as possible into one room to discuss the vision for the project (Marketing, Finance, Digital, Customer Services, and Sales).
Tip: Large organizations often tend to operate in organizational silos. This allows teams to focus on their core function such as marketing, customer care, etc. It allows staff to be effective without being distracted by activities where they have no knowledge and little or no skills. However, it often becomes a problem when the teams don’t have a singular vision/mission from leadership, and they begin to see their area as the driving force behind the company’s success. Often in these situations, cross-departmental communication can be poor to non-existent. By bringing different members from across the organization together in one room, you get to the source of the truth quicker and can link together internal business processes and ways of working.
The core purpose of the stakeholder workshop should be:
To uncover the Current State (explore what exists today in terms of people, processes, systems, and tools);
To define the Desired Future State (understand where the client wants to get to, i.e. their understandig of what the ideal state should look like);
To align all stakeholders on the Vision for the project.
There are a series of activities that you can employ within your stakeholder workshop. I tend to typically build a full workshop day (7-8 hours) around 4-5 activities allowing 45mins uptil 1 hour for lunch and two 15-min coffee breaks between exercises. Any more that than, and I find energy levels start to dwindle.
I will vary the workshop activities I do around the nature of the project. However, each workshop I lead tends to include the following three core activities:
Explore who the business feels their users are and what are the key user stories we need to deliver against.
Tip:If you’re new to delivering client workshops, I’ve added a list of recommended reading to the references section at the bottom of this article which will give you useful ideas on workshop activities, materials, and group sizes.
Following the workshop, you’ll need to produce a write up of what happened in the workshop itself. It also helps to take lots of photos on the workshop day. The purpose of the write-up should be to not only explain the purpose of the day and key findings, but also recommendations of next steps. Write-ups can be especially helpful for internal communication within the organization and bringing non-attendees up to speed with what happened on the day as well as agreeing on the next steps for the project.
Uncovering User Goals
Of course, Discovery is not just about understanding what the organization wants. We need to validate what users actually want and need.
With the business goals defined, you can then move on to explore the user goals through conducting some user research. There are many different user research methods you can employ throughout the Discovery process from Customer Interviews and Heuristic Evaluations to Usability Tests and Competitor Reviews, and more.
Having a clear idea of the questions you are looking to answer and available budget is the key to helping select the right research methods. It is, for this reason, important that you have a good idea of what these are before you get to this point.
Before you start to select which are the best user research methods to employ, step back and ask yourself the following question:
“What are the questions I/we as a design team need answers to?”
For example, do you want to understand:
How many users are interacting with the current product?
How do users think your product compares to a competitor product?
What are the most common friction points within the current product?
How is the current product’s performance measured?
Do users struggle to find certain key pieces of information?
Grab a pen and write down what you want to achieve from your research in a list.
Tip: If you know you are going to be working on a fixed/tight budget, it is important to get confirmation on what that budget may look like at this point since this will have some bearing on the research methods you choose.
Another tip: User research does not have to happen after organizational research. I always find it helps to do some exploratory research prior to running stakeholder workshops. This ensures you go into the room with a baseline understanding of the organization its users and some common pain points. Some customers may not know what users do on their websites/apps nowadays; I like to go in prepared with some research to hand whether that be User Testing, Analytics Review or Tree Testing outputs.
Selecting Research Methods
The map below from the Nielsen Norman Group (NNG) shows an overview of 20 popular user research methods plotted on a 3-dimensional framework. It can provide a useful guide for helping you narrow down on a set of research methods to use.
The diagram may look complicated, but let us break down some key terms.
Along the x-axis, research methods are separated by the types of data they produce.
Quantitative data involves numbers and figures. It is great for answering questions such as:
Qualitative data involves quote, observations, photos, videos, and notes.
What do users think?
How do users feel?
Why do users behave in a certain way?
What are users like?
What frustrates users?
Along the y-axis, research methods are separated by the user inputs.
This data is based on what users do (outcomes).
This data is based on attitudes and opinions.
Finally, research methods are also classified by their context. Context explains the nature of the research, some research methods such as interviews require no product at all. Meanwhile, usability tests require users to complete scripted tasks and tell us how they think and feel.
Using the Model
Using your question list, firstly identify whether you are looking to understand users opinions (what people say) or actions (what people do) and secondly whether you are looking to understand why they behave in a certain way (why and how to fix) or how many of them are behaving in a certain way (how many and how much).
Now look at this simplified version of the matrix, and you should be able to work out which user research methods to focus in on.
If you’re looking to understand users’ attitudes and beliefs and you don’t have a working product then ‘Focus Groups’ or ‘Interviews’ would be suitable user research methods.
If you want to understand how many users are interacting with the current website or app then an ‘Analytics Review’ would be the right research method to adopt. Meanwhile, if you want to test how many people will be impacted by a change, A/B testing would be a suitable method.
No Silver Bullet
By now you should realize there is no shortcut to the research process; not one single UX research method will provide all the answers you need for a project.
Analytics reviews, for example, are a great low-cost way to explore behavioral, quantitative data about how users interact with an existing website or application.
However, this data falls short of telling you:
Why users visited the site/app in the first place (motivation);
What tasks they were looking to accomplish (intent);
If users were successful in completing their tasks (task completion);
How users found their overall experience (satisfaction).
These types of questions are best answered by other research methods such as ‘Customer Feedback’ surveys (also known as ‘Intercept Surveys’) which are available from tools such as Hotjar, Usabilla, and Qualaroo.
In order to build a holistic view of the user experience, the Research/Discovery process should typically last around 3 to 4 weeks and combine a combination of the different research methods.
Use your list of questions and the NNG matrix to help you decide on the most suitable research methods for your project. Wherever possible, try to use complimentary research methods to build a bigger picture of users motivations, drivers, and behaviors.
Tip: The UX Recipe tool is a great website for helping you pull together the different research methods you feel you need for a project and to calculate the cost of doing so.
Which brings me on to my next point.
Contexts And Budgets
The time and budget which you can allocate to Discovery will vary greatly depending on your role. Are you working in-house, freelance, or in an agency? Some typical scenarios are as follows:
Clients employ agencies to build projects that generate the right results. To get the right results, you firstly need to ensure you understand both the business’ needs and the needs of the users as these are almost always not the same. Agencies almost always start with a detailed Discovery phase often led by the UX Design team. Budgets are generally included in the cost of the total project, as such ample time is available for research.
In-House: Large Company
When working in a large company, you are likely to already have a suite of tools along with a program of activity you’re using to measure the customer experience. Secondly, you are likely to be working alongside colleagues with specialist skills such as Data Analysts, Market Researchers, and even a Content Team. Do not be afraid to say hello to these people and see if they will be willing to help you conduct some research. Customer service teams are also worth befriending. Customer service teams are the front line of a business where customer problems are aired for all to see. They can be a goldmine of useful information. Go spend some time with the team, listen to customer service calls, and review call/chat logs.
In-House: Smaller Company
When working as part of an in-house team in a smaller company, you are likely to be working on a tight budget and are spread across a lot of activities. Nevertheless, with some creative thinking, you can still undertake some low-cost research tasks such as Site Intercept surveys, Analytics reviews, and Guerilla testing, or simply review applied research.
When working freelance, your client often seeks you out with a very fixed budget, timeline and set of deliverables in mind, i.e. “We need a new Logo” or “We need a landing page design.” Selling Discovery as part of the process can often be a challenge freelancers typically undertake since they mostly end up using their own time and even working overtime. But it doesn’t have to be like this. Clients can be willing to spend their time in the Discovery pre-project phase. However, you need to be confident to be able to sell yourself and defend your process. This video has some excellent tips on how to sell Discovery to clients as a freelancer.
Selling Design Discovery
As you can see from the above, selling Design Discovery can be a challenge depending on your context. It’s much harder to sell Design Discovery when working as a freelancer than it is working within an agency.
Some of the most commons excuses organizations put forward for discounting the research process are:
“We don’t have the budget.”
“We’ll find it out in BETA.”
“We don’t have time.”
“We already know what users want.”
When selling Design Discovery and combating these points of view, remember these key things:
It doesn’t have to be expensive.
Research does not have to be costly especially with all of the tools and resources we have available today. You can conduct a Guerilla User Testing session for the price of a basic coffee. Furthermore, you can often source willing participants from website intercepts, forums or social media groups who are more than willing to help.
It’s much harder to fix later.
The findings that come as an output from research can be invaluable. It is much more cost and time effective to spend some of the project budgets up front to ensure there are no assumptions and blind spots than it is to course correct later on if the project has shifted off tangent. Uncovering blockers or significant pain points later into the project can be a huge drain on time as well as monetary resources.
Organizational views can often be biased.
Within large organizations especially, a view of ‘what users want’ is often shaped by senior managers’ thoughts and opinions rather than any applied user research. These viewpoints then cascade down to more junior members of the team who start to adopt the same viewpoints. Validating these opinions are actually correct viewpoints is essential.
There are other cross-company benefits.
Furthermore, a Discovery process also brings with it internal benefits. By bringing members from other business functions together and setting a clear direction for the project, you should win advocates for the project across many business functions. Everyone should leave the room with a clear understanding of what the project is, its vision, and the problems you are trying to fix. This helps to alleviate an enormous amount of uncertainty within the organization.
I like to best explain the purpose of the discovery phase by using my adaptation of the Design Squiggle by Damien Newman:
See how the Discovery phase allows us time to tackle the most uncertainty?
Waterfall And Agile
A Discovery phase can be integrated into both Waterfall and Agile project management methodologies.
In Waterfall projects, the Discovery phase happens at the very start of the project and can typically run for 4 to 12 weeks depending on the size of the project, the number of interdependent systems, and the areas which need to be explored.
In Agile projects, you may run a Discovery phase upfront to outline the purpose for the project and interconnect systems along with mini 1 to 2-week discovery process at the start of each sprint to gather the information you need to build out a feature.
The next time you start on any digital project:
Make sure you allow time for a Discovery phase at the start of your project to define both business and user goals, and to set a clear vision that sets a clear purpose and direction for the project to all stakeholders.
Be sure to run a Stakeholder workshop with representatives from a variety of different business functions across the business (Marketing, Finance, Digital, Customer Services, Sales).
Before selecting which user research methods to use on your project, write down a list of questions you wish to understand and get a budget defined. From there, you can use the NNG matrix to help you understand what the best tool to use is.
If you found this article interesting, here is some recommended further reading:
If you are interested in running Stakeholder workshops, I’d highly recommend reading the following books. Not only will they give you useful hints and tips on how to run workshops, they’re packed full of different workshop exercises to help you get answers to specific questions.
CSS Custom Properties (sometimes known as ‘CSS variables’) are now supported in all modern browsers, and people are starting to use them in production. This is great, but they’re different from variables in preprocessors, and I’ve already seen many examples of people using them without considering what advantages they offer.
How Are They Similar To Variables In Preprocessors?
Custom Properties are a little bit like variables in preprocessors but have very some important differences. The first and most obvious difference is the syntax.
With SCSS we use a dollar symbol to denote a variable:
In Less we use an @ symbol:
Custom properties follow a similar conventions and use a -- prefix:
One important difference between custom properties and variables in preprocessors is that custom properties have a different syntax for assigning a value and retrieving that value. When retrieving the value of a custom property we use the var() function.
The next most obvious difference is in the name. They are called ‘custom properties’ because they really are CSS properties. In preprocessors, you can declare and use variables almost anywhere, including outside declaration blocks, in media rules, or even as part of a selector.
Most of the examples above would be invalid using custom properties.
Custom properties have the same rules about where they can be used as normal CSS properties. It’s far better to think of them as dynamic properties than variables. That means they can only be used inside a declaration block, or in other words, custom properties are tied to a selector. This can be the :root selector, or any other valid selector.
You can retrieve the value of a custom property anywhere you would otherwise use a value in a property declaration. This means they can be used as a single value, as part of a shorthand statement or even inside calc() equations.
However, they cannot be used in media rules, or selectors including :nth-child().
There is probably a lot more you want to know about the syntax and how custom properties work, such as how to use fallback values and can you assign variables to other variables (yes), but this basic introduction should be enough to understand the rest of the concepts in this article. For more information on the specifics of how custom properties work, you can read “It’s Time To Start Using Custom Properties” written by Serg Hospodarets.
Dynamic vs. Static
Cosmetic differences aside, the most significant difference between variables in preprocessors and custom properties is how they are scoped. We can refer to variables as either statically or dynamically scoped. Variables in preprocessors are static whereas custom properties are dynamic.
Where CSS is concerned static means that you can update the value of a variable at different points in the compilation process, but this cannot change the value of the code that came before it.
Once this is rendered to CSS, the variables are gone. This means that we could potentially read an .scss file and determine it’s output without knowing anything about the HTML, browser or other inputs. This is not the case with custom properties.
Preprocessors do have a kind of “block scope” where variables can be temporarily changed inside a selector, function or mixin. This changes the value of a variable inside the block, but it’s still static. This is tied to the block, not the selector. In the example below, the variable $background is changed inside the .example block. It changes back to the initial value outside the block, even if we use the same selector.
Custom properties work differently. Where custom properties are concerned, dynamically scoped means they are subject to inheritance and the cascade. The property is tied to a selector and if the value changes, this affects all matching DOM elements just like any other CSS property.
@media screen and (min-width: 600px)
We don’t have to change where the custom property is used — we change the value of the custom property with CSS. This means using the same custom property, we can have different values in different places or context on the same page.
Global vs. Local
CSS is similar. We have some things that are applied globally and some things that are more local. Brand colors, vertical spacing, and typography are all examples of things you might want to be applied globally and consistently across your website or application. We also have local things. For example, a button component might have a small and large variant. You wouldn’t want the sizes from these buttons to be applied to all input elements or even every element on the page.
CSS Custom Properties are by default locally scoped to the specific selectors we apply them to. So they are kinda like local variables. However, custom properties are also inherited, so in many situations they behave like global variables — especially when applied to the :root selector. This means that we need to be thoughtful about how to use them.
So many examples show custom properties being applied to the :root element and although, this fine for a demo, it can result in a messy global scope and unintended issues with inheritance. Luckily, we’ve already learned these lessons.
Global Variables Tend To Be Static
There are a few small exceptions, but generally speaking, most global things in CSS are also static.
Global variables like brand colors, typography and spacing don’t tend to change much from one component to the next. When they do change this tends to be a global rebranding or some other significant change that rarely happens on a mature product. It still makes sense for these things to be variables, they are used in many places, and variables help with consistency. But it doesn’t make sense for them to be dynamic. The value of these variables does not change in any dynamic way.
For this reason, I strongly recommend using preprocessors for global (static) variables. This not only ensures that they are always static, but it visually denotes them within the code. This can make CSS a whole lot more readable and easier to maintain.
Local Static Variables Are OK (Sometimes)
You might think given the strong stance on global variables being static, that by reflection, all local variables might need to be dynamic. While it’s true that local variables do tend to be dynamic, this is nowhere near as strong as the tendency for a global variable to be static.
Locally static variables are perfectly OK in many situations. I use preprocessors variables in component files mostly as a developer convenience.
Consider the classic example of a button component with multiple size variations.
Obviously, this example would make more sense if I was using the variables multiple times or deriving margin and padding values from the size variables. However, the ability to quickly prototype different sizes might be a sufficient reason.
Because most static variables are global, I like to differentiate static variables that are used only inside a component. To do this, you can prefix these variables with the component name, or you could use another prefix such as c-variable-name for component or l-variable-name for local. You can use whatever prefix you want, or you can prefix global variables. Whatever you choose, it’s helpful to differentiate especially if converting an existing codebase to use custom properties.
When To Use Custom Properties
I suspect we will always use some form of static variables, although we might need fewer in future, as custom properties offer new ways to organise logic and code. Until then, I think in most situations we are going to be working with a combination of preprocessor variables and custom properties.
It’s helpful to know that we can assign static variables to custom properties. Whether they are global or local, it makes sense in many situations to convert static variables, to locally dynamic custom properties.
Note: Did you know that $var is valid value for a custom property? Recent versions of Sass recognize this, and therefore we need to interpolate variables assigned to custom properties, like this: #$var. This tells Sass you want to output the value of the variable, rather than just $var in the stylesheet. This is only needed for situations like custom properties, where a variable names can also be a valid CSS.
If we take the button example above and decide all buttons should use the small variation on mobile devices, regardless of the class applied in the HTML, this is now a more dynamic situation. For this, we should use custom properties.
Here I create a single custom property: --button-size. This custom property is initially scoped to all button elements using the btn class. I then change the value of --button-size above 600px for the classes btn-med and btn-lrg. Finally, I apply this custom property to all button elements in one place.
Don’t Be Too Clever
The dynamic nature of custom properties allows us to create some clever and complicated components.
With the introduction of preprocessors, many of us created libraries with clever abstractions using mixins and custom functions. In limited cases, examples like this are still useful today, but for the most part, the longer I work with preprocessors the fewer features I use. Today, I use preprocessors almost exclusively for static variables.
Custom properties will not (and should not) be immune from this type of experimentation, and I look forward to seeing many clever examples. But in the long run, readable and maintainable code will always win over clever abstractions (at least in production).
I read an excellent article on this topic on the Free Code Camp Medium recently. It was written by Bill Sourour and is called “Don’t Do It At Runtime. Do It At Design Time.” Rather than paraphrasing his arguments, I’ll let you read it.
One key difference between preprocessor variables and custom properties is that custom properties work at runtime. This means things that might have been borderline acceptable, in terms of complexity, with preprocessors might not be a good idea with custom properties.
One example that illustrated this for me recently was this:
This generates a modular scale. A modular scale is a series of numbers that relate to each other using a ratio. They are often used in web design and development to set font-sizes or spacing.
In this example, each custom property is determined using calc(), by taking the value of the previous custom property and multiplying this by the ratio. Doing this, we can get the next number in the scale.
This means the ratios are calculated at run-time and you can change them by updating only the value of the --font-scale property. For example:
@media screen and (min-width: 800px)
This is clever, concise and much quicker than calculating all the values again should you want to change the scale. It’s also something I would not do in production code.
Although the above example is useful for prototyping, in production, I’d much prefer to see something like this:
Similar to the example in Bill’s article, I find it helpful to see what the actual values are. We read code many more times than we write it and global values such as font scales change infrequently in production.
The above example is still not perfect. It violates the rule from earlier that global values should be static. I’d much prefer to use preprocessor variables and convert them to locally dynamic custom properties using the techniques demonstrated earlier.
It is also important to avoid situations where we go from using one custom property to a different custom property. This can happen when we name properties like this.
Change The Value Not The Variable
Change the value not the variable is one of the most important strategies for using custom properties effectively.
As a general rule, you should never change which custom property is used for any single purpose.
It’s easy to do because this is exactly how we do things with preprocessors, but it makes little sense with custom properties.
In this example, we have two custom properties that are used on an example component. I switch from using the value of --font-size-small to --font-size-large depending on the screen size.
Finally, in a single place, I use the value of this custom property:
In this example and others before it, media queries have only been used to change the value of custom properties. You might also notice there is only one place where the var() statement is used, and regular CSS properties are updated.
This separation between variable declarations and property declarations is intentional. There are many reasons for this, but the benefits are most obvious when thinking about responsive design.
Responsive Design With Custom Properties
One of the difficulties with responsive design when it relies heavily on media queries is that the no matter how you organize your CSS, styles relating to a particular component become fragmented across the stylesheet.
It can be very difficult to know what CSS properties are going to change. Still, CSS Custom Properties can help us organize some of the logic related to responsive design and make working with media queries a lot easier.
If It Changes It’s A Variable
Properties that change using media queries are inherently dynamic and custom properties provide the means to express dynamic values in CSS. This means that if you are using a media query to change any CSS property, you should place this value in a custom property.
You can then move this, along with all the media rules, hover states or any dynamic selectors that define how the value changes, to the top of the document.
Separate Logic From Design
When done correctly, separation of logic and design means that media queries are only be used to change the value of custom properties. It means all the logic related to responsive design should be at the top of the document, and wherever we see a var() statement in our CSS, we immediately know that this property that changes. With traditional methods of writing CSS, there was no way of knowing this at a glance.
Many of us got very good at reading and interpreting CSS at a glance while tracking in our head which properties changed in different situations. I’m tired of this, and I don’t want to do this anymore! Custom properties now provide a link between logic and its implementation, so we don’t need to track this, and that is incredibly useful!
The Logic Fold
The idea of declaring variables at the top of a document or function is not a new idea. It’s something we do in most languages, and it’s now something we can do in CSS as well. Writing CSS in this way creates a clear visual distinction between CSS at the top of the document and below. I need a way to differentiate these sections when I talk about them and the idea of a “logic fold” is a metaphor I’ve started using.
Above the fold contains all preprocessor variables and custom properties. This includes all the different values a custom property can have. It should be easy to trace how a custom property changes.
CSS below the fold is straightforward and highly declarative and easy to read. It feels like CSS before media queries and other necessary complexities of modern CSS.
Take a look at a really simple example of a six column flexbox grid system:
We immediately know --row-display is a value that changes. Initially, it will be block, so the flex values will be ignored.
This example is fairly simple, but if we expanded it to include a flexible width column that fills the remaining space, it’s likely flex-grow, flex-shrink and flex-basis values would need to be converted to custom properties. You can try this or take a look at a more detailed example here.
Custom Properties For Theming
I’ve mostly argued against using custom properties for global dynamic variables and hopefully implied that attaching custom properties to the :root selector is in many cases considered harmful. But every rule has an exception, and for custom properties, it’s theming.
Limited use of global custom properties can make theming a whole lot easier.
Theming generally refers to letting users customize the UI in some way. This could be something like changing colors on a profile page. Or it might be something more localized. For example, you can choose the color of a note in the Google Keep application.
Theming usually involves compiling a separate stylesheet to override a default value with user preferences, or compiling a different stylesheet for each user. Both of these can be difficult and have an impact on performance.
With custom properties, we don’t need to compile a different stylesheet; we only need to update the value of properties according to the user’s preferences. Since they are inherited values, if we do this on the root element they can be used anywhere in our application.
Capitalize Global Dynamic Properties
Custom properties are case sensitive and since most custom properties will be local, if you are using global dynamic properties, it can make sense to capitalize them.
Capitalization of variables often signifies global constants. For us, this is going to signify that the property is set elsewhere in the application and that we should probably not change it locally.
Avoid Directly Setting Global Dynamic Properties
Custom properties accept a fallback value. It can be a useful to avoid directly overwriting the value of a global custom properties and keep user values separate. We can use the fallback value to do this.
The example above sets the value of --THEME-COLOR to the value of --user-theme-color if it exists. If --user-theme-color is not set, the value of #d33a2c will be used. This way, we don’t need to provide a fallback every time we use --THEME-COLOR.
You might expect in the example below that the background will be set to green. However, the value of --user-theme-color has not been set on the root element, so the value of --THEME-COLOR has not changed.
--THEME-COLOR: var(--user-theme-color, #d33a2c);
Indirectly setting global dynamic properties like this protects them from being overwritten locally and ensures user settings are always inherited from the root element. This is a useful convention to safeguard your theme values and avoid unintended inheritance.
If we do want to expose specific properties to inheritance, we can replace the :root selector with a * selector:
--THEME-COLOR: var(--user-theme-color, #d33a2c);
Now the value of --THEME-COLOR is recalculated for every element and therefore the local value of --user-theme-color can be used. In other words, the background color in this example will be green.
Here I set a default value for --note-color and scope this to the .note component. I keep the variable declaration separate from the property declaration, even in this simple example.
const elm = document.querySelector('#note-uid');
I then target a specific instance of a .note element and change the value of the --note-color custom property for that element only. This will now have higher specificity than the default value.
You can see how this works with this example using React. These user preferences could be saved in local storage or in the case of a larger application perhaps in a database.
Manipulating Color With Custom Properties
In addition to hex values and named colors, CSS has colors function such as rgb() and hsl(). These allow us to specify individual components of a color such as the hue or lightness. Custom properties can be used in conjunction with color functions.
background: hsl(var(--hue), 80%, 50%);
This is useful, but some of the most widely used features of preprocessors are advanced color functions that allow us to manipulate color using functions like lighten, darken or desaturate:
It would be useful to have some of these features in browsers. They are coming, but until we have native color modification functions in CSS, custom properties could fill some of that gap.
We’ve seen that custom properties can be used inside existing color functions like rgb() and hsl() but they can also be used in calc(). This means that we can convert a real number to a percentage by multiplying it, e.g. calc(50 * 1%) = 50%.
background: hsl(25, 80%, calc(var(--lightness) * 1%));
The reason we want to store the lightness value as a real number is so that we can manipulate it with calc before converting it to a percentage. For example, if I want to darken a color by 20%, I can multiply its lightness by 0.8. We can make this a little easier to read by separating the lightness calculation into a locally scoped custom property:
Custom properties also allow as to move some of the complexity of theming into the CSS and this complexity can have a negative impact on the maintainability of your CSS, so remember to keep it simple wherever possible.
Using Custom Properties Today
Even if you’re supporting IE10 and 11, you can start using custom properties today. Most of the examples in this article have to do with how we write and structure CSS. The benefits are significant in terms of maintainability, however, most of the examples only reduce what could otherwise be done with more complex code.
I use a tool called postcss-css-variables to convert most of the features of custom properties into a static representation of the same code. Other similar tools ignore custom properties inside media queries or complex selectors treating custom properties much like preprocessor variables.
Loading The Correct Stylesheet
There are many ways you can use postCSS. I use a gulp process to compile separate stylesheets for newer and older browsers. A simplified version of my gulp task looks like this:
import gulp from "gulp";
import sass from "gulp-sass";
import postcss from "gulp-postcss";
import rename from "gulp-rename";
import cssvariables from "postcss-css-variables";
import autoprefixer from "autoprefixer";
import cssnano from "cssnano";
gulp.task("css-no-vars", () =>
.pipe(rename( extname: ".no-vars.css" ))
gulp.task("css", () =>
.pipe(rename( extname: ".css" ))
This results in two CSS files: a regular one with custom properties (styles.css) and one for older browsers (styles.no-vars.css). I want IE10 and 11 to be served styles.no-vars.css and other browsers to get the regular CSS file.
Normally, I’d advocate using feature queries but IE11 doesn’t support feature queries and we’ve used custom properties so extensively that serving a different stylesheet makes sense in this case.
Intelligently serving a different stylesheet and avoiding a flash of unstyled content is not a simple task. If you don’t need the dynamic features of custom properties, you could consider serving all browser styles.no-vars.css and using custom properties simply as a development tool.
If you want to take full advantage of all the dynamic features of custom properties, I suggest using a critical CSS technique. Following these techniques, the main stylesheet is loaded asynchronously while the critical CSS is rendered inline. Your page header might look something like this:
We can extend this to load either styles.css or styles.no-vars.css depending on whether the browser supports custom properties. We can detect support like this:
if ( window.CSS && CSS.supports('color', 'var(--test)') )
If you’ve been struggling to organize CSS efficiently, have difficulty with responsive components, want to implement client-side theming, or just want to start off on the right foot with custom properties, this guide should tell you everything you need to know.
It comes down to understanding the difference between dynamic and static variables in CSS as well as a few simple rules:
Separate logic from design;
If a CSS property changes, consider using a custom property;
Change the value of custom properties, not which custom property is used;
Global variables are usually static.
If you follow these conventions, you will find that working with custom properties is a whole lot easier than you think. This might even change how you approach CSS in general.
Redesigning A Digital Interior Design Shop (A Case Study)
Good products are the result of a continual effort in research and design. And, as it usually turns out, our designs don’t solve the problems they were meant to right away. It’s always about constant improvement and iteration.
I have a client called Design Cafe (let’s call it DC). It’s an innovative interior design shop founded by a couple of very talented architects. They produce bespoke designs for the Indian market and sell them online.
DC approached me two years ago to design a few visual mockups for their website. My scope then was limited to visuals, but I didn’t have the proper foundation upon which to base those visuals, and since I didn’t have an ongoing collaboration with the development team, the final website design did not accurately capture the original design intent and did not meet all of the key user needs.
A year and a half passed and DC decided to come back to me. Their website wasn’t providing the anticipated stream of leads. They came back because my process was good, but they wanted to expand the scope to give it space to scale. This time, I was hired to do the research, planning, visual design and prototyping. This would be a makeover of the old design based on user input and data, and prototyping would allow for easy communication with the development team. I assembled a small team of two: me and a fellow designer, Miroslav Kirov, to help run proper research. In less than two weeks, we were ready to start.
Useful tip: I always kick off a project by talking to the stakeholders. For smaller projects with one or two stakeholders, you can blend the kick-off and the interview into one. Just make sure it’s no longer than an hour.
Our two stakeholders are both domain experts. They have a brick-and-mortar store in the center of Bangalore that attracts a lot of people. Once in there, people are delighted by the way the designs look and feel. Our clients wanted to have a website that conveys the same feeling online and that would make its visitors want to go to the store.
There wasn’t a clear distinction between new, returning and potential clients.
DC’s selling points weren’t clearly communicated.
They had future plans for transforming the website into a hub for interior design ideas. And, last but not least, DC wanted to attract fresh design talent.
Defining the Goals
We shortlisted all of our goals for the project. Our main goal was to explain in a clear and appealing manner what DC does for existing and potential clients in a way that engages them to contact DC and go to the store. Some secondary goals were:
lower the drop-off rate,
capture some customer data,
clarify the brand’s message,
make the website responsive,
explain budgets better,
provide decision-making assistance and become an information influencer.
Our number-one key metric was to convert users to leads who visit the store, which measures the main goal. We needed to improve that by at least 5% initially — a realistic number we decided on with our stakeholders. In order to do that, we needed to:
shorten the conversion time (time needed for a user to get in touch with DC),
increase the form application rate,
increase the overall satisfaction users get from the website.
We would track these metrics by setting up Google Analytics Events once the website is online and by talking with leads who come into the store through the website.
Useful tip: Don’t focus on too many metrics. A handful of your most important ones are enough. Measuring too many things will dilute the results.
In order for us to gain the best possible insights, our user interviews had to target both previous and potential clients, but we had to go minimal, so we picked two potential and three existing clients. They were mostly from the IT sector — DC’s main target group. Given our pretty tight schedule, we started with desk research while we waited for all five user interviews to be scheduled.
Useful tip: You need to know who you are designing for and what research has been done before. Stakeholders tell you their story, but you need to compare it to data and to users’ opinions, expectations and needs.
We could reference some Google Analytics data from the website:
Most users went to the kitchen, then to the bedroom, then to the living room.
The high bounce rate of 80%+ was probably due to a misunderstanding of the brand message and unclear flows and calls to action (CTAs).
Traffic was mostly mobile.
Most users landed on the home page, 70% of them from ads and 16% directly (mostly returning customers), and the rest were equally divided between Facebook and Google Search.
90% of social media traffic came from Facebook. Expanding brand awareness to Instagram and Twitter could be beneficial.
There’s a lot of local competition in the sector. Here were some repeating patterns:
video spots and elaborate galleries showing the completed designs with clients discussing their services;
attractive design presentations with high-quality photos;
targeting of group’s appropriate messages;
quizzes for picking styles;
big bold typography, less text and more visuals.
DC’s customers are mostly aged between 28 and 40, with a secondary set in the higher bracket of 38 and 55 who come for their second home. They are IT or business professionals with a mid to high budget. They value good customer experience but are price-conscious and very practical. Because they are mostly families, very often the wives are the hidden dominant decision-maker.
We talked with five users (three existing and two potential customers) and sent out a survey to 20 more (mixing existing and potential customers; see Design Cafe Questionnaire).
Useful tip: Be sure to schedule all of your interviews ahead of time, and plan for more people than you need. Include extreme users along with the mainstreams. Chances are that if something works for an extreme user, it will work for the rest as well. Extremes will also give you insight about edge cases that mainstreams just don’t care about.
All users were confused about the main goal of the website. Some of their opinions:
“It lacks a proper flow.”
“I need more clarity in the process, especially in terms of timelines.”
“I need more educational information about interior design.”
Everyone was pretty well informed about the competition. They had tried other companies before DC. All found out about DC by either a reference, Google, ads or by physically passing by the store. And, boy, did they love the store! They treated it like an Apple Store for interior design. Turns out that DC really did a great job with that.
Useful tip: Negative feedback helps us find opportunities for improvement. But positive feedback is also pretty useful because it helps you identify which parts of the product are worth retaining and building upon.
Personal touch, customer service, prices and quality of materials were their main motivations for choosing DC. People insisted on being able to see the price of every element on a page at any time (the previous design didn’t have prices on the accessories).
We made an interesting but somehow expected discovery about device usage. Mobile devices were used mostly for consumption and browsing, but when it came to ordering, most people opened their laptops.
The survey results mostly overlapped with the interviews:
Users found DC through different channels, but mainly through referrals.
They didn’t quite understand the current state of the website. Most of them had searched for or used other services before DC.
All of the surveyed users ordered kitchen designs. Almost all had difficulty choosing the right design style.
Most users found the process of designing their own interior hard and were interested in features that could make their choice easier.
Useful tip: Writing good survey questions takes time. Work with a researcher to write them, and schedule double the time you think you’ll need.
User Journeys Overview
Talking with customers helped us gain useful insight about which scenarios would be most important to them. We made an affinity diagram with everything we collected and started prioritizing and combining items in chunks.
The result was seven point-of-view problem statements that we decided to design for:
A new customer needs more information about DC because they need proof of credibility.
A returning customer needs quick access to the designs because they don’t want to waste time.
All customers need to be able to browse the designs at any time.
All customers want to browse designs relevant to their tastes, because that will shorten their search time.
Potential leads need a way to get in touch with DC in order to purchase a design.
All customers, once they’ve ordered, need to stay up to date with their order status, because they need to know what they are paying for and when they will be getting it.
All customers want to read case studies about successful projects, because that will reassure them that DC knows its stuff.
Using this list, we came up with design solutions for every journey.
The previous home page of Design Cafe was confusing. It needed to present more information about the business. The lack of information caused confusion and people were unsure what DC is about. We divided the home page into several sections and designed it so that every section could satisfy the needs of one of our target groups:
For new visitors (the purple flow), we included a short trip through the main unique selling points (USPs) of the service, the way it works, some success stories and an option to start the style quiz.
For returning visitors (the blue flow), who will most likely skip the home page or use it as a waypoint, the hero section and the navigation pointed a way out to browsing designs.
We left a small part at the end of the page (the orange flow) for potential employees, describing what there is to love about DC and a CTA that goes to the careers page.
The whole point of the onboarding process was to capture the customer’s attention so that they could continue forward, either directly to the design catalog or through a feature we called the style quiz.
We made the style quiz to help users narrow down their results.
DC previously had a feature called a 3D builder that we decided to remove. It allowed you to set your room size and then drag-and-drop furniture, windows and doors into the mix. In theory, this sounds good, but in reality people treated it much like a game and expected it to function like a minified version of The Sims’ Build Mode.
Everything made with the 3D builder was ending up completely modified by the designers. The tool was giving people a lot of design power and too many choices. On top of that, supporting it was a huge technical endeavor because it was a whole product on its own.
Compared to it, the style quiz was a relatively simple feature:
It starts out by asking about colors, textures and designs you like.
It continues to ask about room type.
Eventually, it displays a curated list of designs based on your answers.
The whole quiz wizard extends to only four steps and takes less than a minute to complete. But it makes people invest a tad bit of their time, thus creating engagement. The result: We’re improving conversion time and overall satisfaction.
Alternatively, users can skip the style quiz and go directly to the design catalog, then use the filters to fine-tune the results. The page automatically shows kitchen designs, what most people are looking for. And for the price-conscious, we made a small feature that allows them to input their room’s size, and all prices are recalculated.
If people don’t like anything from the catalog, chances are they are not DC’s target customer and there’s not much we can do to keep them on the website. But if they do like a design, they could decide to go forward and get in touch with DC, which brings us to the next step in the process.
Getting in Touch
Contacting DC needed to be as simple as possible. We implemented three ways to do that:
through the chat, shown on every page — the quickest way;
by opening the contact page and filling out the form or by just calling DC on the phone;
by clicking “Book a consultation” in the header, which asks for basic information and requests an appointment (upon submission, the next steps are shown to let users know what exactly is going to happen).
The rest of this journey continues offline: Potential customers meet a DC designer and, after some discussions and planning, place an order. DC notifies them of any progress via email and sends them a link to the progress tracker.
The progress tracker is in a user menu in the top-right corner of the design. Its goal is to show a timeline of the order. Upon an update, an “unread” notification pops out. Most users, however, will usually find out about order updates through email, so the entry point for the whole flow will be external.
Once the interior design order is installed and ready, users will have the completed order on the website for future reference. Their project could be featured on the home page and become part of the case studies.
One of DC’s long-term goals is for its website to become an influencer hub for interior design, filled with case studies, advice and tips. It’s part of a commitment to providing quality content. But DC doesn’t have that content yet. So, we decided to start that section with minimal effort and introduce it as a blog. The client would gradually fill it up with content and detailed process walkthroughs. These would be later expanded and featured on the home page. Case studies are a feature that could significantly increase brand awareness, though they would take time.
Preparing for Visual Design
With the critical user journeys all figured out and wireframed, we were ready to delve into visual design.
Data showed that most people open the website on their phones, but interviews proved that most of them were more willing to buy through a computer, rather than a mobile device. Also, desktop and laptop users were more engaged and loyal. So, we decided to design for desktop-first and work down to the smaller (mobile) resolutions from it in code.
We started collecting visual ideas, words and images. Initially, we had a simple word sequence based on our conversations with the client and a mood board with relevant designs and ideas. The main visual features we were after were simplicity, bold typography, nice photos and clean icons.
Useful tip: Don’t follow a certain trend just because everybody else is doing it. Create a thorough mood board of relevant reference designs that approximate the look and feel you’re going after. This look should be in line with your goals and target audience.
Our client had already started working on a photo shoot, and the results were great. Stock photography would have ruined everything personal about this website. The resulting photos blended with the big type pretty well and helped with that simple language we were after.
Initially, we went with a combination of Raleway and Roboto for the typography. Raleway is a great font but a bit overused. The second iteration was Abril Fatface and Raleway for the copy. Abril Fatface resembles the splendor of Didot and made the whole page a lot more heavy and pretentious. It was an interesting direction to explore, but it didn’t resonate with the modern techy feel of DC. The last iteration was Nexa for the titles, which turned out to be the best choice due to its modern and edgy feel, with Lato — both a great fit.
Useful tip: Play around with type variations. List them side by side to see how they compare. Go to Typewolf, MyFonts or a similar website to get inspired. Look for typefaces that make sense for your product. Consider readability and accessibility. Don’t go overboard with your type scale; keep it as minimal as possible. Check out Butterick’s summary of key rules if in doubt.
DC already had a color scheme, but they gave us the freedom to experiment. The main colors were tints of cyan, golden and plum (or, rather, a strange kind of bordeaux), but the original hues were too faded and didn’t blend with each other well enough.
Useful tip: If the brand already has colors, test slight variations to see how they fit the overall design. Or remove some of the colors and use only one or two. Try designing your layout in monochrome and then test different color combinations on an already mocked-up design. Check out some other great tips by Wojciech Zieliński in his article “How to Use Colors in UI Design: Practical Tips and Tools”.
Here’s what we decided on in the end:
The way we presented all of those type variants and colors was through iterations on the home page.
We focused the first visual iteration on getting the main information clearly visible and squeezing the most out of the testimonials and style quiz sections. After some discussion, we figured it was too plain and needed improvement. We made changes to the fonts and icons and modified some sections, shown in iterations 2 and 3 in the image below.
We didn’t have the time to design custom icons, but the NounProject came to the rescue. With the SVG file format, it’s very simple to change whatever you need and mix it with something else. This sped up our work immensely, and with visual iteration number 4, we signed off on the design of the home page. This allowed us to focus on components and use them as LEGO blocks to build the templates.
I listed most components (see PDF) in a Sketch artboard to keep them accessible. Whenever the design needed a new pattern, we’d come back to this page and look for ways to reuse elements. Having a visual system in place, even for a small project like this, kept things consistent and simple.
Useful tip: Components, atoms, blocks — no matter what you call them, they are all part of systematic thinking about your design. Design systems help you gain a deeper understanding of your product by urging you to focus on patterns, design principles and design language. If you’re new to this approach, check out Brad Frost’s Atomic Design or Alla Kholmatova’s Design Systems.
Prototyping With Code
For our prototype, we decided to use code and set up a simple build process to speed up our work.
Picking tools and processes
Gulp automated everything. If you haven’t heard of it, check out Callum Macrae’s awesome guide. Gulp enabled us to handle all of the styles, scripts and templates, and it outputs a ready-to-use minified production version of the code.
Some of the more important Gulp plugins we used were:
This allows you to use PostCSS. You can bundle it with plugins like cssnext to get a pretty robust and versatile setup.
This sets up a server and automatically updates the view on every change. You can set it to fire up upon starting “gulp watch”, and everything will be synced up on hitting “Save”.
This is a Handlebars implementation for Gulp. It’s a quick way to create templates and reuse them. Imagine you have a button that stays the same throughout the whole design. It would be a symbol in Sketch. It’s basically the same concept but wrapped in HTML. Whenever you want to use that button, you just include the button template. If you change something in the master template, it propagates the changes to every other button in the design. You do that for everything in the design system, and thus you’re using the same paradigm for both visual design and code. No more static page mockups!
Components and templates
We had to mix atomic CSS with module-based CSS to get the most of both worlds. Atomic CSS handled all of the general styles, while the CSS modules handled edge cases.
In atomic CSS, atoms are immutable CSS classes that do just one thing. We used Tachyons, an atomic toolkit. In Tachyons, every class you apply is a single CSS property. For instance, .b stands for font-weight: bold, and .ttu stands for text-transform: uppercase. A paragraph with bold uppercase text would look like this:
<p class="b ttu">Paragraph</p>
Useful tip: Once you get familiar with atomic CSS, it becomes a blazingly fast way to prototype stuff — and a very systematic one, because it urges you to constantly think about reusability and optimization.
A major benefit of prototyping with code is that you can demo complex interactions. We coded most of our critical journeys this way.
Useful tip: With HTML prototypes, you will have to decide the level of fidelity you want to achieve. That might get pretty time-consuming if you go too deep. But you can’t really go wrong with that either because as you go deeper and deeper into the code and fine-tune every possible detail, at some point you’ll start delivering the actual product.
Clients, especially small B2C companies, love when you deliver a design solution that they can use immediately. We shipped just that.
Unfortunately, you can’t always predict a project’s pace, and it took several months for our code to be integrated in DC’s workflow. In its current state, this code is ready for testing, and what’s better is that it’s pretty easy to modify. So, if DC decides to conduct some user tests in the future, any changes will be easy to make.
Collaborate with other designers whenever possible. When two people are thinking about the same problem, they will deliver better ideas. Take turns in taking notes during interviews, and brainstorm goals, ideas and visuals together.
We shipped a working version of the website, and the client was able to use it right away. If you aren’t able to sign off on the code, try to get as close to the final product as possible, and communicate that visually to your client’s team. Document your design — it’s a deliverable that will be used and abused by everyone, from developers to marketers to in-house designers. Set aside some time to make sure all of your ideas are properly understood by everyone.
Scheduling interviews and writing good surveys can be time-consuming. You have to plan ahead and recruit more people than you think you will need. Hire an experienced researcher to work with you on these tasks, and spend some time with your team to identify your goals. Be careful when sourcing participants. Your client can help you find the right people, but you’ll need to stick to participants who meet the right demographics.
Schedule enough time for planning. Project goals, processes, and responsibilities should be clear to everyone on your team. You need time to allow for multiple iterations on prototypes, because prototypes improve products quickly. If you don’t want to mess with code, there are various ways to prototype. But even if you do, you don’t need to write flawless code — just write designer’s code. Or, as Alan Cooper once said, “Sometimes the best way for a designer to communicate their vision is to code something up so that their colleagues can interact with the proposed behavior, rather than just see still images. The goal of such code is not the same as the goal of the code that coders write. The code isn’t for deployment, but for design [and] its purpose is different.”
Don’t focus on a unique design per se, unless that’s the main feature of your product. Better to spend time on things that matter more. Use frameworks, icons and visual assets where possible, or outsource them to another designer and focus on your core product goals and metrics.
Full-day workshop • April 19th In this workshop, Mark Boulton will guide you through the practical design techniques that make a difference. From learning how to crop a photograph to guide a viewers eyes, to being able to typeset a data table for optimum scanning by a reader. This is a very practical workshop. You’ll end the day with a design you are proud of and a new toolbox of design techniques to use tomorrow.