If you’re curious, the “How Might We…” (HMW) framework for creative problem solving originates back to the work of Sidney J. Parnes, Ph.D, in his Creative Behavior Guidebook published in 1967. Dr. Parnes referred to the framework as “Invitation Stems” or “How Mights”. Dr. Parnes' work also led to the additional questions of “How might I?”, “How might you?”, “How might our team?”, and “How might our customers?”. Today, HMW remains one of the most powerful tools for kicking off a process of “challenge mapping.” “How might we…” is the kind of question that lacks hard requirements at first and can feel unanswerable. However, if you get the right people engaged, the answers that surface will lead to progress. How does AmpXD tackle HMW Questions? We start by making sure that the whole team understands the question and starts on common footing. Some follow up questions may be necessary. Have we answered an HMW question like this for other clients or internally at AMP? Can we rely on past experience or will the answer require us to build from scratch? What perspectives will be required to generate the right answer? Engineering? Design? Content? Business objectives? Next, we assemble the team. The best HMW teams represent all who stand to benefit from the answer as well as those who could help us get there. They are a cross section of the organization as well as users, customers, and subject matter experts. Whether you use an agency like AMP or decide to go it alone, there are a few key attributes that each team member must have. Each team member needs to be open, have broad and relevant expertise, and be fearless about sharing ideas and opinions in public. The last consideration for a successful outcome is access. The team will need access to: One another Leadership Information Insight into what is possible. Now that the team is assembled, what can we expect? Answers! If you’ve done the work to fully understand the question, assemble the right team, and provide access to resources, you can expect progress. Once we have a set of answers to our HMW question, we can start to sift for the right one. Each answer must be measured against cost and timeline estimates. If you’ve come to the right answer, everyone will know it. If you don’t find the right answer, often you’ll be left with a new, better HMW question to work with.

Whenever I come across a conversation thread asking what characteristics are most valuable in a UX designer, I frequently see answers such as “desire to learn” and “creativity.” While I don’t disagree that those are highly valuable attributes to have, having interviewed too many designers to count I think there is one additional overlooked characteristic that separates good designers from truly great ones: the ability to think multiple steps ahead and game out their solutions. In the evolution from beginner to expert, designers go through somewhat predictable phases. As they move up the ability curve, most designers get to a place where they can take in the user needs for a particular interaction and come up with multiple options for combinations of UI elements and layouts that will achieve the desired user goal. Evaluating which of these options to move forward with is where the rubber meets the road, and it’s the depth of thought applied to those evaluations that really define the line between good and great designers. As a simple framework, we can think of design evaluation in 3 levels. At the first level, we assess the design to ask if it accomplishes the task we set out to do. Does our signup form allow the user to enter the necessary information to create an account? At the second level, we can evaluate the design for usability and even elegance. Is our form easy to use, simple, and even delightful? At the third level, we ask if our design is bulletproof. What are all the states the form can be in and does it still work in all of them? What happens if a user enters bad data? What if there is a connection error while submitting and also bad input? Taking a design solution from acceptable to awesome requires thinking past what we see on the page. We have to think multiple steps ahead and be able to visualize not just the next step the user will take, but potentially two or three steps down the path. We need to think about not just the easy path through the flow we’re creating, but also all the side paths the user may go down, and all the possible places that may lead. Further, we need to think not just about the simplest state of our UI, but also complex states that it could reasonably be in and make sure it works there as well. Even good designers often stop at the second level (or do a light pass at the third), and rely on user testing, QA, and/or product feedback once a feature is shipped to find the flaws. User testing does have its place for this sort of thing, but is insufficient because it is difficult to make sure you’ve covered the less common usage patterns. Also, space and time for user testing is something we rarely have enough of, and it’s better to put in the thought beforehand and save user testing resources for the most important feedback. Waiting until a product is in the wild to discover the flaws is something we want to avoid at all costs. As a very simple example, consider an overly simplified UI for an admin to add users to a product. We’ve decided already that we want to invite users via email, and the invited user will click on a link and create their account. The admin will enter the email of the person to invite, click the “Invite” button, and the rest is up to them. After coming up with a few directions, we may decide that this is the strongest direction for our Invite Users flow: Our level one evaluation seems to pass; this UI allows us to invite users. For level two, it seems relatively simple and straightforward, easy to understand, and quick feedback from others indicates it’s understandable. Level three requires us to start pushing on this until it breaks. While it would be good to actually draw out all of the states of the interaction (and best to prototype), we can start by simply gaming out a user interacting with this. First, they’ll enter an email and click invite. What happens then? We want them to know they’ve been successful and who has already been invited, so perhaps we can add a successful interaction and a cool animation to add the newly added user to the bottom of the list. What if they add another? And another? What happens when they've added 10, 20, or more users? Our list may be getting longer, and eventually, our user invite form elements will be pushed off the bottom of the page “below the fold". When a different user comes to this section later, after it already has 30 accounts in the list, they may not know to scroll down to the end of the list to find the form. We’ve identified a problem with our design already, and can adjust to fix it, perhaps by moving the user invite form to the top, like this: In addition to evaluating our design for problems that arise from pushing our interactions in their primary incarnation, sometimes we need to think even broader and evaluate our designs at a system level. When designing large and complex products, often the specific interaction we’re designing may need to be accessible from multiple places, or the interaction we are creating can be applied to additional interactions and it would be helpful to be consistent. Evaluating our designs deeply means thinking past just this page and applying our knowledge of the greater whole. Expanding on our previous example, perhaps in our product we also have the ability to create projects and add users to the project. While designing the Invite User form and gaming this out in our head, we can anticipate that sometimes our users might create a project and begin adding users, only to realize that someone they want to add doesn’t have an account yet and needs to be invited. We ideally don’t want to take them out of their project creation flow to invite the new user, so perhaps we want to allow them to access the Invite User form from the Project Creation page. After considering options, we decide that we can put the Invite User form into a popup accessible from the Project Creation page so that they can quickly invite a user and then return to where they were and add them to the project. Our popups have a limited height, so will we be able to adjust our Invite User form to work in a popup? We can add scrolling to the user table to allow for a fixed height implementation, so our design should work even in that future implementation. At this point, you might be either thinking that this is obvious and self-evident, or you’re asking how you can start to incorporate this type of deep thinking into your design process. Even if you’re in the first camp, we can always improve our evaluation skills and hopefully, there are some ideas here that can help. 1. Identify all possible states. In software development, when writing a particular function one of the first steps in testing is to identify all possible inputs that the function could receive so that you can make sure it handles all of them (even bad input). When designing an interaction, we should do the same with our user inputs and behaviors. It can help to make a list of every valid state the UI can be in, and also list out any possible invalid state as well. For something like forms, this can be somewhat straightforward (what could the user enter into this field that is valid/invalid?). For more complex UIs try to think of every valid/invalid permutation of the interface and list them out. If you have a long table of objects with actions, what are the states of this table? It can be empty, it can have a few items, and it can have lots of items. Perhaps we have a need to differentiate between having no items due to not having added any yet (first time) vs. not having any items because they’ve deleted them all (returning user). 2. Try to break it. It’s easy to fall into interacting with your design like your ideal user; after all, you were the one who designed it with them in mind. Instead, at every decision point in your interaction, try to think of how a user might “incorrectly” interact with your design and game out what happens (“incorrectly” is in quotes because there is no wrong way to interact with your design; it’s up to us as designers to facilitate successful interaction with our designs). 3. When in doubt, prototype. It’s generally ideal, given infinite time and resources, to prototype everything to make sure it works how we expect. However, design resources and timelines make it inefficient (and probably unnecessary) to prototype every interaction. If you’re doing something highly complex and gaming out every scenario isn’t possible or easy, building out a robust prototype can help find corner cases and interactions you didn’t anticipate. Be aware of the limitations of prototyping software like Invision however, and make sure that your prototype doesn’t only embody the happy path through the interaction. Sometimes the very act of trying to build a prototype to support every possible user behavior identifies problems we need to address.

In my neighborhood in Portland, Oregon, many of the sidewalks are original - built when the neighborhood was coming together in the early part of the 20th century. You can locate stamps at intersections that have both obsolete street names - Sprague Street is now known as Rosemont; Margarette is now 34th Ave - and the names the contractors who poured the cement, along with the year they were poured. These small reminders of the recent past are fun to find, but point out a glaring inequity in their construction: These old sidewalks are not accessible, and not safe. An unimproved intersection The city is in the process of converting each of the city’s intersections into curb cutouts that are friendlier to those who may require assistance (wheelchairs, kneeling scooters, crutches, probing canes) getting up and onto sidewalks from the street. The brand new curb cutouts include a yellow rubberized traction pad that signals the transition between street and sidewalk, and there are eight on each improved intersection - two on each corner of a standard intersection. An improved intersection. This effort is happening not because the improvements and bright yellow traction pads are attractive, or because the contrast between the fresh cement and the old cement is nice to look at - but because it is the right thing to do for the citizens of Portland and those who have mobility issues who might otherwise need to be in the street in order to avoid the curb. This abides by the regulations set forth in American with Disabilities Act of 1990 (ADA). The benefits go beyond supporting only people who have disabilities, though - anyone who has tried to use a rolling suitcase on the sidewalk, pushed a baby stroller over a curb, or can’t ollie on a skateboard can attest to that. By doing the right thing, Portland has chosen to make their city more accessible to more of its citizens. In our web development projects, we often support clients who need to do the equivalent curb-cutout improvements. Their sites may have been beautifully designed, but fall short in visual and technical areas that would help make their site more accessible. By bringing the site up to a baseline of accessibility standards set forth by the WCAG, the site becomes more equitable, inclusive, and usable for more people. The add-on effect for the client is that they have just widened their potential customer base by not excluding people who may consume web information in different ways. The improvement process also helps shake out other technical issues around markup structure, meaning the site may become more SEO-friendly and may render better in a wider range of devices after the improvements are implemented. While these efforts may be initially driven by legal justification (avoiding ADA lawsuits), or for marketing reasons (reaching more customers), improving your site’s accessibility is the just and correct thing to do. Our process begins by using a suite of tools that analyze the website to identify problem areas. This includes using voice-reader to read the website’s content - not everyone who browses your website will use their eyes to do so. We also see how the site renders without styles applied, validate the markup of the site to ensure the proper document structure & hierarchy is established, and closely scrutinize how interactive elements work. Particularly complex interactive elements like carousels or interactive navigation menus may require an entire rebuild in order to be accessible, but the goal is to maintain the current design or as close to it as possible. The end result of such an effort should not sacrifice visual design or interactivity, nor should it even be noticeable to those users who use standard means to interact with websites. But for those who need assistance, the improvements are welcome and appreciated. For sites that we build from scratch, we design and develop with this equity in mind from the beginning. By starting off with a requirement of accessibility, the new site enters the digital world already with accessibility in place. The level of accessibility, set forth by WCAG standards - “A” to “AAA”, with the latter being the most strict - may be dictated by the customer’s requirements. Projects for larger clients, non-profits, or government clients typically have a minimum accessibility level mandate for digital properties. But even for those without the mandate, doing the right thing results in a site that behaves nicely across different input types and allows for a wider audience to engage with the site. Do you need help with your site’s accessibility? Are you concerned your site is unintentionally excluding users?

A friend and mentor once spoke to clients about his three questions (Yapp’s three rules) that any home page must answer. They were: Who are you? What do you do? Who do you do it for? These questions are the most important goals to accomplish with any home page, as you need to quickly communicate to users about your brand and why should it be relevant to them. Why the urgency? Well, for any new or uninformed user, they will spend perhaps a total of < 3 seconds reviewing the site depending on where they came from and why they are there. It is important that they understand your brand and what it means to them. This is part of the Brand and Messaging problem that most websites face. They fail to understand who they are and what they want to communicate to their customers. Don't try to be everything for everyone The second common challenge on many websites is part of the inherent value of the web and leads us to our next set of three rules: Focus, focus, focus! Most company websites try to communicate to their audience everything that the company wants them to hear. The two challenges inherent here are a lack of priority and not focusing on what the user’s needs are. For any site — E-commerce, Marketing site, etc. — there are multiple audiences who come to the site. A company needs to prioritize its audiences into a hierarchy and prioritize its messaging and home page real-estate to communicating to them. This has as much to do with messaging as design and user-experience, but the lesson is the same: Focus on the most important users and tell what they need to hear to act on what you want them to act on. The second challenge stems from the very nature of the web. A website is available to everyone. However, it doesn’t need to speak to everyone who could possibly come to your site. Common secondary audiences for most company sites are press & analysts as well as job seekers. Both of these types of users are motivated to interact with your site and don’t need precious home-page real estate dedicated to them. They know where to find the news and careers sections (in the About Us) of your site with little effort as long as your navigation is clear and you have a site map. It's about your audience - not you My organizations architect their websites as a reflection of their internal structures and hierarchy. This is a common mistake. Websites should be designed to the needs of your audience in the way they want to engage with your brand and their needs. Not designing your website's architecture, messaging, value proposition and navigation to your primary audience's needs will create frustration and lower levels of engagement. Think mobile first The majority of website traffic today are typically from mobile or tablet devices. Therefore, you need to ensure that the website be equally as effective in the mobile format as this will likely be the first impression your brand has with your target audience. Designing a website to be effective in a smaller format is challenging and requires extreme diligence to properly tell your brand story and drive engagement. Companies who neglect the mobile experience are making a big mistake. However, we still find many companies that are not prepared for a mobile first world. Brand experience needs to be consistent beyond the website When our team evaluates digital ecosystems and website for our clients, we are keen to examine the swim lanes in the customer's journey. The reason is your customers are likely to visit varying digital properties representing your brand from Instagram, Facebook, LinkedIn, Email, Landing pages, Whitepapers, Mobile Applications and beyond. If the brand experience and story are disconnected across these varying assets, you will create confusion and lose the ability to drive home the key brand impressions you hope to achieve. Basic website evaluation benchmarks: 1. Clearly articulate your Brand Value Proposition through a structured Messaging Architecture which addresses the main three questions: Who are you? What do you do? Who do you do it for? 2. Focus your efforts on your home page on convincing the primary users of your website on what you want them to do. 3. Prioritize your messaging through clear design and user-experience on focused messages to your users satisfying what they need to know and how you want them to act. 4. Is your website designed to the needs of your audiences first? 5. Is your mobile optimized website effective? 6. Are all your digital properties working in synergy to reinforce your brand? Our Offer If you would like a complementary review and assessment of your website, we would be delighted to evaluate your website and provide some insights and thoughts.

CREATING USEFUL STYLE GUIDES FOR WEB PROJECTS - PART 2 In part two of two, we'll explore different ways to create styleguides and what works and doesn't about each method. Throughout, we'll look at examples. If you haven't read the first part of this series from last month, or need a refresher, click here. We have already defined what a styleguide is, and what types of visual definitions need to be in them - and I've made recommendations about when to create them. This post will dive into the different ways of actually creating the styleguide. Method One: Static Old School I'm calling this the Static Old School method: A designer or production artist lays out a styleguide based on the design system for the project in Illustrator or Photoshop. They export it as a PDF, get client approval, and move on to layout. The PDF is handed off to the developers to begin their baseline work. Pros: Gets the job done Gives designer complete control over formatting and layout, which may be useful for client presentations Cons: Not easily updated - requires a designer to maintain Does not keep designers honest - a label indicates that this blue color is #3c89bf — but is it actually? Not interactive - cannot demonstrate rollover states or add code snippets Developers cannot easily highlight text to inspect additional properties that may not be defined, such as line height Verdict and Recommendation: On a small project or one with a short timeline, this approach will suffice. There are enough "cons" to avoid it if you can though. Method Two: Use a Plugin! Since a designer has her layout in a design program like Photoshop or Sketch already, wouldn't it be really convenient if a magic button could be pressed and a styleguide is automatically created? Fear not, this magic button exists. The most well-known style guide generator is Craft by Invision. Invision is an online collaborative prototyping tool that allows designers to upload their layouts, request reviews or comments from other team members or clients, and simulate interaction by creating clickable hotspots. If a layout is uploaded correctly, developers can interact directly with the app to inspect fonts, measurements, and CSS properties: Invision has created a plugin called Craft that allows designers to automatically generate a styleguide based on all of the existing properties in their layout. The plugin will analyze all of the font properties and colors used in your various page layouts and generate a separate static styleguide for you. This can then be exported as a PDF / static styleguide and shared, or uploaded to Invision for review and for developer inspection. I created a demo of the plugin in action which you can view below: https://youtu.be/BzENA_cibds https://www.youtube.com/watch?v=BzENA_cibds Craft is not the only game in town - zeroheight uses a Sketch or Photoshop plugin to generate a styleguide based on a layout as well. There are additional steps and control given to this tool, since zeroheight lets you create products with technical specs as parameters (such as the design and screen resolution). In this way, this solution is a combination of a local design plugin and an online management tool. Unlike Craft, the designer has more control about what ends up in the layout to begin with - avoiding the scenario where every single color or font on the layout ends up in the styleguide that later has to be removed. Zeroheight will also allow designers to define entire component definitions, which make for a much more robust styleguide. Once the designer defines the parameters and what layers should be included, zeroheight will export the generated guide to its server, where the interactive styleguide is automatically created based on the export. This is where your living styleguide is put for further editing, viewing and sharing with other team members. Unlike Craft, where the generated styleguide is just another page in your layout, the zeroheight styleguide is managed within its website. A risk I see with this approach is if a design changes but the styleguide is not synced, there's no guarantee a developer is seeing the latest changes. Deciding on a proper workflow can help mitigate that risk. zeroheight has other bells & whistles, such as JIRA and Slack integration, that can notify team members when the styleguide defintion is updated. It's unclear how much this service costs, but since it's more than just a plugin, I am guessing there is a subscription model involved. The website provides no pricing model, no demo (I found a few on YouTube) and no trial version, so you don't really know what you're getting without having to go through a sales call and presentation. Likely, the people making the decision to purchase the product aren't the people who are sussing out whether the tool works for them or not, which can require a lot of legwork for the team just to find out whether the tool is going to do what they want or not. Pros: Reduces the amount of work required by designers to create the styleguide May help keep designers honest - in the Craft demo video above, you can see I had multiple similar shades of grey and orange that were not intended. In a real-world example, I'd need to decide whether those colors are still required, or remove them from my layout. Removes any ambiguity in the definitions - yes, that really is 60pt font, and yes that really is #3c89bf Excellent Sketch support Can be easily re-exported as your design changes to capture more definitions Cons: Requires the layout to be defined first While it may keep designers honest, they may not go back to actually address duplicates or ambiguous definitions in their primary layout, leading to more ambiguity. Outputted result is still static unless you use Invision or zeroheight, which is not free Not sure if it works as well for Photoshop, unknown whether it exists for other layout tools at all. No way to make Craft interactive Craft only captures colors and fonts; doesn't capture button styles or any additional design language components that should be in a complete styleguide (zeroheight is more comprehensive) Verdict and Recommendation: This is better than doing it entirely by hand if you're using Sketch (and even moreso if your team is using Invision anyway), but the output result of Craft is not enough to be considered a complete styleguide, and there's no real way to make it interactive. zeroheight shows more promise, but without the ability to try the product out, you have to hope that that it does everything I think it does. I can't make a strong recommendation for or against it at this point without knowing more or having some hands-on time with it. Method Three: Generators Upon Generators! David Hund was kind enough to compile an enormous list of code-driven generators, of which ... there are many: Without the luxury of going through each individual tool and testing it out, these are very cool for a few reasons - they can live in your existing code projects which means you are not creating these based on the prototype layout, but actually basing it on production code. The end result is an interactive styleguide based on code you've already written. Some of the tools will automatically generate the styleguide, meaning you can continue writing the code for your project and the styleguide gets continuously updated; others require more input from the developer. A few examples and demos for some selected items are below: Stylemark, which will generate a nice page for you based on markdown format; Patternlab React Styleguidist KSS, which generates a styleguide based on /* comments */ developers put into their CSS and HTML templates. The comments are parsed by the tool, which outputs a HTML file with visuals and code snippets. Storybook.js, a UI development environment for JS projects (React, Vue Angular) Many of these tools have the same or similar functionality as their counterparts, and many of them won't apply to your specific project based on the platform it is living on. That said, there are many to choose from for a variety of platforms - and additional research and trial & error is likely the only way to find the one with the right feature set for you. While these are pretty slick and ultimately devs like me are easily impressed by any tool that "automagically" does something, the big unspoken issue here to me is that these tools cut out the designer from the process, and developers don't just make up the styles from scratch in the development phase. Thus, these tools are not a replacement for a styleguide, since a designer is going to need something to even start the project - they are likely going to *still* need the designer to hand something off statically at the start. So, that means these tools are likely a way to convert the styleguide from its initial form to a living form - but are not a replacement or the only styleguide to be created on the project. Pros: Reduces the amount of work required by developers to create an interactive styleguide Can be integrated with source control so there's never a disparity between the core site code and the generated styleguide Generates something that can be pushed to a public (or protected) URL and visited / referred to easily - eliminating the "Which is the the latest styleguide PDF?" question Since the styleguides are based on existing code, what is in them accurately represents the current state of the project. Can be continuously updated to reflect the latest styles and code Cons: An overwhelming number of choices A lot of these options are open-source and/or undermaintained - meaning no support if something doesn't work Ability to implement may require developer resources and hours that aren't available The tool you like may not be compatible with your framework or project platform Learning curve range depending on which tool is used and how involved it is. Often dependent upon learning and installing additional technology (various node packages, third-party dependencies, etc) Totally cuts out the designers from the process, unless they are also writing the code. Since the styleguides are based on existing code, what is in them may not *accurately* represent what the design was *supposed* to be! Verdict and Recommendation: Smashing Magazine has a nice, more in-depth review of some of these tools - though it's a few years old - worth checking out if you are compelled to move in the generator direction. Other Web Applications We've already briefly talked about Invision, which is more of an online prototyping tool. It becomes more than just that when using the Craft plugin. However, there are also online services tailored specifically for generating styleguides, for a fee. Two additional examples are Frontify and Patternry; zeroheight would also fit into this category as outlined above. FRONTIFY The approach for Frontify is to allow users to upload or add specifications via WYSIWYG editor. This could be done before, during, or after high-fidelity design by a designer, and can easily be updated as code snippets become available by the developer. It appears to allow for a collaborative approach that could be integrated at various points along the phase of a project. Frontify Style Guide from Frontify on Vimeo. Frontify offers additional services, such as a media library for storing image assets, and what they call a Brand Portal, for entire brand identity suite. The product aims to be a central repository for any given brand or product's guidelines, to be shared by designers, marketers, and developers alike. PATTERNRY If Frontify is trying to be everything to everyone, Patternry narrows its range of services and its target user. In Patternry, building a style guide requires a developer to write code that is hosted within Patternry. The target user for this product is a UI designer / developer - the product does not run off of drag-and-drop or WYWIWYG tools. The end result is more control. The component definitions inside Patternry seem to depend upon production-ready CSS and JS to function, introducing some concern about keeping code in sync between your code repository and Patternry. This also limits the collaboration aspect, as a designer without code experience can't dive in to make adjustments. Verdict and Recommendation: It's clear that these types of services wish to make the creation of sharable and maintainable style guides quite easy, but also wants to hitch users into a subscription model where they are dependent upon them as part of their workflow. That may not be in your budget, and may be yet another thing to track (along with GitHub, JIRA, Basecamp, etc). Some of the features are fairly robust, though, and the idea of not having to create any code from scratch is appealing. The feature set of Frontify seems pretty broad, so if your team can define a workflow that works for everyone, it may be a very useful suite of tools that act as a central repository for your style guides and brand standards. With Patternry, it seems to be more of a framework for an online styleguide than an actual generator or creator. That may be okay, but keep in mind that it's likely going to introduce code disparity between your repository and styleguide. Using a code-based generator tool as described above may be more useful. Some More Online Styleguide Examples FRONTIFY Frontify - covered above - used their own tool to generate their styleguide. Always nice to see a company pracitcing what they preach and using their own tools. I like how it mixes both visual definitions, when to use what, and provides code samples. They also categorize the sections into Design, Identity and Communication. Very thorough, but goes beyond a styleguide for a website and into the brand identity / pattern library for the entire product. View it here. Frontify ColorsFrontify Typography YELP Yelp provides its styleguide online publically, which provides nice code-toggle ability. The visual layout of the styleguide is less engaging than the previous example, which is perhaps emphasises the utilitarian nature of it. View it here. Yelp IslandsYelp Color - including SASS variablesYelp Typography - Including utility class definintions for front-end developers or content editors PAGEUP PEOPLE This is a styleguide that clearly took a lot of time to build. I like how this styleguide includes code samples for each component along with usage notes to remind authors how to utilize each component. I think their foundation area could use some more baseline code samples (typography, for example) but it possible that is baked into their global stylesheet, and developers would not have to touch it. View it here. PageUp color - nicely designed color blobs, though users have to hover above them to view the hex value.PageUp Buttons - Very thorough with helpful do's and don'ts and code samples.PageUp Component example - includes code sample and usage guidePageUp Typography - This section looks nice but is lacking for more detail around the values (line spacing / letter spacing, weights, etc) More examples: via CreativeBloq — Three Online Style Guides That Do It Right via Hubspot — Apple, Google & Starbucks: Inside the Web Design Style Guides of 10 Famous Companies Conclusion The takeaways here are that there will not likely be a single tool for solving the styleguide portion of the project. Nor should the responsibility of creating styleguide be assigned to only the designer or developer — it should be a collaborative process between technology and creative. We have found out that in some cases, two styleguides will need to be created - one static, perhaps for client approval and tech handoff; and one dynamic / interactive that will be the evergreen and living document to be referenced. It's also clear that everyone has their own definition of the right order of operations for creating styleguides. In my previous post, I had recommended starting with the styleguide, but also recognize that this workflow is not possible for everyone or for every project. Some of the tools outlined above will be more flexibile than others to fit your approval process and work style. I would suggest that an important criteria for selection is the ability for the tool or methodology to be flexible enough to work with you, rather than one that forces you to change your workflow in order to use. Hopefully this post has given you a good overview on the types of methods available and the pros and cons of each. Resources and Citations Styleguides.io List of Styleguide Generators An In-Depth Overview of Living Style Guide Tools Three Online Style Guides That Do It Right Apple, Google & Starbucks: Inside the Web Design Style Guides of 10 Famous Companies

CREATING USEFUL STYLE GUIDES FOR WEB PROJECTS -PART 1 Today's post is a two-parter. In this post, we are exploring the use of style guides and how they can help in all aspects and phases of a digital project by minimizing ambiguity and setting definable parameters that can be validated and tested against. A good style guide will help reduce hours spent by all parties throughout the phases of the project. In a future post, we'll take a look at some examples of style guides, what works about them, and explore some tools that can help the creation of these guides. What is a styleguide? A styleguide sets rules around how things look and behave. Styleguides are the projects visual source of truth for both user interface (UI) and user experience (UX). More focussed than brand guidelines, a styleguide is intended to be the visual and functional requirements definition for websites or applications. A styleguide will pull in components from its parent design system which may include overall brand guidelines, design system or an established pattern library. If a brand has very specific and strong brand guidelines, design system or an existing pattern library, a project's styleguide will be derived heavily from it or may not need to be developed at all. However, if these parent documents do not define every component in the project, a styleguide should be created to cover these cases. Via A List Apart Style guides exist in different formats - anything from a static PDF or image, to a single web page or an entire microsite or cloud-based prototype can be used for host the styleguide. Of course, they're more useful as univerally accessible documents that are easily updated, so web-based styleguides are popular for a reason. Thus, the best styleguides are built as a collaboration between the design team and the development team. Not only will they define how things look, they'll also define how to build those things with the correct code. This example from Lonely Planet exemplifies this full-fledged approach, covering both the visual aspect of components and layout but also specifying a code pattern for how to build the components. The main point is that it is a visual tool that can be referenced by multiple people playing their respective roles. There may be a written component to it, but it is primary visual. A styleguide can be developed in conjunction with the main layouts, or as a template before the main layouts are defined. Ideally, the guide is a deliverable that the client approves with the designs. Via Lonely Planet Why use a style guide? While front-end technlogy seems to change on a monthly or weekly basis, the phases that a project goes through often do not. Whether your business practices waterfall, agile, hybrid, or some other methodology to get the job done, at some point, there is a handoff between creative and tech. A layout has to get out of a designers head, into a document, approved, and handed off to the developers for implementation. This could happen once, or it could happen many times over the course of a single project, but the transition point and hand-off process is always there. This handoff process is a crucial step and it is important to minimize abiguity so that specifications can be met. Via Barricade Developers love specification and requirements (maybe not actually _writing_ them, but that's another topic). By putting rules and definitions behind everything from how the user is supposed to interact with something on screen to the way the layout changes at a particular breakpoint, a specification can be met - and tested against. These requirements become the acceptance criteria that define whether the task was completed or not. Without these set of rules, ambiguity creeps into the picture. Ambiguity is a developers — and ultimately, a user's — worst nightmare. Ambiguity allows room for error, leaves things open to interpretation and subjectivity, and ultimately, cannot be tested against. Much nature abhors a vacuum, developers abhor ambigutity. Design, however, can be more comfortable in the realm of the ambiguous. Sometimes this is intentional. Art, by definition, is open to interpretation and can be intentionally unintentional (if that makes sense). More often than not, though, it's a result of shifting business requirements (see Peter's post) or a pressing time or budget constraint that does not allow the team to fully flesh out how some new component will function or look. Since one of the styleguide's purpose is to fulfill the role of a requirements document for UX and UI, it forces designers to design to the requirements. This is particularly useful after a project has been deployed and there are enhancements or iterative changes to be made, particularly by another designer. Via Auth0 When to create a styleguide While we don't always have the luxury of endless budget and time, I would argue (and so would Brad Frost) that spending design hours to create a styleguide before high-fidelity design even begins will pay off on the back-end of the project. By starting with the styleguide, designers are taking into account the UX decisions done in wireframing phase, along with any brand standards to apply. The styleguide will lay down the groundwork for the high-fidelity design. The completed styleguide should be handed off to the client for approval, which can then be given to production designers *and* to front-end developers. In a web project, while the designers are beginning their high-fidelity mockups, the developers are using the completed and approved styleguide to write base CSS that will drive the majority of the site's look and feel. Since the client has already approved the style guide, there should be no danger in having to "re-do" anything in rounds of revision. What's in a good styleguide? In creating a styleguide, the bare minimum should be included, for all required breakpoints: LAYOUT Responsive breakpoints Grid system DESIGN COMPONENTS Icons Image Galleries Thumbnails TYPOGRAPHY Font Faces Heading Styles and Type Sizes Paragraph / Body Styles and Type Sizes List Styles (ordered; unordered) and Type Sizes Any other specialized definitions, like form label styles or subheading styles INTERACTIVE AND NAVIGATIONAL ELEMENTS Buttons - rest, hover states Links - rest, hover states Main Nav - rest, hover, active states Breadcrumb Nav Togglers - on, off states Tool Tips - on, off states Alert boxes Modal / overlay boxes Custom form elements (checkboxes, radio buttons, selects, etc) COLOR PALETTE Primary colors and when to use them Secondary, tertiary colors and when to use them ANIMATION Loading icons Progress bars Any other animations the layout may require Resources and Citations Design System vs Pattern Libraries vs Style Guides: What's the difference? Nielsen Norman Group - Front-End Style-Guides: Definition, Requirements, Component Checklist Atomic Design by Brad Frost Styleguides.io - Collection of Styleguide Examples Sajio George Brand Styleguide Examples Stay Tuned for Part two of this post, where I will evaluate some helpful tools to streamline the process of creating a styleguide, as well as take a closer look at more examples and why they work!

When the question of what will define 2017 comes up, the response most often includes words like “Trump” and “populism” and “division” and “anger.” “Green” — not so much. Yet if you believe the team at the Pantone Color Institute, which calls itself the “global color authority,” green will be everywhere in 2017. Not just any old green, of course: Pantone 15-0343, colloquially known as greenery, which is to say a “yellow-green shade that evokes the first days of spring.” Green with envy.

Today, Chick-fil-A has launched a redesigned website with feature stories, recipes, GIFs, videos and other content as it tries to strengthen their connection with fans. The menu is now programmed to show the proper items for the time of day whenever someone logs on. So if it is before 10:30 a.m., the viewer will see the breakfast menu, while later in the afternoon they could be tempted by treats such as ice cream, cookies and milkshakes. What will they show on Sundays?

Like many publishers, The Financial Times used to treat its error page as an afterthought. Readers would land on when an article couldn’t be found. It was polite and had utilitarian value, but was drab and lacked personality. Last year, however, the British newspaper rolled out a new 404 page that espouses a clever list of economic theories why the page wasn’t found. The page is a result of a new unit: FT Labs. Labs is charged with tackling projects big and small that don’t fit into the normal development processes. A team for the big ideas.

Brands are moving beyond flat, motionless symbols for their corporate identities toward dynamic, ever-changing entities known as "living logos." In some ways, the concept of a living logo isn’t unique to the digital age. In the 1980s, televised MTV promos featured a logo in which the "M" was constantly changing colors. This was the first time a logo went from being static to animated. More than a mark.