A good design system should cover all components and all of their states (e.g. placeholder, value, hover, focus, error, disabled). Not only should you design each of these states so they can be built and documented, but having a symbol for each state (of a component) is also very useful for easy application when documenting a product flow or interaction […]
But what about when you have dozens of system components, each with several different states… You could end up with hundreds of symbols! This may seem hard to manage, but it’s not. Enter nested symbols and what I’ve been calling ‘control symbols’ and ‘variable symbols’.
This is easily the killer feature in Sketch and a really interesting idea — one that goes way deeper than the very basic way I have been using symbols. I’ve been envisioning a boilerplate Sketch file that I can use to start any project, but I wasn’t sure how to set it up so that stylistic changes to foundational components would be pushed across an entire design system. This may be the silver bullet. Thanks for sharing, Andrew!
I recently completed work on an enterprise design system. The story was a familiar one: our client had both built and acquired many products over the years, and they all looked and behaved differently. And not in good ways.
This was my first time on a design system project. I have of course designed style guides, pattern libraries, and sticker sheets in the past, but these deliverables are different in that they are typically created after the fact. This time, the design system work began well in advance of product redesign and development work.
I learned (and even re-learned) some things. Maybe you’ll find them useful.
A design system is an expansive undertaking, and our client’s first concern was what it should look like. That’s natural; one of the more obvious benefits of a design system is a cohesive style. It’s a highly attractive feature, especially if there is a lot of inconsistency in the current product.
Everyone has a different level of experience with design; one client may be able to look at something generalized or abstract — like style tiles or element collages — and easily fill in the blanks. Another client may require something more literal, like seeing full mockups of a few of their existing screens before they feel okay with signing off on a stylistic direction. It’s important to have a conversation with the client, show them examples of what you can do for them to establish the visual direction, and pick the approach that fits their needs.
I didn’t have a conversation with my client about this, which was super dumb of me. I simply told the client I would be creating element collages, and showed them some examples of what they were. I didn’t give them a choice, assuming the output would be just what we needed given the time we had. We were under pressure to quickly move into component creation (but when is design not pushed to go faster, amirite?), and I figured that collages would allow for an acceptable degree of stylistic exploration in a short amount of time. Upon presenting the collages, the client responded positively but was a little wary of charging full speed ahead based on such limited, abstract selection of visuals.
I won’t make decisions for the client next time. In retrospect I should have presented all options, explained their strengths and weaknesses, and followed my gut by recommending full screen mockups. It’s much more effort up front, but the representation of a familiar screen would have made the stylistic direction much more real. Based on the client’s design maturity, I think that would have been more effective and started the entire project with a higher level of confidence.
In general, there is a logical order in which design system components are constructed. Complex components are built from smaller ones. Forms, for instance, are made up of various inputs and buttons. The production of components should be organized in such a way that they can be continually used to construct larger elements. Toward the beginning of the project, these larger elements might be forms. Further along in the project, the larger elements might be whole pages.
I think we got this right, for the most part. We started by selecting typefaces, icons, and documenting a basic color palette, and then moved into foundational elements like buttons, links, textfields, dropdowns, etc. The one thing I overlooked in the beginning was defining the base unit — a rem value by which we would size everything in the system. Clearly, I would define this early on next time, as not defining on it from the beginning caused us to have to adjust some component sizing in code later on. It wasn’t a huge deal, but it would given us cleaner design throughput and parity between our Sketch files and coded components.
(Bee tee dubs, we arrived at 8pts = 1 rem. It multiplies well and dovetails nicely with 8-point grid systems.)
I found that the worst way to a approach a design system is in the way that it’s often pitched to the client: as a collection of discrete components that can be put together in a million different combinations, like Lego bricks. That may be a good way to think about a design system when it’s completed, but not when it’s being designed. The relationships between components is critical, and if components are designed in isolation those contextual relationships will be missed.
This was something we did not have planned out to do, though I intuitively did this as I went along. However, having to steal time for these exercises was not optimal, and it would have been much better to have proper stories in the backlog that ensured there was time for these activities. These stories — whether they are for components, sections, pages, or whatnot — dedicate time & thought toward continually zooming out and assessing how all the components play together.
Components need documentation. The more complex the component, the more lengthy the documentation (generally). The website we created for the design system needed copy to describe components, patterns, guidelines, principles, code, and more. We definitely underestimated the amount of time it would take to sit down and write all of this content, even with all the “starter” content we could reference on other design system websites. I don’t have a magic solution for the next time I do this, like “add 20% more time to every story”, but I’ll definitely look more closely at each element’s expected functionality and consider what effort it will take to fully explain its usage.
Lastly, a Design System ≠ a Designer
While it’s true that a design system can include complex solutions and describe very complete patterns, it is still a tool that needs a human mind to utilize. I think that large organizations may get over-excited at the prospect of a design system because they think it will remove all their UX problems in one fell swoop, or allow their engineers to be the designers. Nope. Here, I think we did the best job we could to delicately set proper expectations so that the incredible value of the design system was maintained while also encouraging the in-house design organization to keep growing.
Design systems are fun! Knowing more about how it all works will make it even better the next time around.
Originally published on The InVision Blog on June 8, 2016.
Launched in 2005, Blinksale is an invoicing application for freelancers and small businesses. Built exclusively for use in a desktop browser, the app had never worried itself over small screens. Mobile web browsing wasn’t a common investment at the time—especially for web apps—and responsive design wouldn’t develop until years later. But with the advent of the iPhone in 2007, the product landscape began shifting significantly and many web products began to go mobile.
As smartphones increased in popularity, so did the requests for a native iOS app experience for Blinksale.
In the fall of 2013, we were able to spin up a mobile initiative in order to support to the way our customers—and prospective customers—are now working.
The team began with high-level discussions of what it thought the app should be. Should it only deal with invoices, or should it also handle estimates, client management, settings, and any number of other features? Should the invoice creation process on mobile be simplified, or should we include all its bells and whistles?
There were a lot of questions and tough decisions. In the end, it didn’t feel right to treat the mobile app as an abbreviated version of the web app. We wanted mobile users to feel like they had the whole app in the palm of their hand so that, if they wanted, they could be completely untethered from the web app.
In the course of our product discussions, we started a list of core product features in a shared spreadsheet so that we could track the features we talked about. Now that we’d decided that the app should include pretty much everything, we had to define “everything.”
That simple spreadsheet evolved into a detailed inventory as I documented every screen, element, feature, and action in Blinksale.
This was as much a discovery exercise as a documentation effort. None of us had been with the product since the beginning, and forcing ourselves to shine a light into all the corners of the app helped us get acquainted with parts that we hadn’t necessarily paid attention to before.
The end result was like one of those scenes in Iron Man where Tony Stark looks at an exploded holographic view of some piece of complex tech. It allowed us to see all of the pieces we were dealing with and how they connected to each other. We were able to have more specific and informed conversations about what should be “in” or “out” of the product. It also served as a map so we didn’t forget any elements as we reconstructed screens and functionality in iOS.
What we were able to see is that not every piece of functionality from the web app could or needed to move to iOS. For example, exporting a data table to an XLS file is not likely a relevant activity on a smartphone, but that is something that the web app can do. We decided that should not be a feature we pursue on mobile.
Once we’d tempered our understanding of what features should go into the app, I could more clearly explore design.
From spreadsheet to screen
After pondering the spreadsheet, I decided to jump right into Photoshop to explore a few key screens. Playing is vital to the design process, but it often gets stamped out by the pressure to meet deadlines or jump right into agile development. I didn’t want to leave it out, so I made sure that our schedule included time for this activity.
I chose to play around with an invoice (in both read-only and edit mode), and the invoices (list) screens. The invoice is the centerpiece of the app, and I suspected that solving design there would create a lot of patterns to be used elsewhere. And there are quite a few list screens within Blinksale, so figuring out that format could also assist design in other places.
As a result of making screen designs that looked very real—not sketches or other abstractions—I think I arrived at solid design decisions much more quickly. When you have space to play, pressure releases and the mind has permission to wander. And when you go as high-fidelity as possible, you avoid the pitfalls that lie between abstraction and reality.
So as I played with these core screens, tangential design—like primary navigation and other high-level design patterns—were also able to crystallize. The core aesthetic (color, fonts, etc.) also materialized quickly, as I’d been thinking about the next evolution of Blinksale’s visual design for some time.
Mapping the territory
With these structural and navigational ideas gaining more clarity, I decided to create a simple “app map”—a visual representation of the screens I’d need to organize and chain together. It helped me turn that very abstract spreadsheet into a high-level screen diagram. This visual also helped me prove out my main navigation ideas and give the developer a clearer picture of how I was thinking about the app’s structure.
Have I mentioned that the development team was privy to all of this work and these product conversations? They were. Development was exposed to design work from the very start and validated or raised red flags if I started going down a path that was problematic. Design should never be isolated—it rarely has all the answers.
Designing for iOS
There’s been a lot of talk about how Apple’s influence may or may not be homogenizing user interface design, but I’m not going to get into that. What I will say is that our product team didn’t want Blinksale to simply pull in standard iOS UI elements and call it a day. We wanted to stand apart to some extent. Additionally, not all of Apple’s default design choices agreed with me in the context of this app.
But the great thing about a human interface guideline is that it’s a guideline. Think something isn’t quite right? It’s your app and your design—do something better.
For example, I wanted to do something more interesting and flexible than iOS’s standard text inputs. Other areas of the visual design were shaping up in such a way that this default element would look out of place. I also wanted to be able to make the UI more compact by putting 2 or more inputs side by side, and the default pattern made this difficult, if not impossible.
I ended up using an input pattern that displays the input label by default, but then animates it to up above the input area once the user begins typing. This allowed us accommodate that compact layout goal and give the app a fresh, differentiated element.
No operating system is going to hand over everything you need all of the time. It’s okay to push the boundaries and create new things so long as you stay true to the overall spirit of the platform.
Capturing interaction details
In completing the app design, I ended up creating mockups for nearly every screen. Remember that thing about high-fidelity design? With every screen I mocked up, more reusable UI was created. It wasn’t long before I was mostly dragging in elements from existing designs to create new ones.
As I finished each screen, I placed them into a Keynote deck where I could annotate them. I find that the narrative style of walking through a screen or a workflow enlightens the developers on the intricacies of the interaction design and helps the designer detect gaps, inconsistencies, and flaws. Chaining together screens helped me see the “story” of the interactions unfold, like a comic book. I could more easily identify where the successes and breakdowns happen between screens, and what I need to think about as the user moved from one thing to the next.
These days, InVision takes the place of my old Keynote workflow. It’s easy to link up a bunch of screens with hotspots and guide the team through the specific click path with Tour Points. Dev Notes or Comments act as my annotations. And the screen-level transitions mean I don’t have to annotate how one screen animates to the next—we can all just see it.
Until this point, I’d enjoyed a very necessary head start in front of development. I’ve heard this approach referred to in industry lingo as “Sprint Zero.” It gives the designer an important opportunity to get some design figured out up front before anyone starts building. Remember making time for play? There’s that, and then there are a number of bigger design decisions that are better to make before getting into the wild seas of development.
By coming to the table with at least a vision for how screens should chain together (the app map), how users would get around (Keynote walkthrough), and what major UI elements would look like (mockups), there was less risk of major rework as we built the product.
Although we’d determined that the app’s feature set would be as close to the web app as possible, we still needed to define what we were going to launch as our first release—it couldn’t be everything. Plus, there was some foundational work to be done, like extending the application programming interface (API) to do things it hadn’t been asked to do before. We also began writing stories and forming sprints. (For the uninitiated, you can think of a story as a to-do, and a sprint as a short period of time—usually a couple of weeks—to complete the to-dos.)
For development, the nature of sprints acknowledges the impossibility of knowing with absolute certainty how long things will take to build. Design deserves the same treatment so that there’s sufficient time to properly work out problems. This requires a team with shared goals, reasonable patience, and personal responsibility. Everyone is trusted not to waste time, but they’re also expected not to rush out work that isn’t their best.
The majority of sprints came with a Test Flight update that we could all download and use. Having an actual app to tap around allowed development to point out holes or problems with the design as well as validate that everything was working as it should.
Occasionally we ran across design needs that I’d missed. Sometimes development was pretty confident in a solution and, in order to get a feature completed, they went ahead and implemented the idea. I can’t recall us ever completely throwing out one of those solutions.
On the contrary, they were so close to what I would have designed that we ended up collaborating to get them just a bit more polished. On a good team, everyone—not just designers—knows what great UX looks like.
There were technical limitations, too. Sometimes we discovered that my designs weren’t possible to implement or were unreasonably difficult. I had to accept these constraints and then fabricate a different way to solve the problem.
It takes a village
It shouldn’t be news to anyone that UX isn’t just for designers. It never was. We’ve been fortunate to build a team that cares about UX and supports it.
We are more than our job titles. We didn’t figure out every iota of the design in perfect detail before development. Animations were one place where I could count on the experience of our developers to make recommendations. Others on the team provided input that greatly improved the design of the app. Great design takes a village.
One of the exciting and terrifying things about technology is that it’s always changing. Today’s solutions are tomorrow’s laughably clunky user interface. Every day is a new opportunity to take a pass over what has shipped and consider what could be done to make it better.
Update (9/15/16) — I checked my review on whim and noticed that MVMT has redesigned their reviews area in such a way that you cannot sort by date or rating as you could previously. As a result, my review is now many clicks away, toward the end of the list. Okay.
The review itself has been edited by… someone. Apparently MVMT is threatened by mentions of competitors, so they edited out my 2 mentions of Timex, which very much changes the basic gist of my review.
What a bunch of babies.
Update (5/19/16) — My grousing on Twitter got the attention of MVMT customer service, who emailed me to resolve the situation. Apparently it has been the company’s policy to closely monitor incoming reviews, take down any review that seems to contain any hint of dissatisfaction, and follow up with the reviewer via email to resolve their concerns privately. This is, of course, a terrible policy and I’ve been told that it will be changing.
However, that this seemed like a good idea in the first place strikes me as incredulous. Removing reviews under the guise of a customer satisfaction protocol? It’s hard to believe that in this day and age an entirely internet-based business would not expect backlash over review censorship, however good the intentions.
In the end, though, my review is back up at its original 4-star rating. And yes, I’ll be checking periodically to see if it sticks. :)
I’m mature enough now that the idea of writing a blog post about a beef I have with some random company feels plenty distasteful, but sometimes the situation leaves one feeling like they have no other recourse. Ideally, someone googling for MVMT or Chrono Black/Tan Leather watch will be able to read this this and draw their own conclusions.
It all started with an email from MVMT Watches to review the watch I had recently purchased — a fetching Chrono Black/Tan Leather. “Tell us what you think!” the email said. Here’s what I wrote:
Very Stylish (4 stars)
Overall, I’m quite happy with this watch. It’s a striking design, and it looks just as good in person as it does in the photos. I get compliments all the time when I wear it. Well worth the purchase, for sure!
I would have given this watch 5 stars if it had not been for 2 small things:
1. The strap feels a bit “spongy” — if that makes sense. The upper appears to be actual leather, but it feels like a super-thin veneer of leather. I understand that “genuine leather” bands cannot be expected to use really thick leather, but it does feel really lightweight for the price of the watch. And consider that Timex sells its Waterbury x Red Wing chronos with thick leather bands for less than the price of this watch.
2. The chronograph pushers are very “clicky”. Meaning, when depressed, they make a click sound and feel like they stick for a moment before releasing back up. The effect is that it feels like something is broken, missing, or not lubricated. Again — even at this low price point — that the pusher action is not smooth like a $60 Timex just seems wrong.
(It’s also worth mentioning that I had to Google how to set the date and align the chronograph hands. Seems like a silly thing for MVMT to not provide any printed instructions with the watch, and to also make this information so difficult to find on the website.)
This review was never posted. After looking through the other ~50 reviews for the watch, I noticed that they were all 5 star reviews. Sorry, no one has a track record like that. Here’s one 5-star review from 2/27/16 that is still inexplicably posted for all to see:
LOSINGMINUTES (5 stars)
I’m finding my watch is losing minutes every few days not really happy with that situation you keep sending pop up ads on every page I go on very annoying at this point would not rebuy or recommend your product to any of my acquaintances
I find it hard to believe that a reviewer would rate a watch that does not accurately tell time at 5 stars. Something tells me that this reviewer figured out that a 5-star rating was the only way to have their voice heard and consequently gamed the system.
Taking this approach, I resubmitted my review again — this time rating it 5 stars but adding a disclaimer at the top that I was only rating it this highly to get it posted. I’m smart! And for a couple of days, it worked. My review posted and was viewable even after a page refresh, and on different devices. Success! The voice of the customer had been heard!
Nope. It’s been removed.
Look, I get it: you have an open comment form and the internet is full of trolls. You gotta police that thing. But when a verified purchaser posts a generally positive review with a few light criticisms, removing it without explanation casts a shadow over everything you are. It makes you look like a child who sticks their fingers in their year and yells “LA LA LA LA LA I CAN’T HEARYOU” to drown out the sound of disagreeable people talking.
Several years ago I personally discovered (and I am certainly not the first person to do this) that writing out problems I encounter while designing often leads me to a clear solution. This exercise began as an attempt to solicit feedback from my coworkers via email, and to this day I often write inside an email program, even if I have no intention of sending.
The exercise is simple enough: I write out my thoughts on the problem as a solicitation for help, frame it up to ask for the recipient’s thoughts at the end, review it, and edit repeatedly for clarity.
By working through the problem with the mindset of explaining it to another person, a fuller story emerges. The process of articulating a thought to someone who cannot be expected to have the same understanding of the minutia — as the writer does — forces the mind to see the problem in different ways. It also requires discovering or recalling details that may have seemed inconsequential. And, naturally, it requires broader thinking to properly situate the problem in the recipient’s mind. All of this can lead to some very satisfying “a-ha!” moments.
I’m not exactly sure why this technique seems to work so well for me, but I have a few good guesses:
Like note taking, the simple act of writing a thing down makes it easier to recall and work with. The words are right there, right in front of my eyes. I have to make sense of it.
For me, at least, writing is a focusing activity. In order to really work at explaining my issue to another person, I have to concentrate more intently than if I was simply sketching possible solutions. I am forced to physically adapt my environment to the task (no noise or visual distractions).
A sense of manageability
There’s something soothing about reducing your huge problem down to a few blocks of text. I find that the amount of text I write always makes the problem seem less daunting. Like, “This problem is only 3 paragraphs long? Whew!”
Acknowledging all the information
Since the person I am writing to is not aware of all the details of my problem, I am forced to include information that I may be taking for granted. Seeing this information written down forces me to actively deal with it in my problem-solving.
This exercise naturally forces me to repeatedly run through and remold my narrative.
It can take some time, and I can’t say that it works 100% of the time, but it does work. If you’ve never tried this approach before, give it a shot. It’s not the only way to achieve clarity, but it’s definitely satisfying.