Posts About Notable
Posts About Notable
The problems we've run into designing amazing products have inspired us to build powerful tools, frameworks and resources that have helped us design better and faster. We've made many of these resources freely accessible to the open source community, and it's been nothing short of awe inspiring to see how millions of designers and developers use them to create amazing sites, apps and emails.
From Frustration to Inspiration
We didn't want to use standard frameworks or libraries like jQuery, Angular, Backbone, etc because we knew that our customers would be using them too. A native solution would greatly decrease the chance of conflict or breaking their pages logic.
We scoured the net for an open source, native, @mention library and came up with nothing. So we rolled up our sleeves, put our heads down, and got to work. The result of which is Tribute, and we're incredibly proud of what we've created.
Check out our Playground Page to see how it works and give it a try!
The worlds of video games and design share many common elements and have influenced each other for decades. We here at ZURB are on a quest to change the way people design, and what better way to get people interacting with our work than the medium of electronic games!
With our deep knowledge of design and cursory knowledge of videogame hardware, developing our own console was a no brainer. We're proud to announce the future of video gaming, ZURBA!
- A once cutting edge 8 bit graphics processor for eye popping visuals and zoetrope quality animations!
- An adrenaline pumping mono MIDI synthesizer audio engine capable of 4 note polyphony!
- A high latency, near ergonomic, single button wired joystick controller!
- A diverse lineup of launch titles including the puzzler 'Wobbly Woos,' the 'Yeti's Islet Jr.' platformer, the 'Legend of ZURBA' RPG adventure and the genre bending 'Car and G.U.N.' Each launch title features the beloved Notaballs characters from your favorite design platform, Notable!
Check out these lukewarm reviews!
The critics we spoke to did not want their names included in this article
Video games have taken one step forward and about three steps backward with ZURBA
ZURBA is the console I would have dreamed about if no other consoles had come out in the last twenty five years.
You control the car game with a gun controller?
ZURBA hits store shelves this summer (price TBD), but check out the link below to see the teaser commercial:
Facebook just unveiled a new way for their users to interact with content, Reactions. Users of the site now can express their thoughts and feelings on content through 6 emojis, love laughter, happiness, shock, sadness and anger. This presents a huge opportunity to companies placing content on Facebook, but also presents huge risk. With public sentiment from 1.4 billion people now front and center, how do you test how people feel about your content?
Social Test for Facebook
We're excited to announce we've expanded Notable's powerful selection of testing features with a brand new option for seeing how your content will perform on Social Media networks. Product and Marketing teams will find this app extremely powerful for testing how a product feature or content piece will be received by their audience. We call it the Social Test for Facebook.
Take a sample test and see how it works.
Purchase Test Results
Using our worldwide pool of diverse testers through Enroll or your own users, you're now able to test and get an accurate reflection of how your content will be received using the same style of 6 emoji reactions. Optimize your content to get the best results before posting live, and set your content up for success!
This powerful new testing option is available in Notable, our design collaboration platform. Request access to our private release today and start optimizing your content.
When we talk to product managers and product designers, there is one question that we hear over and over again. 'How do you get your team to agree on what to build next?' Most people will agree that ideas are cheap, and the people on your team have lots of them. How then do you know which to pursue, and how do you keep the team engaged, when not everyone's ideas will be selected?
First, let's take a step back. We're firm believers that anyone can design and anyone can be a designer. There is no mystical superpower or genetic predisposition that gives someone the ability to do design. We don't believe that only designers or those at the top should be making decisions and passing them down to the rest of the team. Rather design is everyone's responsibility, and Progressive Design makes it easy for everyone to be involved.
A critical part of Progressive Design is the Design Feedback Loop. It's a simple process that encapsulates the 4 core components of what a product designer does to influence teams and move products forward. Using this process to structure debate around our designs builds and sustains momentum, as well as helps us to design better and faster.
Create, show, react, shape
Before we get into the 4 steps of structured debate, let's state some assumptions about your team and product design so that we're all clear on the context of what we're talking about here.
You work with other people
Even if you are a company of one, we assume you are at least building a product that will be consumed by others (probably yourself included). Product Design is about creating something to be used by people, and if you're not designing with people in mind, then structured debate does not apply to you (and we're not even sure what it is exactly that you are doing).
These other people know things you don't
Your team is composed of people that know things you don't know, and you value them for this. Your customers may not know what they want, but they know (even if they can't communicate it) what will make them happy, what they will buy, and what they will reject.
You influence your product's impact
You may be the product manager, the CTO, a front end developer, an icon designer, a growth hacker, or a customer advocate, it really does not matter. What matters is that the work you do directly influences how your product changes the people that use it.
You care about creating something of value
If you're just looking to satisfy your manager or get points with the CEO for design that pops and sizzles then you can stop reading. To create value you also need to be (or are capable of being) a good listener. If you're not able to listen to your team or your customers, then these practices are a waste of time.
Great, we've got that all that taken care of, let's get into the good stuff.
Step one: Create
This may seem obvious but you (whoever you are) need to create something to be able to talk about it with your team. This may be a sketch of the interface or a coded proof of concept. It may be a visual mockup in photoshop, or copy for the site. Research even counts so long as you've synthesized it with the needs of the product and it has more depth than clippings from Fast Company.
Here are two things that do not fall into the create category and derail debate:
- An unprioritized list of things for other people to do
- Long speeches about the importance of doing a thing
These are things for sure, but in the context of product design they don't count in the create step.
Creating things is essential to creating momentum. Creation shows effort and investment. People know when you are half assing it and real effort inspires effort. The best way to get a conversation started in a constructive direction is to start with the work, the things you created and take it from there.
Creation creates clarity. Words are a poor substitute for many mediums (namely visual ones). Words also tend to be highly contextual to a specific conversation or person, and quickly lose their potency. When you lack clarity you'll likely end up debating the wrong thing, wasting time, and creating frustration for everyone.
Lastly if there is no creation, there is no product and there is no change. It's the most important thing that needs to be done if any result is expected. Ideas are cheap. Creation is the heart of design, and everyone should be doing it.
Step two: Show
You did something? That's great! Now you need to show it. Remember in grade school your math teacher always telling you to show your work? Well maybe you hated it then, but in design the work you show is more important than the answer. Don't be afraid to show early, and show often.
Remember all those smart people and customers you're working with, the only way you can take advantage of what they know is by showing your work. As a good product manager, encouraging the people on your team to show their work is your chief concern. Not because you are an authoritarian top down manager, but because you know that creation in a vacuum is toxic. It's not about you approving or disapproving of the work, it's about facilitating the showing of the work so that everyone on the team is contributing their expertise to the result.
Ed Catmull of Pixar talks about getting people to show their creative work everyday, how painful this is at first, and how critical it is to their creative process. It's more effort to show the work early, and it's not comfortable to show something before it's complete. But the benefit is that when you are done with the work, you are done. You already showed it to other people, and you already incorporated their feedback. No big reveal, no surprises or anxiety at the end.
Showing what you created is how you ask the question that you are going to debate. It's your opportunity to frame the problem. Think about a simple question like 'Is your coffee perfect?'. It primes the respondent to ponder the perfection of the coffee. Now ask 'Is your coffee too bitter', and you're making the person think about the bitterness, something they may never have considered. This is a simple example, but one that shows how the presentation (how you show the work) frames the debate you are structuring. Absence of framing gives every participant free reign to take the debate in whatever direction they like.
Step three: React
The direct result of showing your work is getting a reaction, and this of course is where most conversations take a turn down Random Feedback Street and then head straight down Complete Waste of Time Avenue. The key to getting the right kind of feedback to make the debate constructive is how you set it up with the work you created and showed to the group.
During a conversation, the team will have many reactions to the work you show. The model here is to mentally process these simply as reactions to the work. There is a natural inclination to try and work through the feedback right away and solve the problem. This only works for the most trivial decisions and fails for larger more nuanced problems.
Avoid the temptation to solve the problem right then and there. New ideas are fantastic and start flowing when you show new and interesting work. Make note of them and riff on them, but don't get stuck trying to solve a tough problem by coming up with more ideas and immediately evaluating them. It's easy to get into a 'lost keys' state of mind where you're racking your brain for a solution when none is immediately present. It's better to record the reactions and move on to the next problem. Nothing kills the energy of meeting like waiting for someone to find their 'lost keys'.
There are a couple different types of reactions that you may get:
- Positive reactions: You've done a good job, they liked what you did. Pay attention to the chord that you hit, is that what you were going for?
- Negative reactions: Your worst fear, they didn't like your work. Before you throw it all in the garbage ask yourself why. Did you show the work with the right context? Is there a better way you can present the work? Negative can be a good thing, it's validation that you're creating something interesting enough for someone to say 'No'.
- Neutrality: The worst of all outcomes. You showed something so lame or obvious that the viewers could not even be bothered to mildly dislike it. If you are not getting any reactions from the things you are creating then create something more interesting.
Reactions are an important way to learn something about the work you did and gain insights. You can fiddle with the pixels of your creation all day, but without fresh insights, it's not going to change much.
Step four: Shape
You created something, you showed it to someone and they reacted. Now what? Now you get to decide what happens next. This is where actual decision making and responsibility combine to allow the designer to make decisions and move the project forward.
Shaping happens outside the larger group, and has a single person with the final authority for making decisions. But there is a catch. This decision maker may have complete dictatorial power, but they are also responsible for showing these decisions to the larger team again and defending them. Ultimately they can shape the reactions in the following ways:
- Ignoring reactions: Don't think the person knew what they were talking about? Don't think it's the right thing to do? It is well within your rights to ignore a reaction, so long as it's a choice. Sometimes facing a hard truth can be difficult and we ignore it, this is not productive. For everything that we choose to ignore, we need to have a reason, and that reason needs to be communicated back to the person that gave the reaction.
- Incorporating reactions: Taking and implementing an idea wholesale is the easiest thing to do. Sometimes the feedback is deeply insightful and this makes sense. Otherwise ask yourself if this is the right way to go.
- Synthesizing reactions: What does the reaction mean? What does it mean in the context of the larger goals of the project? Most good reactions fall into this category. Insights that are not prescriptive, but change you perspective (if ever so slightly) and influence the next thing you create.
And then you do it all again
Here is the trick, there are not four steps to be done once, or even once per project. The way you get better at product design is by repeating these steps as quickly and as often as you can.
You can think about improving as a product designer by improving how you can optimize these four steps. How can you break up the work you create to show it more often, while still having something interesting to show? How can you effectively show the work to get reactions that will help you shape the work and then create more work? There are the questions we ask ourselves everyday, and almost everything that we write about has to do with these four practices.
Maybe you went through this and found it all to be pretty obvious, great, that's how it should feel. Maybe this just feels like a Communications 101 playbook on how to work in a group. Well guess what, that's kinda what product design is, and that does not make it any easier. Remember how difficult it was to work in a three person group on a simple essay? Long nights of getting next to nothing done and having to tolerate smelly apartments and terrible music. Now try working on a running product with dozens of teammates, tens of thousands of active customers, and millions of potential people you could be selling to. This stuff is really hard.
What we hope, is that by giving you a mental model for thinking about how groups come to decisions you can be more successful. We live this stuff everyday and build it into everything that we do.
Notable and product design
We built Notable to help us live these steps and do them more effectively. When we create a feature in Notable, we think about how it fits into create, show, react and shape. From day one we believed that people should not create in Notable. The medium was too constrained. People should feel free to create anywhere (from napkins to photoshop) and be able to upload what they created into annotations, or create clickable prototypes, or even upload coded prototypes.
React was the core of Annotations, where you can leave notes directly on the work someone else did. We've been showing our work to clients for 17 years, and all of that thinking was baked into Influence, where you can easily create a story around the work you are showing and put it in the context of a process. Shape is an area that largely done outside Notable, but this is something that we want to explore.
More to share
This post was just about what the practices are. They are a mental model for thinking about what exactly we do as product designers. We've got much more to share about the methods we use to create and show our creations and how to react and shape reactions from others into better creations. We've learned a lot and are constantly learning more. We're looking forward to continuing to share what we learn and learn from others too. Thoughts?
There is a lot of excitement about the Internet of Things and electronics being smart. Actually the excitement right now is just around electronic devices being able to communicate with each other at all, never mind the smart part. If you can attach a Raspberry Pi to it, people will and probably already have. We recently saw a toaster oven that can send you a text when your toast is ready.
That's cool and all, but toast text messages are not nearly as interesting as a home of electronics that are designed to work together and solve people problems. Imagine your refrigerator communicating with your phone to let you know what ingredients you're out of when you're at the grocery store, or a washing machine that alerts your smartwatch that your clothes are done so you can move them into the dryer so they don't sit wet all day. That will be the difference between just an Internet of Things, and the magical world of tomorrow we're all waiting for.
This type of seamless connectivity, connectivity for a purpose that solves real problems, is what we set out to achieve with the new Notable, our product design platform.
Designing a Winning Product for Winning at Product Design
Over the last six years we've built a number of products, each designed to solve a problem or pain point that we hit when practicing product design. Notable was originally created to help us create product audits. Verify was built to quickly validate design decisions through gettting ideas in front of real people. Solidify was designed to create clickable prototypes with the goal of quick iterations, not wasting time building complex prototypes or spending hours attempting this in Keynote. Influence was made to help us quickly and professionally present our design work when we were manually posting everything as static HTML.
We love each of these products and as a complete product design solution use them significantly in our own process. Not only do they help us to solve acute problems, we've found that they actually make us better product designers.
But we always knew that what we were creating was more than just individual solutions. The real impact would come from all of the apps working as a whole. For example, getting the results from a concept test and being able to click straight to the prototype and see where people are getting stuck is an entirely different experience than hearing about the test going poorly in a meeting and trying to track down the designer to get a peek at the prototype.
Twelve months ago we began work in earnest to combine all of these distinct offerings into into a single platform. Now hundreds of sketches, thousands of commits, and millions of pixels later it's complete.
The New Notable: Helping You Win From Concept to Code
Notable was the first product we created. It was about leaving notes on screens, but it was also about doing 'notable' work. Some teams build products to make a lot of money, some build products to serve a company or community need, still others build products to create marketing value. But all creators or products want people to take note of what they have done, they want their work to have value and mean something. They want to do something Notable. That is the aim of our platform, and why we took the name from our first application (Notable) and made it the name of our entire platform.
Like the Internet of Things, our goal was to do more than simply connect our products together. Our goal was to create a set of design tools that are cohesive and easy to use to connect you, your team and your work. The new Notable walks you through product design, from concept to code, helping you collaborate more easily and keeping your whole team in the flow of forward momentum.
120 Days to Public Release
We've been using the new Notable in production here at ZURB every day for the past 8 months. It's all of our tools and techniques in one powerful package, and has both sped up and improved our work. Battle tested day in and day out, we're continuing to iterate and evolve the platform up to our public launch and beyond.
The new Notable will be available to the public in 120 days. Until then, it's in private release and we're letting in a limited number of people to start using the applications now. If you're interested in getting your hands on these powerful design tools and seeing how your team can build something truly Notable, sign up for the Private Release today and let's get you started.
A product designer's journey is filled with wonder. It can also be rife with peril and despair. So how do you enjoy the awesome parts of product design without letting the negative parts discourage you and get you down?
A Product Design Odyssey
We design products at ZURB. We design products with clients, with internal teams, and we train people to do the same in their companies. Since 1998 we've been helping people design products and we've learned that amazing sparks can happen when teams work together seamlessly. We also learned that if good flow is interrupted it's hard to get up and be productive again. We put together a list of our top seven product design challenges and how we've overcome them.
Feel #1: Getting a Crew Together
Getting a team together is a risky challenge for everyone involved. Learning to improve your value as a team member is an ongoing process where you become skilled enough to earn autonomy in your work. We value problem-solving abilities above all else, and we hire based on a skill-set baseline — as well as that passion and drive to solve problems.
Joining a team doesn't end when your butt is in the fancy Aeron chair wrangling pixels. Hiring is risky for teams because a new employee could either uplift the team or set everyone back and lower morale. It's also risky and stressful for the new employee who feels anxious to perform at a high-level from day one.
How to deal with the feel: We get buy-in from the entire team on new hires. When we vote to hire someone, we're committing to supporting the person in their career and have become invested in their success. This is great for teams because it reduces a lot of politics that growing teams traditionally suffer from, and helps new peeps acclimate faster.
Feel #2: Set Sail to Iteration Island
When you're working toward a product release, it seems like the release date is everything. Problem is the relative quickness of building things gets people to commit too quickly and assume that their solution to a problem is the best. That means when a stakeholder inevitably sends feedback, designers will flip tables.
Designers get a lot of flak for being attached to their work, but what non-designers don't understand is that this comes from a good place. This attachment is (usually) a result of passion, not arrogance. There's nothing worse than a designer that immediately responds with 'I'll change it!' when his design decisions are questioned. So, designers … get mad! Tension is great as long as everyone is engaged and gives everyone else the benefit of the doubt.
How to deal with the feel: seek out feedback. The more you ask for it, the more trust you'll build with stakeholders and getting feedback will become less stressful. When stakeholders feel trusted, they're less inclined to constantly nudge product designers because they know that their feedback is valued. A Progressive Design process requires a tight feedback loop, initiated by the person who did the work. Practice getting feedback often by checking in with other team members. Be 'disruptable', and encourage your team to do the same. Learn to disconnect from your work, then assume that the person giving you feedback means to improve the product. They don't want to tear down your amazingly flawless work. They want to help you grow by reframing the problem and finding a better solution together.
Feel #3: Everybody Get Out and Push!
When deadlines loom, everyone needs to contribute. While top-down guidance is necessary, in execution everyone should contribute tangible value to the team outside of planning and keeping everyone on track. Contributing value doesn't necessarily mean pushing code — stakeholders can talk to customers, stay on top of analytics, write content and marketing materials. There's definitely no shortage of things to do as a team gears up for launch.
This might get some pushback from folks more inclined toward traditional management, who see living in a spreadsheet as just as valuable as pushing code. However, something magical happens to a team when they see the leader out in front pulling them towards success.
How to deal with the feel: We don't have any managers at ZURB. Design management is certainly a key skill for a leader, but it's not a role. Leaders know when to manage and when to directly contribute, and they have the skills to do both.
Meet Matt our Notable team lead, and Nic our customer advocate. Over the past couple of months, they've been working together on customer development efforts — demoing the product, collecting feedback, and signing people up for early testing — while also working through feature iterations and fixes on the new Notable. They both contribute immense value to the team by speaking to customers and relaying feedback while the rest of the team iterates on the product.
If you want to boost your team's morale, get out and push!
Feel #4: Avoid the Siren Song of New Trends
Flat design is in? FLATTEN ALL THE THINGS! Motion is in? If it ain't bouncin' around my page it better GTFO! Bunnies are in? Put carrots everywhere! Trends are shiny and interesting, but they distract teams from focusing on problem-solving. At the end of the day, if customers can't complete a task or get their information, they won't care if your site has sleek SVG animations everywhere.
When the hamburger navigation pattern first became a thing (I want to say Facebook is to blame for popularizing it), everybody jumped onboard. This is it! This is the holy grail of navigation. Slap it on every site you own. Even we at ZURB jumped on this bandwagon. A few years later, we're realizing that despite the ubiquity of this pattern, users still have no idea what to do with it.
How to deal with the feel: In building the new Notable, we have a few key tags in the GitHub repo to help us prioritize features and issues.
There are a couple of labels that are obviously more important than others such as 'High Priority' or 'From Bryan' — both essentially meaning: Address Immediately. Then there are labels like 'Discuss' and 'Nice to Have.' These are usually added to issues that are not mission-critical. That makes it easier to prioritize which issues to close down. If it ain't broke don't fix it, unless you've run out of broken things to fix.
I just want to be heard. I want to challenge us to be better as a team and pass on all the knowledge that I've gained from working on this for six years. I want to share the two-hour conversations we had hammering through an idea four years ago that influenced the result!—Bryan, Chief Instigator
Feel #5: Plunge Into the Pit of Despair
It's bound to happen. Things will go wrong and they'll go wrong all at once. Your image-uploading code will fail, your comment system turned out to be a lot more complicated to use than you thought, and you missed out on implementing a feature that was important to some of your biggest customers!
Welcome to the pit of despair. You are not alone.
As product designers, we're not unfamiliar with the pit. It hits hard, coloring your whole project and makes issues seem way bigger than they are. It can be caused by the smallest problems.
We fell into the pit of despair in designing the new Notable. We were trying to get the app to work functionally and neglected the visuals. This led to the app appearing broken even if it wasn't, which caused everyone to feel run-down and ineffective. A quick visual facelift made the team feel better about their work — things were looking less broken, which gave us the push we needed to climb out of the pit of despair.
How to deal with the feel: Keep calm and make a list. Remember the prioritization system that we talked about previously? This will again be the solution to your problem. No matter how big or small it is, what is the most completely broken thing? Figure out a plan with your team to tackle that first, then move down the list. Without a prioritized list, it's difficult to get out of the pit, so make sure your list is always full of things to do. Once you're done fixing things and you get out of the pit of despair, you can start making a list of things to improve, i.e. the fun stuff!
Feel #6: Venture Through the Straits of Slow Servers
There's nothing more frustrating than working through several iterations of a feature, ironing out minute interactions, and getting everything in place — only to have your servers crap out on you. Put yourself in the customer's shoes. They're even more frustrated than you because they're trying to get their work done, and all they get are server errors. This can frustrate you and leave you feeling helpless, especially if dealing with server issues isn't your strong suit.
About a year ago, an newly exposed SSL vulnerability affected pretty much every site out there, including Notable. The engineers on the team were hard at work fixing the issue and patching the problem. The designers and customer advocate were dealing with a totally different problem — in a crisis that could only be fully resolved by writing code, how can non-engineers contribute in meaningful ways? We put together a plan: we knew that we had to be upfront with our customers and clearly communicate the issue and how we're working towards resolving it.
How to deal with the feel: Face the issue head-on and work with your engineers to figure out the problem. We described before how designers (including engineers) are also customer advocates. This is more true when there are problems. Stop feeling helpless and start talking to customers. If there's a server issue, make sure you reach out to people and let them know that you're experiencing problems. Provide frequent updates and make sure you get back to anyone who emailed or tweeted at you with complaints.
Be honest about the situation with your customers and work on helping them achieve their goals, even if it's at the detriment to your product in the short-run. Tim Cook did this during the heights of the Apple Maps problems. By recommending other apps, he might have turned people away from using the apps in the short term, but he won over customer loyalty in the long run because he was honest, vulnerable, and most importantly showed that his primary concern is solving the customer problem.
Feel #7: Explore the Caverns of Customer Development
So you've been working on this product for a couple of months. You're pretty proud of the work you were able to accomplish with your team. You set up a call with a customer to get their feedback, and suddenly everything seems more broken than it actually is. You notice every misplaced pixel and every broken interaction, even before the customer calls it out. And then the customer calls out other problems that you didn't even notice!
How to deal with the feel: In the words of my favorite dad band: Get over it! Your customers are the reason you're still around, so make sure you listen to them. There's a worrying trend in the industry— that by not talking to customers, you'll somehow build a simpler, more focused product. Wrong. As we build the newfangled Notable, we're also demonstrating the new platform to at least one customer per day, getting feedback, and iterating based on customer needs and business goals.
Customer feedback isn't a to-do list. It's feedback that you still have to organize and process before letting it influence your work. Feedback helps you justify your design decisions, as well as challenge your assumptions. It's not an excuse to put your brain on a shelf.
Product design is a roller coaster. It's super scary at first — there are a lot of pieces that all need to work together to solve problems. It's also exciting, and as you're getting on the ride and ramping up, your excitement and fear escalate — then you plunge for that first time, realize there's no turning back, and start to enjoy the ride. Once it's over, you know you'll be right back in the front of the line for another go!
Notable, our product design platform, is now in private release! Get access today! Get Early Access to Notable
Five years ago, it was all about UX, but we saw through that. At the time, we were pretty stoked about figuring out the best way to get to answers in product design (still are!). However, we realized that there aren't a lot of designers out there that understand what it actually means to be a product designer.
UX is one part of it, but what are the rest of the pieces? This is the story of how you too can become a product designer. So stop being a UX/UI guru or prophet or whatever and start solving problems.
The Values of a Product Designer
Product designers not only need to have a core set of skills, but a few key values as well. Embodying these values is just as important as being able to solve an interaction design problem or code up a page.
Balancing customer needs and business goals
This is the bread and butter of a product designer — the baseline requirement. If a designer isn't able to do this, they're not a product designer. Why? Because product designers should aim to find that sweet spot between customer needs, business goals and technical feasibility. These three areas are what blur the lines between a designer and a developer in the "traditional sense," and the reason why we've done away with those tired concepts at ZURB.
Keeping an open mind
Product designers get excited about new ideas, and doesn't always shoot things down. In turn, they aren't afraid to question their decisions, or let other people build off their ideas.
Knowing when to say no
Conversely, a product designer also knows when to say "no." More importantly, she'll know how to say no — backing up her decisions with data, customer feedback or her own past experience. Because she understands the customer needs, business goals and technology, she's able to justify her design decisions and move the product forward rather than run around in circles.
These values are a riff of our own ZURBian values. We consider everyone on our team a product designer, including engineers. So if skills are only one part of being an awesome designer, how do you turn these three values into practice?
Breaking News! You're Now a Customer Advocate!
You'll hear a lot of UXers talk about empathy, which sounds really warm and fuzzy, until you realize that you don't really know what that means in the context of a product. Here's what it really means: when a feature breaks in your product, you will do everything in your power to fix it for your users.
Which goes to say, if you don't know what the problems are … you certainly won't figure out what future ones. Product designers need to invest themselves in customer problems to anticipate future problems that might come up.
No one on the team is exempt from customer advocacy. Simply put, everyone involved in the product is a customer advocate, including designers, engineers and marketers. Typically, a designer won't interact directly with customers, and that can be incredibly detrimental to the design process, whether the designer is working on a client project or an internal one with a team. You can't think of customer advocacy as just a 'customer support problem" or an "engineering problem." It's your problem too!
Engineers Are Product Designers Too
Product design happens when decisions are made, and everyone should be decision-makers, including engineers. While designers should write their own code, engineers should likewise be trained in the same product design process.
A small team with a designer/engineer pairing is one of the most effective way to build a product. The designer should be constantly asking the engineer for her feedback on implementation and technical feasibility, while also trying to stay in front of problems. In other words, they need to be continually collaborating. But in order to have a nimble team like this, you need to have a few things in place:
- Clear Communication: This goes without saying, but seamless communication with few barriers as possible is essential. The barrier could be really simple. Laura likes to send her deliverables over email and Bill only checks his inbox once a day. In this case both peeps need to figure out a communication method that works well for both of them. In other cases, the communication problems could be deeper, and the earlier you identify and work on them the better your process will be.
- Blurred Lines: Don't overdefine the roles. Designers should code their own design work, so they can continue to work through the interaction nuance that only really comes up once a design is in code. Engineers should also contribute to the interactions by giving feedback and sketching out ideas. After all, there's no room to get territorial in product design.
Detailed Spec and Testing: Designers should clearly spec out their static code before they hand it off to an engineer. A typical designer-to-engineer handoff at ZURB contains two things:
- Static Code: This is the complete static code for the feature in all its different variations and error states. This is delivered in a shared Git repo.
- Annotated Set: The feature spec is created by the designer in an annotated Notable set that highlights all the functionality that needs to be implemented.
These are the absolutely necessary pieces to a functional collaboration. We'll also usually create an issue in the Github repo to track discussions and updates around the feature, and use it to handle assignments.
Of course, the designer's work isn't done with the handoff. That communication needs to be maintained during and after the feature is built, when it's up to the designer to comprehensively test every interaction in the feature. We use a spreadsheet for every major feature, and document every single interaction and state in that spreadsheet. We then test those interactions, and if an interaction is A-OK we mark it as green. Otherwise we highlight it in eye-bleedy red and create an issue in Github for the bug.
It's so satisfying when this…
turns into this…
Those Who Don't Know History Are Doomed to Repeat It
Effective product designers need to stay ahead of the rest of the team, which means that they'll often have to be the first person to spot a bug or come up with an idea. The best way to stay ahead is to know your own history. Efficiency is crucial to staying out in front, so designers have to be careful and not reinvent the wheel. For designers new on a product team that has existed for a while, this means doing a lot of homework to learn why certain design decisions were made, and why the product functions the way it does.
As we build the new Notable, we were working on getting rid of the Organize feature because, through our own use and customer interviews, we found that people were mostly confused by the feature and never used it. Our design problem was: how do we maintain the existing functionality of the Organize feature, without tossing all that functionality into a separate confusing page? After a few iterations, we realized that we'd just reinvented the same feature and called it a different name. We ended up completely rethinking the functionality and its purpose, coming up with a much simpler solution.
You Can't Solve Problems in Photoshop
Studies show that 90% of designers will jump into Photoshop/Sketch to solve problems1. Product Designers will ask why five times before implementing any feature. They'll create prototypes, run tests, check analytics data, talk to customers, and discuss ideas with their team. Notice how Photoshop isn't required for any of these things. Drop Photoshop and start designing products. Unless you're working towards a deadline, in which case what are you doing reading this article?
Designers shouldn't be using their tools as crutches in product design, because most of product design happens outside the computer.
1. Not a real study
The Rise of the Gut Thinkers!
So where does a product designer fit into a progressive design process? A product designer should be the person driving decisions, even if they're not directly making the actual decision. The product designer has the experience and guts that allow them to influence informed decision-making among the team. We've learned two things about product design from working on our new Notable release:
- You need a really convincing reason for why you should add or remove a feature
- Getting those convincing reasons involves a lot of work that a typical designer isn't typically trained to do
Take for example the next version of Notable. We wanted to make sure that we were maintaining all the existing features. Bryan sent the team a list of features that were in the old version that were missing from the new version. While working with the customer advocate through the list, we noticed the Nudge feature was on there, and our gut reaction was, "who even uses that?" When we built the first pass of the new Notable, our first instinct was not to build the feature, and focus on features that were more valuable. We needed a good reason to convince Bryan that this feature wasn't necessary, so we turned to our analytics. We tracked the Nudge feature in the existing app for two weeks, and the results we found will shock you!
Turns out, our gut was right! A mere 0.1% of our users used the Nudge feature in those two weeks. We were able to push back on the feature and focus on other more frequently used features.
That's No Moon…
You might be asking yourself why anyone would want to become a product designer at this point. Well, because it's amazing. You get a feeling of certainty that you wouldn't get with say, a purely visual design role. Practicing product design trains you to think with your gut but not rely on it. Product design allows you to empathize with your users and make sure you're solving business problems too. Figuring out a great flow for your team is how you can get everybody on the same path, whether they speak Photoshop, Rails or Wookie.
Product design is about teamwork, because it's really hard to learn to do all this stuff by yourself. Product design problems are kind of like the Death Star — they're big and intimidating, and can seem almost invincible. By identifying the problem, getting the right team, then getting that team to work together seamlessly you can take on any Death Star.
Notable, our product design platform, is now in private release! Get access today!Get Early Access to Notable
Think of a designer. You might work with a designer, or you might have seen one in passing with that unmistakable designer affinity for apple products and snark. You might even be one yourself! Now picture this designer working. You're probably imagining this person heads down at an immaculate desk with a Moleskine in hand and earphones in their ears. She's blissfully pushing pixels around a screen until they're just right. Ah, DESIGN!
What this designer has done is isolated herself far away from her customers.
Design is a Conversation
In Let's Make Mistakes, Mike Monteiro talks about the hiring process for designers and doing designer tests. A common test is to give the designer a popular site or app and ask them to "redesign" it. In the podcast, Monteiro's rather succinct and appropriate response to this practice was 'You're not designing d*ck.'
Design is a process that involves learning about the business goals of the product, as well as the customer needs. Taking a quick pass at a visual update is not design and will not help anyone find out if a candidate will be a good designer.
Step Away From the Pixels
Design is hard, but talking to people is harder. A product designer needs to master both doing awesome work and presenting it awesomely. There's no such thing as a great designer that just pushes pixels around. If a designer can't sell her work, then she's not doing her job. In over 16 years of experience with design, we've figured out that designers can't work in silent isolation. A great designer asks questions, and doesn't treat feedback or a requirements document as a to-do list.
A Requirements Document Isn't a Product Recipe
' Which leads us back to the PRD, or product requirements document. It's a living document that evolves as you get feedback from customers. We're waging war against the traditional PRD. These documents can hold the team back and keep people from innovating. There are better ways to prevent feature creep, either by using a PRD or ditching it entirely. If you're a consultant or a project manager at an agency, you might think that PRD's are a good thing because they give you clarity. A PRD, however, will not get you to the right answer.
Everyone Should Present Their Work. Yes, Even Product Designers
We should clarify that when we use the word "customers," we're talking about both customers in the product sense and clients in the consulting sense. Clients are customers too, so whatever we say here about product design and customers applies in an agency environment and consulting relationships too. There's a gap between product designers and consultants. Product designers think they're above selling, which couldn't be further from the truth. Every time a product designer presents a new feature to their team, they're selling that work. Consultants on the other hand, don't traditionally think about problems to solve, and will immediately jump into their comfort zone. Designers need to get more comfortable with presenting &mdashl and talking with customers.
Sold. Talking to Customers is a Thing. Now What?
There are a few things you're going to need to do, starting with actually finding your customers. If you have an existing product then that's great! You already have a pool of customers you can tap into. If you're still building your first iteration and you don't have any customers yet, then you'll need to figure out where your customers hang out. Go to forums, visit link sites they might frequent, tweet out with appropriate hashtags. You'll basically want to do the opposite of being "stealth."
Brace Yourselves. Feedback is Coming
Don't just hop on customer calls unprepared. A customer call is a great opportunity for show-and-tell, so flex your presentation muscles and get dialin'. In fact, it's mandatory that you hop on a call or walk into a room with something. Like, are you working on an awesome new feature? Are you updating your visual styles? Bring that with you! Most of all, consider the type of feedback that would be most valuable to you, then go present the work that will get you that feedback.
As we're working on the new Notable release, we're also constantly getting on calls with existing customers to show our progress and get feedback. This feedback has been incredibly valuable to us and not just on the product-and-features front. On one of the calls, we presented our new marketing site to a customer. We got validation on a lot of the decisions we'd made in our design, but we also got some feedback that we wouldn't have noticed on our own. For instance, we're combining all the apps into a single platform with the next push, and we hadn't made that quite clear in our marketing site redesign. This was easy for the customer to pick up on, because they're looking at the site with fresh eyes, but our own team never really saw the issue until it was highlighted in that particular section of the site.
Forget Shipping. Talk to Customers Early and Often
Shipping is great. As far as a customer is concerned, if you don't ship your product doesn't exist. Now that we got that out of the way, you need to also talk to your customers early and often. Don't wait until your product is "complete." Let's face it ' designers are perfectionists, and we'll polish and polish until the cows come home. That's awesome, but not helpful if you're to have an effective design feedback loop.
Talk With Your Customers, Not at Them
We used the word presentation to describe what you'll do on a customer call. This might be a bit misleading. Why? Because you should not be doing all the talking on these calls. Sure, you have a message you want to get to your customer, to get them excited about an upcoming release or a feature update, but this is really all about the customer and their feedback. That's what will help you improve your product.
It's Just a Customer Development Thing
Talking to your customers is not as daunting as you might think, as long as you have a plan! It's almost like a formula ' do work, present, get feedback, filter and organize, do more work, etc. There is a missing piece, however. What happened to that customer? It's a little cheesy, but one of the most fulfilling parts of building a product is growing it along with your customers.
As your customer base starts to grow, it will be more challenging to keep track of everyone you talk with. This is why keeping your customers in a solid CRM is absolutely necessary. The problem with a conventional CRM is that designers don't like to use tools like CRMs. You might as well ask your designers to use spreadsheets.
We've been trying to figure out how to work better with our customers, which is why we're building Customer Lists as a primary feature of our upcoming Notable release, which you can see a sneak preview below.
These are easily accessible customer lists that you can assign to projects. Designers will then have very little barriers to sharing content with customers. This isn't a replacement for a traditional CRM, of course. We use Zoho CRM here ' it's super helpful for keeping track of customers. For designers, however, we needed a simpler way to share design work with those customers. You create a customer list in the same way you would in any CRM: simply type out names and address or upload a CSV, and Notable will do the rest.
For example, you can create a customer list named "Mobile Users." You can then assign this list to a project for a new feature you're building. The next time your designer builds a prototype, they can quickly share that prototype out with the Mobile Users list. We're being a little sneaky here, eliminating the usual scheduling or access privilege excuses.
But in the end, it'll help designers reach out to more customers so they can get feedback and have more meaningful conversations, where they're taking with each other to make a better product.
We're experiencing yet another growth spurt here at ZURB. This month we're boosting our Design Apps team with not one, but two new ZURBians — one engineer and one customer advocate! So without further ado, let's meet…
Bill Tran, Rails Engineer
Bill grew up copying comic books because he wanted to draw like a comic book artist. Yes, he was that kid who who drew Bart Simpson and Teenage Mutant Ninja Turtles everywhere he could find a place wide enough to fit "kowabunga!" As a teenager he taught himself how to breakdance, draw graffiti art and, best of all, to customize cars. That's when he found his calling.
Bill's interest in cars, especially building custom vehicles, revved his career in prototyping. He fell in love with industrial and automotive design, dreaming up ideas, iterating through designs and building the real thing. So he spent the last 10 years chopping things up, machining raw metal and plastic, designing 3D parts with SOLIDWORKS, and painting the final objects with aesthetic flair. He spent a few years building prototype cars with Honda, and a few more with 5 Axis Models who built concept cars for Toyota Scion and Lexus.
But computers, it seems, were inevitable. Bill had been around them since the old Mac Classics in elementary school, and he'd built a few of his own custom PCs for fun. And as the auto industry began to lag in 2008, he decided to trade aerodynamics for streamlined user workflows, and began to teach himself Ruby on Rails.
But it's not all cars and code. Bill is also a family man: husband for eight years before joining ZURB, and the proud father of two girls, both under ten, both makers in the making.
Bill's career steered him to join ZURB as a Rails Engineer shortly after his first ZURB Wired event — one of the fastest prototypes he's ever been involved with.
Nic Edwards, Customer Advocate
Nic has a history of escaping to foreign lands and picking up new languages, including French and Japanese. He also loves cooking so much that he graduated from the Professional Culinary Institute. Nowadays he's fairly adept at cooking large pieces of delicious pork.
In 2013, Nic took a General Assembly design crash course — and got hooked. When he learned about ZURB through Louis, his predecessor here and high school friend, he knew working here would be a great learning opportunity. So far, he says, he was right. "It's the perfect place" to achieve his ultimate goal of designing great products.
According to Netflix, he's a daily binge watcher. And while he hasn't sportsballed, he's handy with a fencing sabre. Sometimes you'll find him rowing or pushing his limits in CrossFit. To that end he's taken on a weekly role — a cinnamon roll, that is — to get swoll in all the wrong ways.
His travels have brought him almost full circle back to Campbell, just a few miles away from his home town of Los Gatos, CA.
Everyone please give a warm welcome to our new ZURBians!
Product teams competing on features are racing to the bottom. The design process and the design feedback loop are crucial to a successful product, and this feedback isn't just important on fleshed out prototypes, but for initial rough ideas as well.
We talked about PRDs and the unnecessary constraints that an archaic document will place on the team and how that hinders innovation. Here, we will look at the situation from the opposite point of view — what kind of product will result from an uninhibited flow of ideas?
The Engine of Design Thinking
You'll hear us talk about this a lot. This is design thinking. Designers cannot succeed without a feedback loop made up of design work, feedback, and iteration. At the center of this is the design work, which is not important in itself, but it is a way to solicit feedback and get the conversation started. Feedback is the conversation that is triggered by design work. This feedback can come from customers and stakeholders, and it will drive iteration.
At ZURB we think of each product release — and client project — as an iteration, and each iteration is composed of smaller feedback loops throughout the project. This philosophy works great when the team keeps the bigger picture in mind, while soliciting feedback from each other, as well as customers, on a regular basis to drive progress.
Wouldn't It Be Cool If …
It's tough to keep brainstorming sessions productive. Designers will get excited about the implementing the latest trends, developers will want to tinker with newfangled tech, and product managers will want integration up the wazoo. When the main rule of brainstorming is that there are no bad ideas, keeping these meetings productive becomes a challenge.
Trendy != Innovative
It might seem innovative to hop on the latest bandwagon — flat design, skeuomorphism, skeuominimalism, meteor.js, space.js, doge.js. Teams love to jump on trendy bandwagons because they're fun. Everyone talks about these trends so it feels like you're part of the community when trying these things out. The reality is that trends are a distraction. When the team is more excited about trying out new technologies than solving customer problems, you have an apathy problem.
Find Your Zag by Building Less
In Marty Neumeier's book, Zag, he talks about finding your Zag while others Zig in a cluttered market. The productivity app market is one of the most cluttered right now. There's a slew of to-do and project management apps pretty much all offering the same thing, albeit with different UI designs and interactions. While a lot of the apps are inundated with features, most of those features are no more beneficial than what you can get from a pencil and paper.
Contrast this with bookmarking service Pinboard. Pinboard was launched when Delicious was sold to Yahoo! and was quick to provide a service that customers needed the most — a way to transfer bookmarks over from Delicious to Pinboard. There isn't much else to Pinboard other than the essential features, and one killer selling point — Maciej Ceglowski, the app's creator, lists his response to support request as a primary advantage of using the app.
I wrote Pinboard in the spring of 2009 as a personal project, partly out of frustration with a redesign of Delicious that I felt removed a lot of utility from the site, and partly because I had long wanted to have a bookmarking site that would archive my bookmarks.
— Maciej Ceglowski, Pinboard Founder
It also doesn't hurt that the app's Twitter account is often hilarious, giving customers even more of a reason to stick around.
Pinboard has 12 essential minerals that make bookmarks strong— Pinboard (@Pinboard) August 8, 2014
There Be Creeps Here!
No fair, you say, this dude is running the app all by himself. There isn't an entire team of people each trying to do different things. Sure, Feature Creep is more likely to appear when everyone wants to jump on their bandwagon of choice, and everyone else is too afraid/doesn't care enough to just say No. The Feature Creep is a strange creature. It appears friendly at first — in fact, it'll fool you into believing it has the answers to all your problems! It'll start off slow, convincing you that if your product isn't running on backbonejsonrails8 it will fail miserably, and ending with a giant monstrosity that communicates a faint hint of the problem-solving product it might have been.
Break out the sticky notes!
We often hear that there are no bad ideas in brainstorming. This helps people come up with ideas without fear of judgement. Problems happen when that same mentality is maintained further along in the product's life. Giving critical feedback is hard, and that's why it's important to make sure people are receptive to feedback.
Feedback will allow you and your team to properly collect and filter ideas. One of the ways we do this at ZURB is we collect the feedback in little quips on sticky notes. We then organize those notes on a whiteboard to create a funnel of ideas. You do need to get a large volume of ideas to start with, so don't start naysaying too early!
Make Your Meetings Less Yawn-worthy and More Productive
Naysayers can help drive productive meetings past that initial 'anything goes' stage. However it's also important that people aren't just looking to contradict each other. People need to do their homework upfront, and everyone should be open to critical feedback. One way to do this is to assign roles in the meeting. Before you start your meeting decide who will be the bad cop — that's the person who will always try to contradict the presented ideas, regardless of whether or not they like it.
For example, the designer on your team wants to change the entire UI design to be flat. While other people on the team agree or disagree, the bad cop asks why — and demands data to support this decision. Was a simple prototype of the flat design tested with existing customers? What's the competition doing? How does this redesign fit into the overall brand. Because it's the bad cop's job to question everything, it forces the team to justify their design and development decisions with data rather than whims.
ZURB's Amazing Feature Creep Repellent
We talked a lot about our approach to product design, including prototyping, brainstorming, and customer development. Tackling Feature Creep is hard work, so we've put together this handy guide to warding off its attacks:
- Assign roles in your meetings: The bad cop is an obvious first choice, and you can get more creative with roles.
- Do your homework: You and your team should be aware of the purpose of the meeting ahead of time so that people can do their homework and arrive at the meeting informed.
- Start prototyping: Encourage your team to prototype their ideas before meetings to more effectively communicate the benefits of their work.
- Test your prototypes: Prototypes are useless if not tested, so make sure your team runs prototypes by customers first. That way they'll be able to support their theories with real data!
Make Friends to Thwart Feature Creep
Don't tackle the Feature Creep on your own. Heroes know they need friends to overcome challenges, and product design is only slightly less harrowing of a feat than slaying dragons. Reach out to customers constantly and consistently.
If you're working on a new product, then finding potential customers will be more challenging. In this case, you'll want to tap into any existing relationships with people that match your target audience — these people can be co-workers, friends, family, anyone that you already have contact with that would be willing to test out a prototype and give feedback. This is where establishing relationships can be immensely helpful in the future. The next time you're at a conference or meetup, put your networking hat on and turn on that product designer charm!
If you're working on an existing product with customers, then you're already ahead of the game! Your customers will give you amazing insights into your product.
We're in the middle of an amazing customer development exercise with Notable right now. It's been around for four years, and we've built a sizable customer base during that time. Throughout our design process for the upcoming release, we've been getting feedback on everything from features to marketing material. We found this so helpful that we even included a feature in the new Notable that will allow you to store lists of your customers and assign them to projects. That way customers will be kept top-of-mind for designers, and they'll be encouraged to directly reach out for feedback during their design process.
Notable, our product design platform, is now in private release! Get access today!Get Early Access to Notable
- Page 1 of 3
- Older Posts »