At Carbon Five it’s pretty common to do our editing in vim embedded in a tmux session. Tmux, if you haven’t used it, is a “terminal multiplexer” that lets you create multiple tabs and panes in a terminal, persist terminal sessions, and (with plugins) send commands from vim to another pane. It’s also great for remote pair programming, since you can share a session over the internet.

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 …

Raphael Koh

In our last Domain-Driven Design discussion, we learned how to group similar business components into application Bounded Contexts, which were separated folders in our Rails apps. This segregated cohesive groups of application code into separate folder structures (bounded contexts), and gave us a jumping-off point to drawing more explicit boundaries between domains in our monolith. Now it’s time for us to re-think how to communicate from one context to another. Here’s how:

Continue reading …

As the popularity of Elixir and Phoenix continues to grow, we find ourselves spinning up more and more Phoenix apps for our clients and side projects. At Carbon Five, we have a pretty good consensus on our favorite practices and tools. With each new app, we find ourselves repeating the same steps to bring in many of the same resources and processes.

We created Razor, an opinionated app generator, to save ourselves this time and trouble. Razor isn’t the only one out there, but it captures our common needs and preferences at Carbon Five pretty comprehensively. It also provides a great platform for discussion; we hope to watch Razor evolve as the Elixir ecosystem grows and we continue to learn.

Continue reading …

As a digital product development consultancy that delivers more than 30 projects a year, we get to work with a lot of founders: technical and non-technical alike. Over the last 17 some-odd years, there are a few traits we see time and again in successful non-technical founders. And really, these six traits benefit anyone trying to create a successful new product.

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 …

Welcome to the 4th of our User Research series where we share our insights into how to generate a list of features. In the coming paragraphs we’ll talk about how User Research can help with stakeholder management, generating a feature list, and prioritizing a feature list. This post focuses on feature definition, and making what we’ve heard actionable (and testable!). Our next and final post will cover a handful of methods to prototype the features we generate here.

In our last post, we worked on synthesis and analysis of user interviews. After a number of interviews, we refined our proto-personas and identified common experiences.

(You haven’t done synthesis before? No worries! We run User Research Sprints that help with this process.)

Continue reading …