small_Fcsqb5pWQAAzPIK.jpeg

thumbnail_Fcsqb5pWQAAzPIK.jpeg

Adobe acquires Figma, cue the memes 🤪

large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

Still can’t get a UX job? Give up.

large_featuredImage

medium_featuredImage

small_featuredImage

thumbnail_featuredImage

Sticking to UI/UX trends is a losing strategy

<p><a href="http://ift.tt/2oaNaUB">medium bookmark / Raindrop.io</a> |  </p>
<div>
<p><strong><em>A brief introduction: </em></strong><em>I’m Marcin: a former UX manager and now co-founder and CEO at </em><a href="http://uxpin.com/"><em>UXPin — the full stack UX design platform</em></a><em>. In this series of posts, I’m reporting on UXPin’s journey of creating our own design system. We went through </em><a href="http://ift.tt/2odJuAq"><em>the reasons to build a design system</em></a><em>, </em><a href="http://ift.tt/2oTkVc4"><em>building a design inventory</em></a><em>, </em><a href="http://ift.tt/2oVpunb"><em>setting-up a unified color palette</em></a><em> and</em><a href="http://ift.tt/2peOiqp"><em> managing the basic style properties</em></a><em>. Today we’re going to take a step back and strengthen the foundation of our design system with design principles.</em></p>
<p>Right after <a href="http://ift.tt/2peOiqp">setting up the basic style properties</a> for our growing design system, our design operations team stammered. We wanted to move forward and clean up the typography, creating a crystal-clear typographic scale with corresponding Less mixins and variables. However, more fundamental questions started to pile up:</p>
<ul>
<li>How to choose the right patterns across different patterns playing the same role in different parts of the product (including headlines)?</li>
<li>How to make design decisions consistent across different patterns and parts of the design system?</li>
<li>How best to bring consistency to ongoing projects without waiting for a subsequent release of the system? And communicate that need to the product team?</li>
</ul>
<p>The more we engaged with these fundamental questions the more overwhelmed we started to feel.</p>
<p>This feeling of being trapped in design decision-making, reminded me of our late 2015 efforts to bring a completely new visual aesthetic to <a href="http://uxpin.com/">UXPin</a>.</p>
</div>
<div>
<div>
<div><img src="http://ift.tt/2osLD8B" alt="1*2d2vaeI-PIzagsYurLQYpA.png"></div>
</div>
<p><a href="http://uxpin.com/">UXPin</a> new aesthetic introduce in 2015/2016 as a result of using set of design principles</div>
<div>
<h3>Establishing Design Principles — The Process</h3>
<p>Working on the new version of UXPin back in 2015 brought a ton of design-process challenges. We had to coordinate the efforts of multiple designers and developers, multiple simultaneous feedback sources (usability tests, customer service feedback, sales feedback, analytics, multivariable split tests) and, of course, the differing opinions of stakeholders.</p>
<p>Our design team quickly agreed what kind of architectural changes we want to make. Our decisions were based on extensive user research and we knew exactly what we expected to see in the new interface. The aesthetic of this new interface was quite a different story.</p>
<p>The main visual designer on the project and I had a different sense of beauty. On every design review, we would end up in a subjective discussion of taste. It was leading us nowhere. To overcome this challenge, we decided to bring our discussion to a higher level and talk about principles. We used a simple process to establish our design principles:</p>
<ol>
<li><strong>Find product analogies.</strong> Start by discussing principles through reference to familiar products, outside of your product category (for example, don’t refer your SaaS aplication to other SasS applications — this is going to trigger mindless copying instead of designing). Do you want your product to feel like a white Porsche, or a red Ferrari? Do you want it to resemble a classic Braun audio systems, or maybe you feel that it should be more like an airplane’s cockpit? Start listing these analogies and think about the reason behind every choice.</li>
<li><strong>Find design principles in analogous products. </strong>Go through your list of product analogies and think what makes these products the way they are? Do they bring a feeling of familiarity? Intuitiveness? Or perhaps they indicate endless possibilities through richness of options? List the reasons you think every analogous product is the right choice.</li>
<li><strong>Make the list real with existing user research. </strong>Go through the list of reasons for your choices and mark those that you can connect to existing user research results. Did users complain about bloated interface and you would like your product to be as simple as an original iPod? Did users point that not all the critical features are easily accessible and you were thinking about building something that brings in the qualities of an air-fighter cockpit? Mark those references for user research (ideally link to research results and sources).</li>
<li><strong>Build value statements</strong>. Take your analogies and reasons then sort them, starting with the most frequently mentioned by users. Eliminate those that were not mentioned by users <strong>and</strong> you consider them not important (if you deeply care for something not mentioned in the research — keep it). Try to rewrite the list by formulating value statements: We want our product to be like [ <em>complete with your product analogy</em>], because it [<em>complete with the reason</em>] and it’s important to [<em>our users/me/us</em>]. For example: “We want our product to be like a white Porsche 911 from the 80s, because it brings the feeling of timeless quality and it’s important to us”, or “We want our product to be like Harman Kardon Soundstick Speakers, because they’re modern and minimalistic and our customers mentioned frequently that our product is looks dated and interface is bloated with unnecessary functions”. You get the idea.</li>
<li><strong>Abstract your principles. </strong>Now simply take all your value statements and remove product reference (you can keep it in a description) to make design principles more universal.</li>
</ol>
<p>After completing these five simple steps our design principles were ready to go! Here’s the final list:</p>
<p><strong>UXPin Design Principles</strong></p>
<p>1. <strong>No distractions</strong>. Every redundant piece of the interface (lines, buttons, shadows, animations) is a source of distraction. As such, should be eliminated to empower users’ creativity with well architected and inspiring design tool.</p>
<p>2. <strong>Design centric</strong>. Users’ designs should lie at the center of UXPin. Our interface should be unobtrusive to the point of transparency.</p>
<p>3. <strong>Adaptive interface.</strong> UXPin’s interface should act according to the context of use. All the ‘inactive’ features should remain completely hidden until user can use them (no inactive buttons and links!)</p>
<p>4. <strong>Space</strong>. UXPin’s interface should create a peaceful atmosphere, triggering creativity of users. This ambience can be shaped by leaving a lot of space around every piece of interface. Cluttered interface is the source of stress that produces cortisol and adrenaline,both blocks our creative powers.</p>
<p>5. <strong>Inspiration</strong>. UXPin design should inspire and, as such, can’t be a derivative of design of other SaaS apps. We should strive for an original aesthetic inspired by the best products ever created (some of the sources of our inspiration: Fountain Pen <a href="http://ift.tt/1ZBaGCw">Pilot Vanishing Point Matte Black</a>, <a href="http://ift.tt/1qFVbuA">speakers Harman Kardon Sound Stick</a>,<a href="http://ift.tt/1ZBbTcS"> record player Pro-ject</a>, <a href="http://ift.tt/28nv5kl">speakers DALI Zensor</a>).</p>
<p>6. <strong>Interactive</strong> <strong>Consistency</strong>. Interface components, icons, fonts should all be consistent to create predictable experience.</p>
<p>7. <strong>Predictable Architecture</strong>. Architecture of UXPin must be predictable and natural. Features should be placed in the right context to be easy to discover by new users. Example of predictable architecture: settings of canvas should be placed next to the canvas.</p>
<p>We started to use these design principles as a benchmark for our design decisions and a tool to measure ourselves against during design reviews. For example, we would ask ourselves whether a particular interface solution is predictable enough from the architecture point of view and whether it interferes in a negative way with users’ design project. Design principles provided quick feedback throughout the design process.</p>
<p>We also used these principles to explain our decisions to the entire team and stakeholders. Design Principles are extremely useful to lay out foundation of design decision-making without going into too many confusing details. Quoting after <a href="http://ift.tt/1fyOUb8">Luke Wroblewski</a>:</p>
<blockquote><p>“Design principles are the guiding light for any software application. They define and communicate the key characteristics of the product to a wide variety of stakeholders including clients, colleagues, and team members. Design principles articulate the fundamental goals that all decisions can be measured against and thereby keep the pieces of a project moving toward an integrated whole.”</p></blockquote>
<p>Our principles were extremely important to bringing a new aesthetic to UXPin and they quickly became an integral part of the way we think about UXPin interface. All the subsequent projects reflected the line of thinking expressed in our principles even if we weren’t referring to them directly during our design reviews.</p>
<p>Design principles started to work on a subconscious level, which was fine, until we had to make more fundamental design decisions. Decisions that are going to affect the entire product interface. In this new context, we started to face familiar disagreements. Somehow, subconscious process working well during project work, failed us during the work at the design system.</p>
<p>To face this new challenge, we had to bring our design principles back to our consciousness and remind the team of them. We had to centralize our design principles and make sure they prevail not only across all the projects, but also across all the parts of our Design System. How one can achieve? It’s simple — <strong>design principles have to become part of the design system</strong>.</p>
</div>
<div>
<div>
<div><img src="http://ift.tt/2osRZor" alt="1*lSrXSeYMiKKdxB7lBTCaOg.png"></div>
</div>
<p>UXPin Design Principles are stored with other parts of our Design System</p></div>
<div>
<h3>Design Principles in Design Systems</h3>
<p>By now you can tell that we love design principles. At UXPin it’s a proven weapon against:</p>
<ul>
<li>Endless subjective discussion</li>
<li>Unclear design requirements</li>
<li>Inconsistency at the most fundamental level</li>
</ul>
<p>Somehow though, most of design systems do not include design principles at all. According to our research, just slightly above 40% of publicly available systems include design principles.</p>
</div>
<div>
<div>
<div><img src="http://ift.tt/2oaL3Ad" alt="1*yXIH3A0GefK8Py8a6qLiog.jpeg"></div>
</div>
</div>
<div>
<p>Among these 40% we have some of the most comprehensive design systems:</p>
<p><a href="http://ift.tt/2iAvRbu">Salesforce Lightning Design System</a> includes set of universal, high level design principles:</p>
<ul>
<li>Clarity</li>
<li>Efficiency</li>
<li>Consistency</li>
<li>Beauty</li>
</ul>
</div>
<div>
<div>
<div><img src="http://ift.tt/2oaXRqn" alt="1*s_6yIw7QQyb_Hpc_XjuIgA.png"></div>
</div>
<p>Design Principles in <a href="http://ift.tt/2iAvRbu">Salesforce Lightening Design System</a></div>
<div>
<p><a href="http://ift.tt/2hP4JmB">Google Material Design</a> approach to design principles is very minimalistic and focused on what makes Material Design so unique as an universal design system. Their principles are:</p>
<ul>
<li>Material is the metaphor</li>
<li>Bold, graphic, intentional</li>
<li>Motion provides meaning</li>
</ul>
</div>
<div>
<div>
<div><img src="http://ift.tt/2oaSEi4" alt="1*cjxKV4vbZKRjeC479U6XBg.png"></div>
</div>
<p><a href="http://ift.tt/2hP4JmB">Google Material Design</a> — Design Principles</div>
<div>
<p><a href="http://ift.tt/2gyVeKn">Apple iOS</a> has a very detailed and specific set of principles:</p>
<ul>
<li>Aesthetic Integrity</li>
<li>Consistency</li>
<li>Direct Manipulation</li>
<li>Feedback</li>
<li>Metaphors</li>
<li>User Control</li>
</ul>
</div>
<div>
<div>
<div><img src="http://ift.tt/2osDUaw" alt="1*w62wTB-Ldqsn3Ga0fR8Q1w.png"></div>
</div>
<p><a href="http://ift.tt/2gyVeKn">Apple iOS</a> design principles</div>
<div>
<p>As you can see approaches to building a set of design principle varies a lot. From a set of rules defining what Material Design truly is, through set of inspiring (and aspirational) statements in Salesforce Lightning System to precise and strict definition of a good design in iOS Human Guidelines.</p>
<p>UXPin’s set of principles lies somewhere in the middle. Some of our principles point at specific design decisions that are expected from all of our interfaces (e.g. the principle of predictable architecture, which asks for placement of actions in the familiar context), other have more general nature and aim at inspiring (e.g. the principle of inspiration).</p>
<p>So which approach to design principles is the right one?</p>
<h3>What are good design principles?</h3>
<p>One canonical approach to design principles does not exist. Good principles are the ones that are meaningful to the team using them. As anything organized, or managed by design operations team, design principles reason to exist is to serve users and product organization (order intended!). If your team fundamentally refuses to use the set of principles, or just simply ignores them, they lose the entire value. While working on design principles, you have to check with the team and <em>test</em> usefulness of what you prepared.</p>
<p>If you and your team feel unsure about the general direction worth taking, <a href="http://ift.tt/17VWCc6">Julie Zhuo</a> created <a href="http://ift.tt/1QOkWqA">an ingenious set of heuristics for a good set of design principles</a>:</p>
<blockquote><p>“A good set of design principles, on the other hand, does the following:</p></blockquote>
<blockquote><p>1. Helps resolve practical and real-world questions around specific design decisions.</p></blockquote>
<blockquote><p>2. Applies to an entire class of design decisions, both things we can think of today, as well as questions that will pop up in the future.</p></blockquote>
<blockquote><p>3. Imparts a human-oriented sense of “why?” that is easy for everybody — including non-designers — to understand.</p></blockquote>
<blockquote><p>4. Has a point of view and a sense of prioritization that a rational person could disagree with.</p></blockquote>
<blockquote><p>5. Is generally paired with illustrative examples that show how the principle applies to specific decisions.”</p></blockquote>
<p>Controversial? Maybe. Challenging? Definitely, yes. But after all we want our principles to be as challenging as possible, and Julie’s approach helps make them as sharp as possible.</p>
<h3>Summary</h3>
<p>While Design Principles are not the most typical part of the design system, I highly encourage you to consider them. Nothing sets a better foundation and guides the team through a creation and continuous implementation of a design system than a set of meaningful design principles.</p>
</div>
<div><a href="http://ift.tt/2oaNaUB">http://ift.tt/2oaNaUB</a></div>


Design System Sprint 4: Design Principles

Design System Sprint 4: Design Principles

Top Stories