Our industry is ever-changing. Get insights and perspective from our experts as we share our knowledge and experience on how to successfully navigate the marketing landscape.
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!
For mobile marketing, a moment of transformation is at hand. This transformation will bring with it the following five trends: (1) Consumers redefine purchase boundaries; mobile marketing, brand partnerships deepen; (2) Department stores, mobile marketing partners tackle the 'Amazon Effect'; (3) Programmatic accelerates: brands, tech, marketing continue to invest; (4) Technology drives measurement, verification advances; (5) Next-generation creative, video redefine mobile engagements. New year, new trends.
Black Friday had barely just begun, but already mobile traffic and sales were breaking records compared with years prior, according to third-party reports and those from major retailers. In addition to yesterday’s Thanksgiving sales report of a record $771 million in revenue from mobile devices, top retailers, including Amazon, Walmart and Target, have also released numbers pointing to mobile’s sizable impact on their online sales. Mo money, mo mobile.
App-install ads are a major success story in marketing these days. Facebook claims it will be responsible for 4 billion app downloads by 2017, representing up to 20% of its ad revenue. Google recently claimed its app-install ads prompted 2 billion downloads. The hype is real. That's about one app download for every human, which makes this advertising tactic among the most effective that mobile has ever seen. But do these alarmingly large numbers mean that native apps are a winning strategy for brands? The catch.
After years of scornfully dismissing the potential of smartphone gaming, Nintendo has decided to release Super Mario Run, the first Super Mario game for the iPhone. Though the Japanese gaming giant has famously pursued a "blue ocean" strategy—by creating products such as the Wii that catered to markets that competitors such as Sony and Microsoft didn't serve—it's also been held back by its share of dogma. The debut of Super Mario Run will take Nintendo to what may be the most significant part of its future: smartphone games. Make peace, not Wario.
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.
McDonald's has long been a leader in the fast food industry, but it has fallen behind its competitors in one big way: it hasn’t provided customers with a way to order and pay for their meals via smartphone or other mobile device. Now, the company is getting ready to roll out mobile order-and-pay technology. McApp coming your way.
Google, which is set to report Q3 earnings this week, now makes more ad dollars from mobile than from the desktop globally, according to eMarketer’s latest estimates of ad revenues at major publishers. But in its home market of the US, that revenue flip is still in the (very near) future. Mobile now reigns.