Arguably the most difficult skill you’ll learn in your design career is how to communicate that you did what you set out to do in a way that gets people to support and continue the work you did.

Presenting design successfully is about knowing what you want out of the meeting and structuring it to meet those needs. There’s a cliche of design reviews as interpersonally fraught spaces where stakeholders alternate between going on tangents and ripping your work apart. It doesn’t have to be that way.

One of the most interesting distinctions we make in design is between service design and engagement design. Service design is oriented around helping someone achieve a task. The interface that asks for information and prints your boarding pass is service design – it’s successful if you get through it without mistakes as quickly as possible. On the other hand, Engagement design is oriented around keeping people’s attention. If you’re binging a TV show, scrolling down a news feed, or liking your friend’s posts, you’re in an environment designed for engagement.

Designing for engagement means offering up lots and lots of content to keep people interested. A key performance metric for engagement design may be how many posts a user reads, or how many videos they go through without returning to the homepage or search. The end goal of both business and user is a steady flow of content that keeps a user’s attention. Continue reading …

Design has made leaps and bounds to accommodate for all types of visual, auditory, and physical limitations. However, there are some boundaries to what it can accomplish. One example of this boundary where design has not been able to bridge the gap is Dyslexia.

I was diagnosed with Dyslexia and Dysgraphia at the age of eight after three years of struggling through public school curriculum and having teachers say, “You should probably be held back.” It’s an issue that has shaped much of my opinion on design.

Every few months, an article appears in the news about a font that will help people with dyslexia read and “relieve” them of their symptoms; it is frustrating to say the least. What these articles fail to understand is the difference between legibility and accessibility. Let me explain why. Continue reading …

Product Managers are awesome! They keep goals in mind and priorities at the forefront –
and when designers get to work with them, it’s a real treat. Clearly, there is a lot of overlap in skill sets, but sometimes you’ll find yourself on a team without a dedicated PM. So if you’re a designer in a position where you need to do a little PM’ing – you’ll want to have these skills.

For a primer on what a Product Manager is and does on an Agile team, check out this great resource. The role is a bit tricky – and as a designer, the work can feel uncomfortable at first because PM deliverables can seem much less concrete than design’s. But, if you can master the secret art of Product Management, you will be a much better designer for it. Continue reading …

Design is an important part of the development process and we don’t want you to take it away without considering the risks.

Carbon Five has been practicing design for 10 years and in that time we have had the privilege of working with many design-driven companies. However, even the most design-focused companies get cold feet. Here are some things we have learned over the years on the (thankfully rare) occasion the value of design is called into question. Continue reading …

An experience map is a structured customer journey map that we use at Carbon Five to help identify challenges and opportunities within an existing (or imagined) experience. Since we use it so often – both when scoping projects and when kicking off major phases of work – we’d love to share a bit about what makes a great experience map. And because we create them collaboratively with stakeholders, we’ll share our facilitator tips for running an enjoyable experience mapping workshop.

Continue reading …

Carbon Five was recently brought in to build a new product with a planned budget of 6 months. As the first step, we conducted a few rounds of customer development to try and validate the concept. After a month of experiments by a product manager and designer, we ultimately recommended that the company not pursue the idea. Our client spent a few weeks of consulting fees but saved more than 90% of their budget by not building anything.

The client for this project provides software to a niche set of businesses. As more and more competition started popping up, they believed they saw an opportunity to create a digital marketplace in their niche. Before Carbon Five started building software, the client wanted us to confirm demand for the marketplace.

Continue reading …

Here at Carbon Five, we’re pretty fascinated by bots and conversational UI. Recently, we worked with Cooper to test and launch a new Alexa skill, a meeting manager to help teams run daily standups. We’ve already written a fair bit about our collaboration process in general, and in the following post I’m going to get into the nuts and bolts of how we design, plan, and document a user’s conversation with a bot.

Between our work on hands-free applications, our project with Cooper, a handful of Slack bots we’ve built during hackathons, and a Facebook Messenger bot we built to celebrate May the 4th, we’ve had a few chances to experiment with ways to create a conversational UI script.

Continue reading …

If you’ve been following along with the Carbon Five Guide to User Research, we’ve worked on developing and confirming a business hypothesis by talking to users and synthesizing the results, then generating a feature set and prototypes, higher resolution design, development, and usability testing. Hopefully you’ve already run a user test and learned something valuable in the process. (If you haven’t, get thee to a User Research Sprint!)

If you have completed your first round of user interviews, good news: you’ve already done the hardest part of setting up an infrastructure that lets you continue learning from your users. Here’s how to keep the insights coming as your product matures.

Continue reading …

If you’ve been following along with our guide to user research, great! By now you’ve defined your feature set and are ready to try out your ideas. You know your product will be validated by user research and match user needs. You know that you need a version of the product to test your solutions and before writing any production code.

Now, we are going to walk through some of the best ways to get the feature set you have in mind into a useful prototype. Some rules of the road to follow before you begin creating prototypes:

• The more the merrier: Come up with as many ideas to prototype as you can; this will help you evaluate your product with both your team and with your users.
• Iterate, iterate, iterate: Once you have the ideas make sure you evolve them through multiple rounds before you throw them out. This is your time to try stuff out and have fun. If you don’t explore broadly at this stage, when will you?
• Use these prototypes to learn: Prototyping is most powerful when it is used to test a hypothesis and to learn about your users and what they want. Don’t think of the prototypes as a final design but as a way of learning what your final design might be.

Without further ado, here are our six favorite prototyping techniques.

Continue reading …