Then I joined a real team.

Suddenly, I was introduced to this thing called Kanban – and I realized I’d been treating software like a solo art project, not a process.

If that sounds familiar, you’re in the right place.

This guide will walk you through how Kanban actually works, how developers use it to track and prioritize work, and how it can help you stay sane when juggling bugs, features, and real-world deadlines.

Without further delay, lets get into it.

Here’s what we’ll cover:

• So… What Is Kanban?

• The Classic Kanban Board: Three Simple Columns

• How Developers Use Kanban in Real Life

• Kanban vs Scrum: What’s the Difference?

• So which one should you use Scrum or Kanban?

• What Tools Do Teams Use for Kanban?

• How to Use Kanban to Manage Your Own Coding Projects

• Final Thoughts: Why Kanban Isn’t Just a Board

So… What Is Kanban?

At its core, Kanban is a visual way to manage work. It helps teams (or team members) see:

• What needs to get done

• What’s in progress

• What’s finished

• Where things are getting stuck

The concept comes from lean manufacturing, but in tech, it’s often used in Agile teams that need flexibility without the structure of Scrum sprints.

Think of Kanban like a whiteboard that tells a story. Not just what’s done, but how work flows.

The Classic Kanban Board: Three Simple Columns

So what exactly is a Kanban board? At its core, it’s a visual representation of your workflow – a board that shows all the work your team (or you, solo warrior) are juggling, and where each task stands.

It can be physical, like an actual whiteboard with sticky notes that move from one column to the next. Or digital, using tools like Trello, Jira, GitHub Projects, or Notion. The key is that it’s visual and up-to-date. You can walk into a room or open a tab and instantly understand: What’s being worked on? What’s ready to go? Where are things stuck?

It’s like having your brain on a wall, but organized. And slightly less chaotic.

The beauty of Kanban is how dead simple it is to get started. At minimum, your board has three columns:

Each task – or card – moves from left to right as it gets worked on.

Let’s say your team is building a blog platform. Your Kanban board might have cards like:

• “Create signup form”

• “Fix image upload bug”

• “Deploy staging build”

Now, while Kanban is flexible, it can absolutely be taken too far.

I’ve seen boards with more columns than a Greek temple: “Needs Review,” “Pending Client Feedback,” “QA Rework Round 2,” “Blocked but Still Hopeful,” “In Existential Limbo,” and so on. Every card had six tags, three owners, two checklists, and one migraine.

The lesson? Don’t turn your board into a bureaucratic jungle.

You don’t need to account for every edge case. Start simple: “To Do,” “In Progress,” “Review,” “Done.” These basic stages cover most workflows. If you discover a real need for something more – like a dedicated “QA” column or “Blocked” column – add it intentionally, not because you feel like your board needs to look fancy.

Remember: A Kanban board should be helpful, not overwhelming. If you spend more time managing the board than doing the work on it… it’s doing the opposite of what it’s meant to do.

How Developers Use Kanban in Real Life

Here’s how you might interact with a Kanban board on a dev team:

1. You pick up a card from “To Do” – let’s say, “Add dark mode toggle.”

2. You move it to “In Progress.”

3. When it’s ready for review, you might move it to a temporary “Review” or “Testing” column.

4. Once it’s merged, tested, and deployed, you move it to “Done.”

5. You smile, drink some coffee, and grab the next card.

That’s it. But over time, this process helps the whole team:

• Spot bottlenecks

• Prevent duplicate work

• Reduce context switching

• Keep everyone aligned

What’s a WIP Limit — And Why Should You Care?

WIP = Work In Progress. This is the most important concept to keep us in check.

One of Kanban’s key principles is limiting how many things you’re working on at once. Because guess what? Multitasking kills momentum.

A typical WIP limit might look like:

• No more than 2–3 cards per person in “In Progress” Again this is best practice, but folks do pick up a lot and then they end up being the bottleneck.

• No more than 5 tasks waiting on QA.

Why? Because when everything’s urgent, nothing gets done. WIP limits force you to finish one thing before you start more – and that’s how real velocity happens.

If there are more than 5 tasks in the “To Do” column, the team doesn’t take up new ones. Instead, everyone chips in to see how they can help unclog the bottleneck. A bottleneck is your worst enemy in Kanban, and you want to resolve it so items move smoothly on time and on target.

Here’s a video recapping key concepts.

Kanban vs Scrum: What’s the Difference?

You’ve probably heard Scrum and Kanban mentioned in the same breath – and both are popular Agile frameworks. But they’re not interchangeable.

Scrum is structured, with roles like Product Owner and Scrum Master, and work gets organized into time-boxed sprints. It’s perfect for teams that benefit from rhythm and rituals – like sprint planning, daily standups, and retrospectives.

Kanban, on the other hand, is a little looser. No official roles, no set sprint timelines. Work flows continuously, and change can happen anytime. It’s perfect for teams who need more flexibility and fewer ceremonies.

So how do they compare in practice? Let’s break it down:

Bottom line:

• Scrum is a scheduled loop. Kanban is a living flow.

• One’s a playbook. The other’s a status window.

Here’s a video on the main differences between Scrum and Kanban you can watch if you want more detail.

So which one should you use Scrum or Kanban?

So… which one should you use?

It really depends on your team, your product, and your pain points.

✔️ If you’re working on a brand-new product where requirements shift a lot, and your team thrives with structure and routines – Scrum is likely the better fit. Sprints give you a sense of pacing, and ceremonies help ensure alignment.

✔️ If you’re managing ongoing work like bug triage, tech debt, infrastructure tasks, or anything that’s more “whenever it comes in” than “we need to ship this in two weeks” – Kanban gives you flexibility and visibility without the overhead.

And yes, there’s such a thing as Scrumban – a hybrid approach where teams use visual boards and WIP limits from Kanban, but keep some of Scrum’s structure like standups and retros. It’s like Agile tapas: you get the flavors that work best for your appetite.

Here is a detailed video that’'ll teach you more about how Scrumban works in practice.

Watch the Scrumban video only when you are familiar and comfortable with both Scrum and Kanban – otherwise, you might get confused from the cross-pollination of ideas and frameworks.

I personally have never seen a Scrumban implementation thats scaled well – too many folks trying too many things and none of them work. But thats just based on my experience – it may work for you and your team. I’ll let you be the judge.

What Tools Do Teams Use for Kanban?

You’ve probably seen (or used) one already:

• Trello – Simple and great for solo or small teams

• Jira – Enterprise-level, customizable workflows

• GitHub Projects – Lightweight but powerful for devs

• ClickUp / Asana / Notion – Integrated with docs/tasks

Kanban isn’t tied to any one tool – you can use an app, a browser tab, or a whiteboard and a pack of sticky notes from the office supply closet. What matters is how you use it. But let’s walk through some of the most common tools and what they offer in a Kanban context:

🟩 Trello

Trello is probably the easiest way to start with Kanban. It gives you a simple digital board with columns and cards you can drag and drop. It’s great for devs or small teams who don’t need tons of automation – just a clean place to track work visually.

🟨 Jira

Jira is a heavyweight – and while it’s built for Scrum, it also supports robust Kanban boards. You can define custom workflows, use built-in reports like cumulative flow diagrams, enforce WIP limits, and manage team velocity. Ideal for large teams that need traceability, integrations, and permissions.

🟦 GitHub Projects

If your code lives in GitHub, GitHub Projects is a clean way to stay close to your codebase. It lets you create Kanban-style boards with issues and pull requests as cards, so you’re never toggling between tools just to track what’s in progress.

🟧 ClickUp / Asana / Notion

These are all-in-one productivity platforms. They combine Kanban boards with documentation, team chat, calendars, and reporting. If your team needs more than just “move card left to right,” these tools let you manage projects, meetings, notes, and workflows in one place.

🟪 Whiteboard + Sticky Notes

Don’t underestimate the analog approach. It’s fast. It’s visible. It’s tactile. Physically moving a task from “Doing” to “Done” gives you a sense of progress no digital tool can match. And when something’s blocked? Slap a red sticky on it and call it a day.

Bottom line: The best tool is the one your team will actually use. Fancy doesn’t beat consistent. And the actual tool doesn’t matter as much as the discipline your team has to actually use it.

How to Use Kanban to Manage Your Own Coding Projects

Even if you're not on a team yet, Kanban is great for your own workflow. Here’s how you can use it to help yourself out:

1. Create a basic 3-column board (To Do, In Progress, Done)

2. Write out every task, big or small

3. Set a WIP limit (for example, no more than 2 tasks at once)

4. Update it daily. Make it a ritual.

5. Review your flow weekly – What got stuck? What moved fast?

Example:

You’ll be shocked how much clearer your thinking gets when you can see your work. It’s simple but super powerful to visualize your work it in this way.

Final Thoughts: Why Kanban Isn’t Just a Board

Kanban isn’t just a tool – it’s a mindset.

It helps you focus. It helps your team collaborate. And it gives everyone – even non-technical folks – visibility into what’s going on.

If you’re learning to code and want to feel more confident working with others, learning Kanban is low-effort, high-impact.

So don’t wait until your first job. Start using it now – and show up to that standup with confidence.

I hope this small 101 Guide to Kanban was helpful to you all. My sole purpose to write this was to help beginner developers understand Kanban as a practical workflow system – especially for those transitioning from solo coding to collaborative, real-world development environments. It aims to demystify the methodology in a casual, beginner-friendly tone while still offering actionable guidance.

I hope you enjoyed my beginners guide to Kanban.

Until next time, keep Learning, Unlearning and Relearning, folks….

The Design industry is rapidly evolving, and there are many career choices in the space. You've got UI/UX Design, Product Design, Interaction Design, Motion Design, and more.

In this article, I will discuss a roadmap that will show you how to become a self-taught Digital Product Designer without a college degree. It will also help you prepare to land an entry-level role in Product Design.

This post was greatly inspired by the AJ&Smart. 👋

What is Product Design?

According to the Interaction Design Foundation,

"Product Design is the process designers use to blend user needs with business goals to help brands make consistently successful products.

Product designers work to optimize the user experience in the solutions they make for their users—and help their brands by making products sustainable for longer-term business needs."

What is the Difference between UX Design and Product Design?

This is a tricky question because these two roles are often talked about interchangeably. Some companies even combine the job descriptions of these two roles into one because of their significant similarities.

Let’s look at the definition of User Experience (UX) Design.

Interaction Design Foundation defines User experience (UX) design as

"The process design teams use to create products that provide meaningful and relevant experiences to users.

This involves the design of the entire process of acquiring and integrating the product, including aspects of branding, design, usability, and function."

I will be using the terms Product Design and UX Design interchangeably in this post.

How to Get Started with Product Design

Let's go through the steps to get you started.

Figure Out your "Why"

Whether you are switching careers or are getting started in your career, figuring out your "Why" is a crucial step.

A popular misconception about design is that designers are born not made – but this is not the case. Design is a skill that you can learn, but you have to do the proper research to know if it's something you really want to do.

A great way to find out if UX Design is something you would love to do is by taking a 6-day free UX Design from Career Foundary. This is an email-based course, and you will receive course content daily for six days.

From it, you will learn what you will be doing as a Product Designer, what job opportunities are out there, and salary expectations in the field. And if you have further questions, you can email them directly.

If your answer is yes, let’s move to the next step.

Take a Course

I recommend enrolling in a structured course to learn the principles, theory, and fundamentals of design. I will link to some great free courses below.

1. Introduction to User Experience Design: This is a 4 week beginner-friendly course by Coursera. The syllabus includes an overview of UX Design, requirement gathering, designing alternatives, and prototyping. It’s totally free (except if you want to get a certificate after completing the course).

2. Digital Skills: User Experience: This is a 3 week introductory course by Accenture. They take you through the foundations of UX Design, UX basics such as visual design and interactive prototyping, tools, and testing.

3. UI Design with Figma: This is a self-paced 10-hour Figma course that will teach you how to use the tool for UI design. You'll learn everything from creating shapes to using drawing tools, creating websites, and more.

You don't have to take to take all three courses – one is okay.

Paid Courses

• Coursera – Google UX Design Professional Certificate

• Udemy – Master Digital Product Design: UX Research & UI Design

Learn the Major Design Tools

The next phase is to learn some industry-standard design tools. Two of the most popular and cross-platform tools are Figma and Adobe XD.

• Figma: This is a web-based tool that is free for individuals. It also has a desktop version you can download on your machine.

• Adobe XD: This is a paid tool, I believe, but you have a free trial period of 7 days.

Some resources on tools:

• Learn how to use Figma to design websites

• UX/UI Design tutorial in Figma

• The Figma 2021 Crash Course by Example

• Learn Adobe XD in 2021 by Example (Crash Course)

Read Books about Design

Reading books about design is a great way to gain more insight into design principles, design patterns, design guides, and generally in-depth knowledge of the psychology of design.

Here is a list of recommended design books:

• The Design of Everyday Things ~ Don Norman

• Don’t Make Me Think ~ Steve Krug

• Refactoring UI ~ Adam Wathan & Steve Schoger

• Sprint ~ Jaka Knapp

Build a Solid Portfolio

An impressive portfolio is an excellent way to document your work and show your competence in the design industry.

Your portfolio should be well organized and should feature your best work. Your work should show your design process and problem-solving skills.

Here is a guide on how to create a product design portfolio in 8 steps to get you started.

And here are some tips about how to create portfolio-worthy work so you can showcase your best stuff.

Note: It's best not to include course projects in your portfolio.

Another good project idea to add to your portfolio is to take an existing poorly designed product and do your research to discover the users’ pain points. Then rebuild the product and write about your entire design process.

Check out this tweet for ideas on how to build your own portfolio.

Write Articles

Writing an article about your work and how you were able to solve a particular problem is an excellent way of showing your skills, documenting your journey, explaining your struggles, and helping others learn in the process.

And you don’t even need to build a blog from scratch – you can leverage platforms like Hashnode, Medium, and Dev.to to publish your articles.

Practice Practice Practice!

This is the only to get better and get ahead in your career, regardless of your field. Be creative with the knowledge you’ve gained and build solutions. We get better by doing – remember, practice makes better, not perfect. Strive to be better.

A good way to practice is to redo existing products that you think are poorly designed and make them better.

Join Design Communities

A design community is where you get to connect with people who share your interests. A design community is there to provide support at every stage of your career.

Some of the perks of joining a design community include:

• You get to attend meetups and conferences

• You get access to resources and job opportunities

• You get to share your work and receive valuable feedback from senior designers

• You can get recommendations from community members

Design communities are not all perfect, so you should be mindful of the communities you join. Here are some great design communities you can join.

• Friends of Figma

• Adobe Creative Career Discord

• Designer Hangout

• And other local design communities that are close to you.

Start Applying for Jobs

At this stage, you are ready to start applying for entry-level roles or internships. This is not to say that you must follow the aforementioned step chronologically before you start applying for entry-level jobs. I mean you can start applying for roles when you have a couple of impressive projects in your portfolio and are confident in your skills.

Here are some UX Design jobs on Glassdoor.

Resources

The following are some of the best YouTube channels that focus on everything design.

• The Futur

• AJ&Smart

• Awwwards

• Design Course

• Curated list of awesome product design resources.

Conclusion

And that's a wrap! In this post, we covered the steps to get you started in your Product Design journey.

If you found this post valuable give it a share. And if you have any questions or suggestions please feel free to shoot me a DM on Twitter or LinkedIn.

See you in the next one.

Happy Designing!

In my time building and devising products – apps, websites, and graphics makers – I have come across two types of people in general: those that prefer qualitative narratives and those that prefer data and analytics.

The first group is comfortable framing product development in the context of more subjective user feedback and perspectives. The second group, wary of this approach, wants to apply “excel models” to work backwards from numbers.

For ease of categorization, let’s call the first group “storytellers” and the second group “quants”.

Both groups want to construct meaningful product visions, understand users, and build tools at scale. Both groups are well intended but have a different approach to leveraging insights to make decisions.

Yet the way they go about collecting, analyzing, and deploying these insights varies.

It is likely useful to pause for a moment and ask yourself which camp do you more readily side with? Are you more of a storyteller or a quant?

Regardless of the answer, there is a unifying approach that I believe can bring these two personas together and help them find common ground in the pursuit of building better, more well thought out products.

And that approach is through writing.

Why writing is critical to product design

Writing is defined as the activity or skill of marking coherent words on paper and composing text. Learning to write starts with foundational principles: you must learn an alphabet and how to organize letters to make words.

These words, in turn, are then placed together to make sentences.

Sentences, when taken together, can start to convey deeper meaning.

Writing is a forcing mechanism. It makes us think deeply about what we want to communicate and why.

Writing helps us focus on what is most important.

And writing – when done well – mitigates obfuscation.

How many times have you seen a product presentation and been convinced about its merits due to the quality (both good or bad) of the presenter? A charismatic argument, for example, can mask what really matters to users and sway judgements.

Amazon founder Jeff Bezos once wrote:

“Powerpoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.”

Writing forces us to see what really matters: the strength and coherence of an argument and how that argument is supported or substantiated by evidence.

Product development is inherently messy because oftentimes products, even if they appear simple, are inherently complex.

This is true for both hardware and software. Massive complexity exists in common items we take for granted.

Lufthansa claimed that it took 6 million parts for Boeing to build the 747-8.

A simple drive-off-the-lot car might have 30,000 parts.

By some estimates the Android operating system runs on 12-15 million lines of code.

The Large Hadron Collider uses 50 million lines.

Not including backend code, Facebook (the front end and various landing pages) runs on 70 million lines of code.

Well-structured narrative text (as opposed to bullet points or plain text) can help the writer or product designer explain the “why” behind an argument.

Strong and active writing forces more reflective thought and a better understanding of what’s most important and how things – parts, people, plans, budgets, product – are related.

Lastly, writing helps create an even playing field.

All too often ideas (and how or who explains them) can lead to bias. Imagine being given a memo advocating for a product feature or Go To Market plan and you knew nothing of the author, including their background, role, or team.

And all you were allowed to do was evaluate the quality, durability, and clarity of the author’s words. This might lead to better business outcomes and product design decisions.

How to get better at writing

Writing is a skill that can be improved through practice. I remember in 5th grade my mother sitting down with me and using a red ink pen to edit and correct an essay I had written for homework.

Editing words is not easy. It wasn’t fun then and more than two decades later it's still not always fun. But by chipping away at it, we can embrace writing and get better at it.

The old expression “practice makes perfect” certainly didn’t apply in my case. Nevertheless, by forcing myself to write frequently, I was able to improve.

If you are building products and want to use written words to share your vision, win over internal stakeholders, and help communicate more effectively, there are a few things that you can start doing today.

Create an outline

Firstly, you can take out a piece of paper or open an online document, and start building an outline of what you want to communicate. Lead with they why.

You can use an outline to sharpen your thoughts and sketch out your product vision.

Try different types of writing

Secondly, you can play around with fun and different ways of writing to communicate about your product.

For example, you can write a press release. What would the New York Times say about your product if you were a journalist writing for the technology section?

Writing a futuristic press clipping is fun, gets the creative juices flowing, and is an enjoyable way to think through how others might see what you are building.

Jot down some FAQ

Thirdly, you can improve your product writing skills by drafting and completing Frequently Asked Questions (FAQs). What do people not understand about your product and why? Try to think through the questions users have and answer these questions.

The benefits of writing out FAQs are two-fold: you can improve your writing while also more deeply understanding those aspects of your product that users might struggle with. And as a result of this insight you can preemptively solve these problems.

Bringing It All Together: Writing and Product Design

At the beginning of this article I described “storytellers” and “quants”. These two groups represent different approaches to using inputs (data, numbers, feedback, credentials, and so on) to draw conclusions and make inferences.

Writing can bring “storytellers” and “quants” together and provides a level playing field for the expression of ideas.

Writing helps us avoid premature optimization.

While writing might be a challenge for you today, it is worth practicing. If you need prompts to get started try outlining the future of the gig economy or futuristic trends in mobile apps.

If you don’t write about the future state of your products, you should start. It will help sharpen your thinking and enable you to build for better outcomes.

In the end of the day that should be the North Star for all builders.

When you're building a product, there are different frameworks you can deploy to think critically about what to build and why. These frameworks apply to business as well.

When designing a product – or launching a startup – you should answer a few fundamental questions:

1. Should I enter the market or not?
2. Who else exists in this market and what are these firms doing or building?
3. What are the costs of entering this market? Are these costs fixed or variable in nature?
4. If I decide to exit the market – or stop building or maintaining my services or software – what are the costs?
5. Who will use my product or services and what do they value or need?
6. Am I uniquely equipped to help these people or constituents?

This article provides an overview of four interesting, dynamic, and different approaches to probe your assumptions and answer these questions. Ultimately this article is about strategy.

Strategic thinking is about the art of outdoing an adversary knowing that they are trying to do the same to you.

Albert Einstein once asked, “If a cluttered desk is a sign of a cluttered mind, of what, then, is an empty desk a sign?” Just because a desk is empty does not mean it’s not contributing utility. For strategies to be effective they too need to be useful, applicable, and relevant.

Oftentimes building a company – or creating a piece of software – is about the application of strategy.

At a more granular level, this article attempts to help you think about the above questions by leveraging mechanisms for transforming inputs – like data, beliefs, and research – into a desired set of outputs that are easy to deploy in your everyday life and useful.

I have learned about these frameworks through a mixture of reading product launch templates, building products with my own hands, and studying how other product and business stakeholders optimize their work to drive the outcomes they desire.

I want to explain each framework and pass on the most salient takeaways from each so that you can rapidly apply these frameworks and build more effectively.

Framework #1: The Airplane Crash Test

Reginald H. Jones, the Chief Executive Officer of General Electric from 1972 to 1981, was in search of a successor upon retirement. He asked each of his executive subordinates a question:

“A plane crashes and you are on the plane. You don’t survive. Who should take over running the company or building the most important products, and why?”

This is an interesting question to ask yourself, and is especially salient as you build and scale products. Who do you know that is best suited to be the leader in an environment filled with ambiguity?

In your mind, is it you? Is it a peer? What does this person do so well that inspired you to think of them? Try to replicate their behavior and knowledge base to better equip yourself as a builder and product developer.

If you did select yourself, think about why. What skills do you have (technical, business, political, and so on) that can help you drive an organization or product forward? How will you teach those skills to others?

By thinking through the airplane crash test you can reflect holistically on what you do well, why those skills matter, and areas for improvement. You can also gain a deeper sense of appreciation for the skills that others in your life – or on your team – may have.

Framework #2: The Airport Test

This framework is very different from the airplane test. In this thought experiment, ask yourself the following: if I were to be stuck at an airport for many hours with someone, what kind of person would I want that person to be? And secondly, if others reflect on the types of people they would want to spend time with, am I one such individual?

Google famously applied an “airport test” to help conceptualize the types of people it would want to hire. On one hand, the airport test lends itself to some admirable outcomes.

If you are stuck at an airport for many hours with someone, it makes sense that you would want to surround yourself with someone who is curious, insightful, and easy to communicate with. These are valuable skills to cultivate in life, and as a builder.

On the other hand, this test has limitations – and the biggest one is seemingly bias. Would you rather spend more or less time with someone who thought and acted like you?

If so, you might be overlooking great people to learn from and spend time with that differ from yourself.

When building products at scale, you will want to think about all potential users. Many users are different from you and come from different walks of life. Think holistically about these users and who they are – their wants, needs, and diverse backgrounds – so that your product or business can best meet their needs.

Think about the airport test as bi-directional. Try to be the type of builder, motivator, or creator that others want to spend time with. Look for others that meet that test for you, too.

Framework #3: The Working Backwards Framework

Working backwards is a framework practiced by many product builders because it helps set a North Star rooted in customer feedback.

At its core, Working Backwards is a belief system that states that you should speak with users and customers and listen to feedback about what to build and why. The product designer, after organizing this feedback, can start building tools and services that users care about and want.

By working backwards, a builder can save time and money.

Amazon Founder Jeff Bezos once noted that while he can’t predict the future he can’t imagine a future in which people want slower delivery or higher priced items.

By working backwards from the fundamental needs and goals of users he can build solutions, technology, and products that empower these people.

Many great products that you leverage in your daily life are predicated on designers looking at the needs of users and building based on those inputs.

In the case of image searching technology, coders literally saw that people had an end goal of using images to run searches. Working backwards from that destination enabled the creation of reverse image search technology.

When you are building, try to place yourself in the shoes of users and go speak with them. By building relationships and starting these conversations you can be guided by what your users actually care about.

Once you know what matters, you can obsess over the details that best help you help your users. That is what the Working Backwards method is all about.

Framework #4: Jobs To Be Done

A fourth and final framework for understanding how to build businesses and products is to think about why people are “hiring” your technology and what problem your technology solves.

The late Clayton Christensen of Harvard Business School famously argued that the “customer is the wrong unit of measurement”. Instead, Christensen noted, people use solutions for “jobs to be done,” or the pain points they face in their lives.

When you are building your next piece of software, or product, or business, ask yourself: why are people hiring me to do this job? If you believe that your customers are rational, evaluate their behavior.

If you think that your rational users are making irrational choices, take time to better understand how your tool is actually being used.

By framing your work in this light you can develop and hone in on a very important skill set for builders to cultivate, and that is empathy. If you can’t empathize with how your product is being used (and for what purpose) you won’t be able to empathize with your users.

Bringing It All Together: Frameworks for Development

I have outlined four different frameworks to help you think about your work, how you devise products, and ways to conceptualize the development of your software or products across users, time, space, and markets.

These frameworks are not mine but represent interesting and influential nuggets that I have picked up watching others. These nuggets have influenced how I think about design, feedback, and content, and I hope they are useful for you too.

The application of these frameworks can help you build.

You can apply all, some, or none of the above. However, my hope is that by thinking about these questions and approaches you can dive deeper into solving real problems for real users and that you can better develop the skills, product design mindset, and empathy to align your products with the needs of your current or future users.

Would you use product X?

Do you like product X?

What do you enjoy most about the user experience?

These questions all elicit feedback. However, these questions are broad. If you want more specific feedback that you can transform into changes to your product, you will want to ask questions that elicit more details.

If this insight seems obvious, why do we - as builders, designers, and coders - all too often ask for product feedback that leaves us no better off than we were before asking?

I believe - and will provide examples to support in the article that follows - that by asking probing questions, we can collect actionable feedback that leads us to make worthwhile product improvements.

But only by asking the right questions, at the right time and in the right way, can this value be unlocked. If you need help learning to ask the right questions (and follow-up questions), this article is for you.

I have learned how to ask questions through a mixture of patience, practice, coaching, and building.

First, some relevant stories from my past missteps.

How my firsthand experiences building led me to ask different types of questions

When I started a FinTech company to help kids and parents learn about financial education at home, I asked parents if they thought financial education was important to the well being of their children.

What do you think these parents said? As a matter of fact, nearly 100% said that “yes” such education was important.

Guess how many of these parents went on to use the product I built? Only a fraction.

This short example illustrates the importance of asking the right questions. I asked the wrong one. Perhaps I should have asked the following:

• What tools do you use today to teach your children about financial education?
• Why do you value teaching your children about money?
• How are you planning to educate your children about money?

All three of these questions probe the same assumption as the first question: namely, that parents will want to teach their children about financial literacy.

But these questions are fundamentally better because they probe deeper and give the user room to explain their logic and rationale.

This qualitative feedback - where we can go deeper beyond assumptions and platitudes - is where insights exist to shape better product experiences. And that is a central goal for builders.

A second aim of builders is to not only build products that people use, but to build products that people find uniquely valuable.

When I was starting my career I had aspirations of being a Product Manager. A friend, who was a successful Senior Product Manager at Google, challenged me with a simple assignment: build a product that 10,000 people use.

I thought deeply about the challenge and looked into tools to help with student loans and Mapping APIs. Ultimately I decided that I would build a tool that helped solve various problems in my own life. I sat down and thought through these questions:

• What is a problem I currently have that technology can help address?
• Can I build a solution?
• Do I know how to build the technology?
• If I build a product, can others benefit from it too?

If you build it they may come...but you need to ask what your users want and need first.

I decided to build a Chrome extension that enabled users to quickly switch between tabs. After roughly 6 months on the Chrome store the free extension passed 10,000 active users.

I sat down with friends and started asking them how they used the tool and what they needed the tool to do to add more value in their lives.

I honed in by asking very specific questions:

• How many times do you use the tool (and I would cross reference this with internal data)?
• What does the tool not help you do that you need it to do?
• Can I join you at your workstation or desk and observe you using the tool?

These questions led to new insights.

Ultimately I decided that the improvements users wanted were beyond my technical capacity.

So I let the tool sustain itself without further coding improvements.

What did I learn from this experience?

Firstly, building is rewarding. Solving your own problems with small tools and hacks can be great fun and also educational.

Secondly, when you build something that has utility, and others start to use it, you have a unique opportunity to learn from users to make improvements.

These improvements, in turn, can yield even better product features, designs, and outcomes. These enhancements can better satisfy and align with the needs of your users.

Hence a small flywheel can be set in motion.

And lastly, it’s ok to build and push the limits without committing to further releases and development work. It’s ok to say “no” and allocate your time and technical resources elsewhere.

By asking the right questions you can unlock real value.

But this value does not need to be applied just to development cycles. It can also make you realize you are headed down a path you don’t want to be on.

And you can use insights from users - and gleaned from the questions that you ask - to make better informed decisions.

I had a product manager who once noted: “if the feedback is not a strong yes, then it's a no.” I think about this belief system a lot because I am always looking for perspectives that can help shape, inspire, and influence the products I design and build.

I would challenge that product manager - and you - to amend that quote: “If the feedback is not a strong yes, ask why not. If you can’t glean insights from users, then it’s a no.”

The art of intentional product feedback starts with you - the builder - and an open mind.

But tied closely to an open mindset is the ability to ask the right questions. It is healthy to say “in the spirit of open-mindedness, I’m striving to learn and I am learning by asking questions.”

There are many educational tools, online schools, engineering communities with online coding tests, and communities like freeCodeCamp to help you learn to engineer, design, wireframe, and deploy products.

But how many of these tools teach you how to ask questions, think critically about the replies, and then circle back with relevant follow up questions?

When building anything for others - a tool, a website, an app, or highly specialized software (like a QR Code Generator) - you need to know what people want, need, and most strongly value.

Only by asking questions can you learn these things. Only by asking questions can you produce a product that gets your users to a “strong yes.”

I have built and designed apps and websites, and helped scale products at companies small and large, from my own startups all the way up in size to Google.

I have learned about digital design best practices through a mix of trial and error, development cycles, successful launches, product failures, user feedback, and the inevitable iterations that have followed.

I want to pass along what I have learned.

My experiences can hopefully enable you to better understand how digital design works and the role of the designer in conceptualizing products.

Through these lessons you will be able to bring products to market in a more timely and efficient manner and better serve your users.

What is Digital Design and Why Does It Matter?

The formal definition of digital product design is an iterative design method employed with a formal approach to solve a practical problem. Sounds somewhat complicated, right?

It doesn’t need to be.

Using simpler language, a digital product designer discovers a current problem, proposes the best solution possible using a mix of technologies, and introduces it to a market.

Digital design is considered a subset of product design because digital design is all about the building of products - but via software.

The skills you are learning and developing on freeCodeCamp will help you think strategically and technologically about how to solve problems. This is closely tied to the practice of digital design.

In order to implement digital designs you will need to identify opportunities and know the desires of your consumers.

Digital Design and The Real World

Digital design focuses on users.

Customer obsession starts with the user and works backwards.

If you are new to digital design there are a few tactical steps you can take to learn what customers value and how you can leverage a mix of UI, UX, and design thinking to solve tangible problems.

What problem are you solving?

Firstly, work vigorously to earn and keep customer trust by understanding what your product and design are meant to solve. Answer the following questions: why does this product exist? How will it be used?

Digital design done well can have a profound impact on users.

Bringing together intuitive user experiences and simple user interfaces can help your customer best understand how your product works.

A friend of mine worked to help build the iPad reading experience. One story he shared with me is how digital designers made it effortless to “turn the pages” of digital books.

The action of swiping a page, much like moving paper in a real book, evidences how design, UX, and UI efforts can come together to create delightful user experiences.

The next time you swipe a page on your iPad, think about why the experience feels entirely natural and simple. Digital design, done well, is magical.

Innovate and simplify

Secondly, digital designers expect and require innovation and invention and always find ways to simplify. As with your focus on customers, you need to be externally aware, look for new ideas from everywhere, and cannot be limited by a “not invented here” mindset.

When designing websites, for example, it's important to do a few things really, really well. I learned this when building and optimizing my own websites.

I had a mentor who advised:

“Know what you do well, and how you can do it better. If you are designing your website, you know that time is valuable and every additional second your user’s stay on your page, the better. Strong design can shave excess latency from pages and increase the efficiency of the serving environment and that is something to strive for.”

Notice that this advice is specific (i.e. design for speed) yet also broad (improve your user’s experiences in the best way that you can).

When thinking about digital design, take time to deeply understand the levers you can pull and how those levers will yield better experiences and results for your users.

Experimentation is key

Thirdly, experiment.

Digital design, unlike the designing of physical items, can be improved rapidly through sprints and code deployments.

Software is adjustable.

By starting with your customers and working backwards, seeking to simplify, and constantly iterating, you can be insure that your design will eventually stick. If you haven’t reached that point, keep trying.

Here is a mental experiment I like to play with my friends.

Think about the last time you purchased an airline ticket online. How many steps did it take to navigate from the landing page to the confirmation of the payment page?

Why do you think airlines make users go through this check-out flow? How would you improve and simplify the process?

A great way to improve your digital design skills is to practice on another designer’s property. See if you can improve upon it.

Digital designers see being great at something as a starting point, not an endpoint. Through iteration and experimentation, a digital designer can take things that work well (or poorly) and improve upon them in novel and unexpected ways.

If you are new to the field of digital design, that should excite you.

Examples of Digital Design Done Well and How It Helps Users

I want to conclude with examples of digital design done well. I provide examples and images and explain why the digital design is intuitive, simple, and relevant.

If you want to develop your skills in this field, take time to not only think about how you would improve other’s sites but also learn from what leaders in the field do, and why.

Example #1

Elemental Labs provides an incredibly intuitive graphic to help users understand the difference between their product and a competitor’s product. Without reading anything else you intuitively understand that their product is marketed as cleaner, purer, and simpler.

The contrast between colors helps the eye visually understand the message and is an example of great digital design.

Also, notice how grams - a common unit of measurement - is replaced with milligrams. This makes the user feel like there is more sugar (29,000 mgs of sugar feels like a lot).

Example #2

Woven is a fun calendar app that makes group polling easy. I have used a variety of software tools to coordinate groups and it's always a bit messy.

Look how clean the infographic and call to action are. Without thinking deeply about the product you can clearly understand how the product works and why it will benefit you: simply pick a date, poll people, and see which date is best for the group.

I love products that combine compelling design, UX, UI, and are incredibly easy to navigate.

Example #3

For those that want an example from the world of digital and physical design, a particular favorite of mine is LFA Machines.

Their product set is complicated: they offer both semi automatic and fully automatic capsule filling machines. For many people, this technology is abstract as they have not seen machines like this in person.

So what does the site do? It offers a video that is automatically playing when you visit so you can see how the device works and what benefits it provides. This digital design brings together simplicity, clarity, and customer obsession all in one.

Example #4

Here is one final example.

If you want to start a podcast you might experiment with different digital podcast software. One that combines simplicity with easy usability and a terrific digital design standard is Buzz Sprout.

When a user visits their site for the first time the user is prompted with compelling and straightforward guidance, tutorials, and advice on how to create a podcast.

These radio buttons say it all: they make the selection process very user friendly and expedite the podcast creation process. In just a single button the design brings together strong design and product aesthetics and usability.

Product design is the process you go through when you conceptualize and build a product.

The path to building – hardware, software, or even simple prototypes – has different steps and approaches.

I have built products at Google and advised companies who are building products in the web development and mobile app space. Through my experiences as a builder I have made many mistakes. I have also gotten a few things right.

Learning how to design products is not only useful for builders. Learning to wear a “product design hat” can help aspiring product managers, engineers, sales professionals, and managers empathize with how a product is built and why.

Product design is focused on building products to help users make sense of a confusing, complex, and contradictory world.

Through a mix of product launches, mentorship, observation, and repeated experimentation, I have learned the fundamentals of product design. Hopefully you can avoid some of the pitfalls that I experienced.

I want to share eight practical steps with you in the hope that this framework enables you to build and design better products and more rapidly bring them to market.

Step 1: Define the vision of the product

At this earliest stage of design you should turn your computer off.

Put your pencil down. Think.

Ask yourself: “What is the purpose of this product?”

You should be able to loosely articulate what a product might be able to do, who will use it, and what problem the product solves.

Don’t drown in numbers or research. If you are intimately aware of the problem that the product will solve, great. If you are newer to the problem space, think about why the problem exists.

Define what a product will feel like, how users might interact with it, and why other products don’t adequately solve the problem you have identified today.

Step 2: Research the product space and market

In this second stage you should start to look at the market and define who is in it and why.

Answer the following: Who makes similar products, how are those products used and by whom, and what impact are these products having?

How were these existing products brought to market and distributed?

Thoughtful research starts with the end-users.

There are two types of products: those that are incremental improvements to existing products and entirely new inventions. Which one is yours?

Work backwards from customers. Although good product designers may pay attention to competitors, great researchers obsess over how people will use the product itself.

Step 3: Get Feedback and Generate More Ideas

Earn the future trust of users by practicing active listening.

Demonstrate strong judgement and good instinct by building a prototype and getting real feedback. When getting initial feedback, a strong product designer will never say “that’s not my job.”

Answer these questions: How does your product make a user’s life better? How will the product be built and in what timeframe? Who will buy the product?

Be externally aware.

Look for new ideas from everywhere. When getting feedback think about what the person is really saying. What are their words conveying? What do their actions (body language or tone of voice) imply? Most importantly, what are these prospective users not communicating?

Obtain and seek out diverse perspectives and work to accept or disconfirm feedback.

Use feedback to take curiosity – your own and that of users – and translate that into something that people can use.

Product design is about never being done.

Step 4: Ideate

During the ideation stage, insist on the highest standards.

Thinking big is a self-fulfilling prophecy. By looking around the corner, a product designer can think holistically about how a product will solve new or unforeseen problems.

A well designed product unlocks value for end-users. Don’t lose sight of this.

If a design decision is reversible and can be made quickly, show a bias towards action and ideate rapidly.

Embrace calculated risk taking.

Step 5: Build and Don’t Give Up

No task is beneath you in the building stage. Benchmark your progress against the best in your field.

As the Chief Product Officer of Pennybox, I spent two years steering the company through fundraising, development, and the product’s launch.

While I learned immensely from my experience at the helm of Pennybox, the period of time was not without its challenges — some of which, I recognize in hindsight, could have been avoided.

Pennybox, for example, let too much time elapse between product iterations. My experiences running the company have made me acutely aware that designing is hard.

If you are a builder, you can never fully insulate yourself from the inevitable setbacks that come with pushing technological boundaries or creating new products.

Building is hard. Keep bootstrapping. Keep building.

Don’t give up.

Step 6: Earn validation and examine results

Designers need conviction and back bone. They must be tenacious in the pursuit of design and product excellence.

Vic Gundotra, a former Google executive, once told a story about an interaction he had with Steve Jobs.

Gundotra noted that Steve called him and said the following:

"Vic, we have an urgent issue, one that I need addressed right away. I've already assigned someone from my team to help you, and I hope you can fix this tomorrow. I've been looking at the Google logo on the iPhone and I'm not happy with the icon. The second O in Google doesn't have the right yellow gradient. It's just wrong and I'm going to have a staff member fix it tomorrow…”

This maniacal attention to detail is one of the many reasons that Steve Jobs is remembered as a legendary figure.

You too can test and validate results post launch to improve your product and obtain better end-user results. No task is beneath the designer who is connected to, and focused on, every detail.

Remain vigilant.

Flattery from a few users does not mean the design is great. My parents loved Pennybox. Unfortunately, few other parents did.

If the user metrics and anecdotes differ, a product designer will ask why.

Step 7: Set Key Performance Metrics and Measure Them

You can’t measure what you can’t count.

Know what you care about it and measure it.

For websites, that might mean the number of monthly visitors or how long users spend on your website.

For mobile applications, that might mean downloads or active users.

Gather feedback rapidly.

Through measurement and feedback you can make further product improvements.

Closing Thoughts on Product Design

This process will increase the likelihood that your products are relevant, well thought out, and can help users. But you can follow these steps and still stray.

Following are some examples of ideas and concepts I have experienced firsthand that make me think about the principles of good and bad design.

Use these examples to think holistically about the products you use in your everyday life and how you might change or improve them.

Case study #1: Bike paths in Munich

I used to live in Munich.

Bike riding is common in German cities. Designers built small bike paths adjacent to stairs to make it easier for riders to get their bikes up and down stairs without heavy lifting.

This is a compelling design and benefits users.

Case study #2: Train platform design

In the U.S. the space between a train and platform is regulated by the National Disability Authority to 1.5 inches. Not so in Europe.

The nearly 4-inch gap common in Europe is seemingly dangerous and difficult for many users.

Feedback from different stakeholders – like pregnant women, disabled people, and bikers – could have led to different design standards.

There is a reason “Mind the Gap” was invented in London.

Case study #3: Unidentifiable light switches

Here is a photograph of a light-switch, similar to the one in my kitchen. Which switch controls which light?

And which switch controls the drain’s garbage disposal unit? This design often leads to confusion and annoyingly (but understandably) I frequently push the wrong button.

Case study #4: Messaging matters

Sometimes good design can be as effective as clear messaging with a simple and compelling call to action. This is good design: a parking sign that is effective and memorable.

Compare the parking sign to the U.S. Customs and Border Protection pamphlet. This piece of paper is cumbersome to fill out and composed of very small print.

The sections are labeled sequentially on the front but not on the back. This is an inconsistent design.

Many travelers on long flights into the U.S. (where this form is required) take off their glasses or contact lenses. Wouldn’t it be great if this form was digital (to be completed upon arrival) or made of a larger font?

Case study #5: Game design

For those that like to play games, Solitaired is an example of great design. It is one of the only game websites that I visit and can start playing games immediately: there are no pop-ups, no logins, no distractions.

The focus is on the user’s pure interaction with the game, and their simple navigation takes relevant players to their other popular games like Freecell and Spider.

Case study #6: When design just works

Internal communications and email tracking firm Contact Monkey uses an elegant design to help their clients see pricing examples.

Sample pricing plan for Contact Monkey

The clear visual delineation between offerings, the call to action, and core benefits are examples of good product pricing.

Sketch has long been the application of choice for UX and UI designers. But in the last four years, we have seen many new contenders for Sketch’s crown. Three of them that have made the biggest strides are Figma, Adobe XD, and InVision Studio.

These four tools have many pros in common but there are some differences too. For example, the first comparison, Adobe XD vs Sketch, makes sense especially since both have a similar interface which is user-friendly and has a minimalistic style.

In this article, I analyze how the most used design apps compete and what their unique features are using my experience acquired while working at Creative Tim.

Adobe XD

Adobe XD was developed and published by Adobe Inc. XD, released on 18 October 2017. It is a vector-based user experience design tool for web apps, mobile apps, and voice apps available for macOS and Windows. There are versions for iOS and Android as well that help you preview the result of your work directly on mobile devices.

XD also support website wireframing and creating simple interactive click-through prototypes. With the character and layout tools of Adobe XD, Elements can be easily created and individual objects can be exported.

The interface is kept relatively simple, with a toolbar that is aligned at the side, as well as the large artboard area.

Comparing Adobe XD vs Sketch makes sense especially because of this similar interface which is user-friendly and has a minimalistic style.

Sketch

Sketch is a vector graphics editor, developed by the Dutch company Bohemian Coding. Sketch was first released on 7 September 2010 for macOS. It won an Apple Design Award in 2012.

A key difference between Sketch and other vector graphics editors is that Sketch does not include print design features. Sketch is only available on macOS. This problem is partially solved by third party and handoff tools.

When Sketch first came out it completely disrupted the interface design space, but Adobe XD and Figma have recently come forward as new challengers. They offer unique functionality like prototyping and live collaboration.

I’ve recently been researching these tools for my side project, uxtools.co, and wanted to share what I believe the be the most noteworthy decision points. Also, from my point of view, learning to sketch is very useful and it does not take to much to become a Pro.

Figma

Figma came to the stage in 2016 with initial funding of $14M.

With its seamless user interface and sleek feature palette, the tool quickly became a notorious competitor to similar solutions in the field.

Designers from brands like Twitter, Microsoft, GitHub, and Dropbox swear by Figma as the ultimate UI design tool.

InVision Studio

InVision Studio is a new piece of software, released in 2019, that allows designers to build more advanced animation and micro-interactions. Studio also integrated with InVision’s link to Sketch via its Craft plugin.

InVision Studio has got a nice dark UI by default, that helps developers focus on the work to be done in the evening. However, with macOS Mojave, every app can look like this quite easily. When they created it, they were inspired by another design tool - I am thinking about the Sketch app.

Apps Comparison

1. Pricing

Budget can be a big deal when you’re working with your own resources. Some of these licenses have educational and promotional pricing (often 50% off), so don’t miss that part. For example, Figma will get you there for free as long as you're not working on a team.

• Figma: Free for individuals! You can have 3 projects for free, or you can upgrade to unlimited projects and team functionality for $12/month (billed annually).

• Sketch: $99 per license that gets you the Mac App for life and access to the next production versions of the app.

• Adobe XD: It offers free and paid plans, depending on an individual's or team's needs. Paid plans start at $9.99/month.

• InVision Studio: Free right now.

2. Platform

Though Sketch has been immensely popular, it forces designers to only use Mac, which alienates developers from accessing design files.

• Figma: Browser! Figma recently released a Mac app and Windows app (not offline-capable, though).

• Sketch: Mac only.

• Adobe XD: Mac and Windows. Subject to the same limitations as the CC suite.

• InVision Studio: Mac and Windows.

3. Live Collaboration

Nobody likes to send at the end of the day “version 3.0”, “version3.0.final”, “version3.0.final.final”. Live Collaboration can help us, especially live comments.

I imagine these were the same concerns that surrounded the release of the highly innovative Google Docs suite. Google Docs, however, turned the Microsoft Suite on its head with live collaboration, and now Figma is seeking to do the same thing with UI design.

• Figma: Yes! Not to mention being browser-based, it allows Windows and even Linux users to have a very polished design tool.

• Sketch: Not natively, but a plugin, Picnic, is looking to change that. Also, they have Sketch for Teams.

• Adobe XD: It offers real-time Coediting, launched at Adobe MAX 2019.

• InVision Studio: Not currently possible, but can generate share links.

Image: Figma - Argon Design System Pro

4. Handoff

Recently a few apps have been developed specifically to deliver specs (sizing, spacing, color) to developers, but design tools are starting to integrate this functionality natively.

• Figma: Because of live collaboration, developers can easily jump in (regardless of OS) and access the designs. Figma now neatly prints the handoff code for CSS, iOS, or Android in the right panel.

• Sketch: They've recently launched their own native developer handoff feature — Cloud Inspector. There’s even an entirely free alternative called Sketch measure that works just as well.

• Adobe XD: It offers design specs that allow a designer to create a shared link that contains measurements, assets, and automatically-generated CSS code snippets.

• InVision Studio: They have “Inspect Now”.

Image: Figma - Argon Design System Pro

5. Offline

This is so important. Some online apps can protect your information when Wifi goes down, but you need full access to open, use, and save from the app offline.

• Figma: No, in an AMA they stated they don't have any current plans to add it.

• Sketch: Sure.

• Adobe XD: Yep.

• InVision Studio: Yes.

Image: AdobeXD - Argon Dashboard Free

6. Prototyping

There are literally dozens of these apps nowadays, but they might become extinct as Adobe XD brings prototyping directly to the design tool. Keep your eye on these.

• Figma: Yes! It's very basic but feels like Adobe XD without the transitions. Also, there's a nice Framer integration.

• Sketch: Yes!

• Adobe XD: Yes, native prototyping within the app. Adobe XD also supports voice prototyping and keyboard/gamepad support.

• InVision Studio: Yes, you can create prototypes and animations.

Image: InVision Studio - Argon React Native

7. Symbols

Symbols can make your work easier. These have completely changed the design process. Forget building and duplicating list items over and over, let symbols do the work for you.

• Figma: Good to go. Symbols now have states, constraints, and overrides.

• Sketch: The symbol functionality in Sketch is very impressive, and continues to improve. Symbols can be updated across entire documents and can resize responsively (that means less work for you when changing screen sizes).

• Adobe XD: It offers components that can be used throughout a document as well as linked across documents. It also allows designers to create variations of a component for different interactions, known as component states.

• InVision Studio: they have components that are a close approximation to the symbol conventions found in other applications. Components in their final form will honor a broad, scalable hierarchy that allows designers to quickly build-up, mix, and match components intelligently across their designs.

Image: Sketch - Material Kit Pro

Conclusion

Sketch has a big disadvantage here because it is only available for Mac users. And as such, it lets tools like Figma and Adobe XD innovate beyond the basic necessities.

Also, in terms of design tools, Adobe XD provides a robust set of responsive while the Sketch doesn’t have this feature built-in (but it has many plugins). If your tool does something better than the other, it is often enough of a reason to switch over. The browser-based approach that Figma has taken is also something to behold.

When talking about Adobe XD vs Sketch, the first one’s future is looking very bright and will win over many Sketch users. InVision’s change of focus may ensure its survival but one thing is for certain - Adobe XD is here to stay. The Adobe powerhouse is strong, and smaller companies like InVision and Sketch will have to work hard to stay relevant in the future.

People usually prefer to design and work in just one place. If you’re a part of a team, then Figma is undoubtedly for you.

After all of that: first is Figma, second is Sketch, third is Adobe XD and fourth is InVision Studio.

Overall, when talking about the best design software, these four tools are extremely well-suited for modern designer needs.

Try all four out to see which one is better for your use cases. I hope this comparison - Adobe XD vs Sketch vs Figma vs InVision - helped you decide which design tool is better for you.

Resources:

https://www.figma.com/figma-vs-sketch/

https://uxtools.co/blog/sketch-vs-adobe-xd-vs-figma/

https://www.codeinwp.com/blog/figma-vs-sketch-vs-adobe-xd/

https://support.invisionapp.com/hc/en-us/sections/360004450191-Studio

https://helpx.adobe.com/ro/xd/help/components.html

https://www.sketch.com/docs/

Tools for conquering the process from Idea -> Design -> Development -> Deployment

Like many people, I have no shortage of ideas for apps that don’t genuinely need to exist. I tend to hold onto those ideas waiting for some imaginary occasion where free time is abundant and I can build all of them with no thought of income or expense. For me, oftentimes the hurdle to completing a side project isn’t knowing how to do something, but finding the motivation and time to bring it to fruition.

That’s why I set a goal to launch a side project in 10 days.

This post isn’t about the advantages of building with a new technology I was unfamiliar with, or 7 things I learned while doing it. Rather, it’s about my process of building a web app quickly, keeping irrelevant ideas from muddying my focus, and my tool belt to make it happen. The end result was Card Surge.

Idea (1 day)

I spend a lot of time designing and building sites, which means I also spend a lot of time poring over well-designed sites from popular brands. I almost inevitably open up the Chrome inspector to examine how styles are applied or elements are laid out, because I want to see what can quantify those designs as good.

Then I find myself building my own site and referring back to those examples. I repeat the process of opening up the inspector, tweaking their styles, adding my own styles, not getting it right, positioning everything absolute which still doesn’t work, and eventually coming up with something reasonable.

Having found other design tools online like Coolors, or Hero Patterns that were valuable to me, I thought I could make something similar to fit my own interest. And so I set out to build a faster way to iterate over card UI.

I dug through existing tools and found that they looked kind of meh. They didn’t make it easy to create a decent shadow (because sliders were often used for inputs that rarely needed to be tweaked more than a number or two), and there was no reference to designs that actually worked. I felt like that was ample validation for my idea.

Design (2 days)

You see cards in layouts everywhere: pricing pages, product pages, lists, and so on. They are a great way of grouping relevant information and also can stand out on the page with a drop shadow or outline. You can refer to some of these examples of how they can vary:

_[https://crisp.chat/en/pricing](https://crisp.chat/en/pricing" rel="noopener" target="blank" title=")

_[https://flat.io/pricing](https://flat.io/pricing" rel="noopener" target="blank" title=")

_[https://www.intercom.com](https://www.intercom.com/?ref=pages.xyz" rel="noopener" target="blank" title=")

_[https://www.timekit.io](https://www.timekit.io/" rel="noopener" target="blank" title=")

They can have drop shadows, borders on some sides and not others, hover styles, can vary in color, and you can even apply multiple shadows to a single element to create a more exponential gradient in the drop shadow.

I wanted my tool to help designers and developers create cards that looked like those. I figured it should look aesthetically pleasing and use cards itself to help demonstrate what can be done to make them shine ?

I started shaping my ideas in Figma, kept myself from hyperfocusing on unimportant pieces that I could easily do later (like adding logos for brands, adding social icons, and so on) and ended up with this:

_[https://www.figma.com/file/Cav6jxGjiOSOJLaZrnWUtiG1/Cards](https://www.figma.com/file/Cav6jxGjiOSOJLaZrnWUtiG1/Cards" rel="noopener" target="blank" title=")

I knew that I wanted several things in my end product:

1. An editor to tweak styles that would update the UI live
2. A slider that could rotate through nice, fresh examples
3. A place to export the code by copying to the clipboard

Those 3 essentials made the design, along with other things like the content below it and how exactly I’d format the footers and headers I’d left unfinished. It wasn’t entirely fleshed out, because I wanted to get started building before I got too carried away unnecessarily changing things that were probably fine as is.

Development (7 days)

I figured that the most time consuming piece would be actually writing the code for the app, and I wasn’t wrong. There always seem to be issues to worry about that don’t become a problem until you’re in the code. Things pop up like proper UX with the form elements, design decisions that weren’t thought out in initial designs, unsupported features by libraries you plan on using, or Twitter demanding your attention at the expense of your project. ?

I bootstrapped the development process with Gatsby because:

• I could build the interface using React
• Converting the site into a PWA would be as simple as adding a couple lines to a config file (see this tweet)
• Hosting would be a breeze with just static files to deploy
• I could skip a lot of the initial boilerplate and start building the fun pieces right way
• Gatsby is just freaking cool ?

I started from the gatsby-default-starter and built much of the functionality without problems. I implemented 3rd party libraries like react-color and react-slick to remove the need to build complicated slider and color components.

During this time, I decided how to lay out content on other parts of the page that my designs hadn’t included, and built those parts too. I took advantage of newer trends like CSS Grid that made responsive layouts much easier.

At one point, I realized that the diagonal divider I’d included in the layout of my app could be abstracted out and turned into an npm package other people could use. After building a simple component and publishing the package on npm, I realized that I was way off course from my original goals for finishing my project. It would take too much time, so I abandoned that venture (after appending it to my aforementioned list of unnecessary apps and projects to be completed at a later date, that is).

I used a GitHub project to keep track of some of the little things I wanted to get done that were lower priority, and eventually took some measures to add in Gatsby plugins for Google Analytics, some metadata, and included icons for browsers, mobile devices, and the PWA manifest configurations.

Deploy (~45 minutes)

…and launch!

Once I got to a point where my app worked and functioned as I’d designed and envisioned, I thought it still wasn’t good enough. I imagined a portal where users could authenticate, save, and share styles they’d made, and then use the app as a reference to return to. I came to the conclusion that that wasn’t my original intent, and decided to just wrap up what I had actually done. I could build on top of it if I had the motivation later or found that it was something people would actually use.

Getting past those inhibitions of uncertainty throughout were easy since I had a goal in my sights.

I finally realized that I could look at my hard work and appreciate a genuinely cool thing I’d made:

The finished product in it’s natural habitat

Being more or less complete, deploying it was next. Deployment was a really simple process. I didn’t really want to dump money into a domain on a side project I might not care for much in a year or two. So I took advantage of how Surge hosts your sites in the free tier and named it card surge, so all I needed to do was snag the card subdomain and I had a free branded domain at card.surge.sh ?. I ran gatsby build and then surge, and my code was online and distributed across a CDN with automatic SSL.

I also love Netlify too much to not use it, so I pointed my GitHub repo at a project on Netlify to automatically build any pull requests or commits to Master (which came in handy just a couple hours after launching when the first pull request came in).

Without a need for a backend, my site was up and I hadn’t spent a cent.

I took some screenshots and recordings using Kap, wrote up a description, and posted Card Surge on Product Hunt.

Looking back

Working fast and pushing towards a completion date (that I had looming on the calendar) was really rewarding. I had to simplify problems to what mattered and only address concerns that would actually interfere with finishing and launching by my end date.

If I find another project I realistically think I can complete in just a few weeks, I’ll definitely do another sprint like this.

Overcome whatever reservations you have to wrap up that side project you’ve been waiting to finish — you won’t regret it!

Thanks for Reading!

If you have questions about how I did something, why I did something, or what I did horribly wrong, I’m happy to hear from you here in the comments, on Twitter, or via email.

If you found what you read interesting or helpful, feel welcome to leave a clap or two, subscribe for future updates, or retweet/share this tweet: ?

The challenge

I set out to see how far I could push myself creatively as a designer by rebuilding an App I frequently use.

I chose Tinder because I’ve used it a few times, and realized a few modifications to the design would be helpful. Of course I’m not suggesting that my design should be used instead of the current Tinder design. It’s just a different point of view from the current design of the App.

My Goals:

• Create a better user experience
• Facilitate the use of the application
• As a personal goal, to complete my first design project

Understanding the App

Tinder is a location-based social App that is most commonly used as a dating App with a target audience from 18 to 34. Since its debut in 2012, Tinder has undergone rapid growth thanks to its extremely simple way of use and amazing organic strategy.

The Home Page

Old screen and my redesign of it

Problem 1: Bottom buttons and Card swiping

As soon as a user opens the App, Tinder users have two prime features to indicate whether they like a profile or not:

• the bottom buttons
• the card swiping

So which of these should they use?

Both options are very good, but the card swiping provides a much smoother experience. If you compare it to other Apps that are increasingly implementing the card swiping feature, Tinder is far ahead. We should take 100% advantage of it.

After analysing the existing design, the “super like”, “like” and “nope” buttons were removed, with the card swiping gestures for these actions.

The following new buttons were added.

Dismiss Profile Button

Dismiss Profile

Let’s say you come across a profile that interests you and at the same time does not, you can dismiss it and go to the next one.

Message Button

Message

Feature for Tinder gold that would allow you to send a message to any profile, even if they have not yet liked you.

New swiping card - Friends

Tinder is listed under “Lifestyle” in the App store. Although Tinder isn’t marketed as a dating App, most people see it as one. Browsing through the profiles, I saw plenty of bios with something like “Just looking for friends!”.

So swiping down on the new swiping cards allows you to be friend of someone.

Problem 2: Changing pages to see a profile

This modification was something more personal. I didn’t like the way a user would navigate to a person’s profile. I did not consider the process fluid in the eyes of the user as we are constantly changing pages and it does not become very intuitive or practical if we want to go back after seeing the profile.

So I decided to implement the function of being able to see the profile of the user without leaving the main page. Swiping up would display the user’s profile and swiping down would return the user to the main page.

Redesigning the Tinder Feed

Tinder introduced the Feed feature that shows you real-time updates of your matches all in one place. Is a very good idea that will take you beyond “It’s a Match!” and help you make a real connection.

But to access this new feature you need to go to the messages. As I think we should take advantage of this I decided to remove it from the messages and put it on the main screen.

A user would just need to click on the feed button on the main screen to access all the news from their matches.

To navigate within the feed, I decided to implement two buttons:

• New - Clicking on “New” at the bottom of the screen on the right side would create a new post.
• Old - Clicking on “Old” at the bottom of the screen on the left side would navigate to the oldest post until we reach the last one.

The buttons:

• Message - Instant message to the connection without leaving the feed.
• Share - Sharing on social media.

New Feature: Tinder Experiences

Most people see Tinder as a dating App. But it’s much more, the experience can be more powerful. I implemented a new feature called “Tinder Experiences”, a way to take dates and meetings with friends to another level.

Discover places of the city where you are, meet people who share your passions, open up to new experiences.

Status

There are a few other things that can be implemented to improve the user experience a lot. One of them is to know the status of the user. So in a simple and minimalistic way I inserted the staus of users within the messages. This improvement allows us to know if a user is online, offline or inactive.

Another possible feature is to Filter users by when they were last active. This would allow a user to set a range in your “Discovery Preferences”, For example, display users that have been active within the last 30 minutes.

Conclusion

Going into this project, I knew that this would be the perfect opportunity for me to improve my design skills and push myself creatively. I’m studying computer engineering and at the same time studying design alone at home as I want to pursue a career in product design. I figured out that the best way for me to learn would be to just throw myself into a project.

So for me this is not the end of redesigning a mobile App and only the beginning.

Thanks for reading. I hope you liked it. ?

I would appreciate your feedback.

Building something users want is hard — damn hard. They are a fickle bunch and make it so difficult by not clearly articulating exactly what they want. They make us guess, and when we give them something we know they need, they don’t want it. Don’t they know what’s good for them? Why won’t they listen? Grrrr. So frustrating!

The problem is, we’ve told users what they want instead of figuring out what users want. We’re frustrated because what we decided was wrong. Who likes to be told they’re wrong? So how do we deduce what users want and achieve the product market fit we’ve been searching for?

The Lean Startup way starts with a hypothesis (hopefully based on research, experience, or divine inspiration). Then you build a minimal viable product, measure the results, and adjust the product or hypothesis. In other words, we need to figure out, in the quickest way possible and over many iterations, what the users really do want.

There are many great articles and books about finding product market fit. They often don’t discuss falling into the trap of thinking you are on the path the success, but actually being on the road to failure. The best way to tell if you’re building something no one wants is by looking out for these eight traps.

Trap #1: Clueless, like whatever.

You have no clue how many people are using the new feature, application, or site. You have no statistics, measurements, or hard data. When asked, you respond with, “Um…”.

What to do: Being blind to your success or failure isn’t a good way to go about anything. Start by gathering data and metrics with tools such as Google Analytics (free) or MixPanel (costs money for larger sites). You should own this data and be able to rattle off the top of your head the number of users you have, engagement, and feedback. Define your key metrics and own them!

Trap #2: Wrong stakeholders.

You’re only concerned if your internal business owners are happy. The start and end of your success is the happiness of your business owners. When asked for something you know isn’t a good idea, you go along since the “business owner asked for it.”

What to do: Is your goal making your end users (the real users) happy or your business owners happy? Unfortunately, companies often measure employee success (i.e. comp, promotion) based on the happiness of the business owner. But your end user — external or internal — is all that matters. They are the true measurement of success and product market fit. Success will only be achieved if your full focus is on your end users. If that isn’t possible at your company, look for a new job.

Trap #3: I know they’ll love it, I just know it.

You haven’t A/B tested any of the new features because you already know users will love it. You have released the product and people like it or are using it, so job well done.

The Mirador Building in Madrid. Designed by Dutch architecture studio MVRDV in collaboration with the Spanish architect Blanca Lleó and opened in 2005

What to do: This goes back to metrics and measurements. Stop making assumptions because you’re most likely wrong. Only assume you don’t know and you need to test and verify. Use tools such as Google Optimize (free) or Optimizely (paid) to confirm your hypothesis that the new feature is better than the old. You’ll be amazed at the greater success you can achieve through A/B testing. The classic example is 25% more clicks if the button is green instead of red.

Trap #4: My way or the highway.

Your internal customers aren’t adopting the new feature/product that you know is so much better than the old one. You shut down the old feature/app to force your users to use the new one. You await the thank you notes from the users.

What to do: Your users have clearly told you they don’t want the new feature/app, so, please STOP forcing your will on them. Figure out why the users don’t want your new system: ask them, A/B test MVPs, or be willing to scrape or pivot. I’ve been in situations where we forced the users into the new system they didn’t want. Why? Because we already spent a lot of time and money on the new system. As you can imagine, it ended in absolute disaster.

Trap #5: I did my job.

You kinda know people aren’t using what was just built. But you measure success as having delivered the full scope on time and on budget. You declare success!

What to do: Realize you only achieved failure. The true measure of success is: Does your end user want the product? Excuses don’t cut it, unless you plan on sitting down with each user and saying, “Now, I know you don’t like what I built, but I met all the requirements. The product was on time and on budget. Thus, you should use it and like it.”

It is easy (believe me, I know) to escape into “I did my job” thinking. Especially if your company encourages you to focus on your narrow silo (e.g. engineering, marketing). Resist this delusion and always be asking yourself, “Is what I built (no matter how awesome it is from my perspective) what my users want?” Answer this question with data-driven metrics collected from tools such as Google Analytics.

Trap #6: Everyone says they love it.

You measure the product success with, “Users really like it, we have gotten great feedback and my boss said…”.

What to do: As opposed to number Five Trap above, you actually believe you have reached product market fit. You came to this conclusion by listening to anecdotal evidence. Imagine if you were asking investors for a higher valuation because of your great success. Would you present your evidence as, “User Joe Smith said, ‘Great work guys, congrats’” or “The COO said this is really great for the business. Keep going!”

Don’t feel bad if you have fallen into this trap. I’ve sat through many all-hands meetings at billion dollar market-cap companies. We measured our success with similar quotes. Remember, data-driven metrics help you truly measure product market fit.

Trap #7: We can’t release without this feature.

You spend three, six, or twelve months building before shipping. You’ve put your blood, sweat, and tears into the product and it has finally happened. You’ve built every feature the users need and it is glorious. Let’s release!

What to do: Build the minimal viable product (MVP) possible. From there you’ll learn if what you’ve built is on the right path to product market fit. Imagine you’re driving a car at 100 mph towards a brick wall with a 6-foot wide space for you to fit through. If you are a mile away, but hundreds of feet off from the opening, you’ll have time to adjust and make the fit. If you are 10-feet away, but hundreds of feet off from the opening…ouch.

In finding product market fit, you have limited time/money. Would you rather continually measure, learn, and adjust to find that fit? Or would you rather close your eyes, build for 3–12 months, and open your eyes at the end to see if you fit?

Trap #8: Year-end review time.

You spin your year-end review to focus on how hard you worked and delivered everything asked of you. You got a good review, so you must have been successful.

What to do: Look at your last year-end review. Were you able to quote data-driven metrics and definitely prove you found product market fit? To be honest, this is a hard one since no one wants to say they failed, especially at the year-end review. However, if your company culture embraces failure and if you learn from the failure, then perhaps you can be honest. If not, look towards the next year and work on driving towards what users want. If you have data-driven metrics on your year-end review and no one else does, you will stand head-and-shoulders above your colleagues.

Having worked many years in large corporations, I can attest we often came up with the next game-changer by drawing something at a whiteboard. We then self-congratulated our brilliance and spent six months building. This justified why our bonuses should be given even though the users didn’t want what we built.

Conclusion

Finding product market fit is hard — if it were easy everyone would be doing it. Even if you’re practicing building MVPs and have a holistic view of your company, you still might not have hit the mark with your users (achieving the hockey-stick growth). The best thing to do is keep trying. And always be asking yourself, “Am I building products users want?” or “Am I falling into one of the traps of product market fit?”

About the Author: Geoffrey Bourne is the CEO and founder of RETIRETY — helping people in or near retirement find a better way to retire.

Thanks for reading!

If you enjoyed this article, feel free to hit that clap button below ? to help others find it!

Some time ago I shared in a Medium article the idea for context aware messenger app. The idea challenged the design limitation behind all messenger apps allowing you to write only one message at a time.

What I always missed in these apps was a way to save the message I’m currently typing and type and send something else instead. Then a way to get back to previously composed message and continue. Just to stay on topic and keep some order in my conversations.

Left to right: Messages, Slack, Hangouts, Messenger, Whatsapp.

The way I do it today involves the sequence of text field related gestures: Long press, Select All, Cut, Type in, Send, Long press, Paste, continue.

My concept allowed to replace that sequence with a single tap, but it was up to the app to recognise the need for saving a message based on the context of the conversation. I built a Quartz Composer prototype to show the feature in action:

But I never shared the prototype, as it wasn’t functional, allowed for only one extra input field and was done solely for the purpose of recording that video. Also Origami prototypes for Quartz Composer didn’t work very well on the device (not mentioning the absence of native keyboard).

Release of Origami Studio allowed me to revisit the concept and build fully functional (sort of) prototype to share.

I ditched the context aware part and allowed for saving as many drafts as you need, whenever you feel like it.

Here’s a demo video of the new prototype.

Building in Origami Studio.

I could write a separate article/tutorial for each of the technical challenges I encountered while building the proto, but I’ll limit myself to just briefly list some of them here. Hopefully these short descriptions will be enough to spark some ideas whenever you encounter similar blocks. If not don’t hesitate to ping me directly.

Multi line input field.

Text Field component in Origami Studio doesn’t allow for multi line inputs. When you double tap on it to reveal it’s content’s you’ll find the actual Text Input component that does. The problem is it doesn’t have a cursor/caret. So hacked in a cursor by measuring the position of the last letter in the text field.

Each time you type a letter I check if it’s a ‘space’ and if it is I append it’s index to an Array of spaces. Then I assume that whenever height of the input increases the text will break at the last recorded space. Then I measure the rest of the text to place a cursor in a correct position of the new line. When you don’t tap the space I just measure the size of the text that fit the line.

Building a conversation feed.

The challenge here was dynamically creating chat bubbles while keeping the correct order in the feed. When bot starts typing you can see the last bubble on the feed with 3 jumping dots. But if you send the message before it finishes typing your bubble should land on the feed before the bot’s bubble. I managed to make it work by keeping two arrays of messages. Temporary one (bot typing) and final and switching between them whenever bot starts typing or sends the message.

I created a JSON config file with the bot messages that allow you to configure what and when the bot is sending and if it should wait for your message(s) to start typing.

{"message":"Ok, I'm dumb. What do you want from me?!", "waitforuser":2,"delay":1}

waitforuser — describes how many user messages should the bot wait for before it starts typing. Zero means it won’t wait for user at all.
delay — time in seconds before bot starts typing.

Creating/removing input fields and managing their order.

Whenever you create input field I’m increasing the count on the Loop patch, but as soon as you don’t need the field anymore I tried to remove the field from the loop and keep the other input fields keep their order and content. It was impossible for me to figure out as loop patches don’t keep the reference to the actual instance of the element they’re replicating. I worked around by hiding and reusing unused fields instead of removing them from the loop.

Downloads!

You can download Origami prototype, JSON file as well as multiline text field component from my Google Drive.

User’s Manual:

Long press on Send button to save the current text and create new input field. (Yes! It’s undiscoverable. I know.)
Prototype is optimised for use on the device. (You can’t hide the keyboard)

Last minute discovered fun facts:

• The prototype crashes when using emojis. ?
• Multi line input field cursor can behave erratically when typing super fast (I’m sharing anyway).
• When you send a message in the exact time that bot starts typing, the empty bot message can appear on the feed.
• Other bug fixes and performance improvements. (What?!)

I recently read Barry M. Katz’s “Make it New” and am convinced that it’s a must-read for any digital product designer.

Make It New traces the role of design in Silicon Valley.

It’s the story of how a group of outcast designers in Silicon Valley transformed the design field. It’s how they advocated and advanced design from decorating hardware cases to strategic leadership. It’s the history of how these designers defined new design fields within Hewlett-Packard, Ampex, Apple, and a new breed of product design consultancies.

Silicon Valley designers became leaders of all new domains: interaction and (digital) product design. Fields ignored by traditional advertising and graphic design. As such, they were free to explore ergonomics of physical computers and interaction of virtual interfaces. Previous constraints and traditions did not apply. Instead, their creativity created the new field of interactive experiences by merging engineering with humanities.

Design in Silicon Valley was also defined by the freedom of designers to move between research institutes, corporations, and starting their own shops like frog, IDEO, and Lunar. This web of opportunities led to a fluid transfer of knowledge amongst the entire industry. New skills learned in one area were advanced in the next. Knowledge grew as designers jumped into new opportunities and collaborated. Disparate design experience intersected and created new interaction patterns and interfaces.

An important source of San Francisco Bay Area design innovation is West Coast Higher Education. The first wave of postwar designers attended the Art Center College of Design in Los Angeles; a school focused on industrial design, illustration, photography, and advertising. It trained many returning post-war veterans that became the first generation of Silicon Valley designers. In the South Bay, a short distance from each other Stanford and San Jose State University added into the mix theoretical and technical designers. In the Oakland hills and the Dogpatch of San Francisco, the California College of Art added a new group of designers trained in interaction and business.

Design in Silicon Valley is much richer than just Steve Jobs and Moggridge. It includes people such as Carl Clement, who in 1951 was the first designer at HP. He redefined HP products by introducing standardization across all products. The final interface of hardware products was born from his introduction brainstorming and user research into the product process. Techniques that we now consider standard but in 1951 were revolutionary.

Of course, military and government were key players in the growth of technological innovation in Silicon Valley. The federal government unintentionally helped as it sponsored the development of computing that in return required designers to make more humane. Make It New touches on the government’s role shaping the foundation of computing.

The history of design in Silicon Valley is multithreaded and deeper than told in the popular press. Make It New is a great overview of the evolution of design in the Bay Area. The book ends not in the past but in the present as it touches on the role of AirBnB, Facebook, and startups in creating the next generation of Bay Area design innovation.

Make It New: The History of Silicon Valley Design By Barry M. Katz. MIT Press 2015. 280 pages.

Make It New
_The role of design in the formation of the Silicon Valley ecosystem of innovation._mitpress.mit.edu

Moving from a concept to a properly defined MVP

The Minimum Viable Product, although a properly defined term, means different things to different people. In fact, it is one of the most misused terms in the technology domain. It is often poorly referenced to describe a prototype, a demo or even the first deliverable of a project.

“In product development, the minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future development” — Minimum_viable_product

Defining the MVP

Assuming you have this great idea, you need a method to start defining the product. More specifically, the subset of the product features that can serve your objectives with the minimum cost and risk. The following explains how to get from an idea to an MVP.

Identify your users

Set the context — think of the problem, the situation and the opportunity. Think of what is already available in the market dealing with the same problem. Identify and name the types of users involved and how they interact. Document your users, their needs, the problems they are experiencing, their expectations, and the best-possible experience they could have in your context.

The Minimum in the MVP implies that you already have the big picture, you have the product vision! A common mistake is when the team ‘easily’ identifies a set of ‘obvious’ use cases as the MVP — without a clear product vision and the big picture.

Check also: How (and why) to write great User Stories

Think as a user

Having the big picture you need to apply a process to identify the smallest subset of functionality that serves a very specific goal. The goal is to satisfy your users. You also want to enable critical user insights and feedback. This feedback can improve the next iteration in your product development plan.

The big picture is the super-set of user stories across all the classes of users identified. It’s a good idea to create a large set of epic stories. Then iterate across all identified users and try to define user stories covering their needs and expected benefit/ gains.

Use a compact format as the one proposed in Scrum: as a I want to so that <describe the gain>. You don’t have to worry about priorities at this stage. A good idea would be to name each story/ assign a compact title for easier classification and organization.

As soon as you have your product feature super-set, you need to review it to ensure that it defines a product (the P of the MVP). Search for continuity, homogeneity and complementarity among your user stories.

As a result of this process, you may realize that more than one of the related products are referenced in your backlog and need to be separated. Or you may realize that there are significant gaps that need to be filled.

Again, think as a user. Use empathy to identify interactions, scenarios and stories that need to be included.

You need to also gather feedback so you can try to validate your stories and the product. You can gather feedback through expert advice, user interviews, formal or informal surveys or public domain references (for instance any reliable public domain statistics that can help you test your assumptions).

Think as an entrepreneur

Thinking as a user is great. You can be creative and forget, for a moment, about real-world challenges such as technical and financial constraints. Your objective is to compile the product super-set of user stories to satisfy — or to even to excite — all the different types of your users.

Now it’s time to think as an entrepreneur. You need to start considering and documenting implementation costs, priorities, strategic advantages and differentiators against competition.

You need to estimate the development cost of each user story. You also have to quantify the expected value for the user along with the expected impact on the business: your business.

The logic to identify the right minimum subset can be complex — requiring estimates of all the above at the user-story level. For each user story (or Epic) you need to have at least the following:

1. The complexity / cost associated / feasibility

2. The expected value for the user

Estimates of the above dimensions could be on a numerical or ordinal scale. As soon as you have those estimations you can then rank your stories. Also plot them in a simple chart against complexity and expected value for the user.

Check also: How to become a great Product Manager

Prioritize, Rank, Set the focus

At this point you can start prioritizing high-value, low-cost stories over lower value, costly ones. Be aware, though, of those natural, strong dependencies between product features.

In many cases there are technical or procedural dependencies requiring certain features to be implemented first, although their cost is high and the expected user value low. These dependencies need to be identified and possibly visualized in the user stories mapping.

Having the above for each of the features (user stories) of your product allows you to define your MVP as:

“… the minimum set of features (stories) ensuring a good-enough product experience driving increased user engagement that can secure the next product development cycle”

You can sort your entire product backlog by dependency sequence (start with foundation). Then by the value for the user in descending order. Then by complexity and feasibility in ascending.

You can also combine budget constraints, team’s velocity and go-to-market strategy makes it ‘easy’ to identify the red-line of your to-be-proved Viable MP.

Reality check

In reality though, this will be just a draft definition of an MVP. What is needed in an ideal scenario is feedback and validation of the features by real users via prototyping, focus groups, market research, competition analysis and related methods.

The more input from real users, the more confident you can be that your product concept has all it takes to become Viable (which also assumes a great execution/ implementation/ launch).

Check out this other article on how to define an MVP (among other things).

Thanks for reading!

Images: pixabay

Designing for e-commerce is an unforgiving task. Consumers — especially those in India — are inherently price-conscious. From mobile phone accessories to televisions, the cheapest listing wins.

Whether it’s Flipkart, Amazon, or Snapdeal, price is the main thing that matters. This leaves very little room to piggyback on loyalty.

This left Flipkart with an excruciatingly interesting problem to solve: how do you create loyal customers? How do you build a shopping experience that would help curb bargain-chasing, convenience-focused behavior?

To keep the business going, e-commerce platforms depend on periodic events ranging from seasonal/festive sales, clearance sales, thematic sales etc., where the sellers arrive at an agreement to offer certain discounts on their listings.

To put my organization in context, in 2015 Flipkart sold goods worth $300 million during ‘Big Billion Days’, a five day sale event very primary to Flipkart’s business. During the first hour of the sale, Flipkart sold about 500,000 products — with almost 140 orders per second, across 3200 cities and towns across India.

But the life isn’t all sunshine and rainbows — even for the e-commerce giants. Flipkart sees a rise in number of uninstalls right after these sale events end — a retention rate of ~30% on average, year-after-year since 2014. Users don’t often use the Flipkart mobile app once the sale is over, also hinting at the storage constraints Indian mobile users face. They choose to keep apps like Facebook, Whatsapp, and YouTube that they’re more habituated to, but not Flipkart.

Which led us to dig a little deeper into how various category of apps pan out in terms of customer loyalty:

This gave us both (me and Rahul who worked on this project at Flipkart) enough context to ask ourselves: What does it take to build habit forming products?

Our approach

Habits are actions performed with little or no conscious thought. Research suggests ~40% of what we do everyday is out of habit. The video gaming industry has been using the concept of hook to keep the user invested & engaged in their products.

The hook starts with a trigger in user’s environment. We are familiar with external triggers when we see notifications of varying degrees on our products. But what’s more critical to form lasting habits is internal triggers.

Most frequent internal triggers are emotional, and more often than not they are negative. So users try to change this negative mood by browsing Instagram or watching funny videos online.

We make many involuntary activities through the day to escape the negative emotional state, and this is where we thought we could experiment by showing relevant deals for the user on Flipkart.

The user would give in — anticipating a reward — and thus engages/invests into the product/app.

Every morning, when we wake up, most of us feel at least one strong emotion: a fear of missing out. If you find yourself checking email, Facebook, or Twitter the first thing in the morning, then this may be what’s going on inside your mind.

The word FOMO (Fear of missing out) was in fact added to the Oxford English Dictionary in 2013. Although the terminology has only recently been added to our lexicon, experiencing FOMO is nothing new.

We saw an opportunity in this to create internal triggers, and initiate the hook, in addition to our external triggers.

Our Solution

We tried to list out various archetypes of external triggers that might draw the Indian consumers’ attention in the context of shopping. To create a medium for external triggers, we had to think of a UI pattern that could enable this.

We observed that the traditional notifications approach might not work very well due to many of it’s inherent issues, which include an increasing notification blindness among consumers.

1. Daily Digest: **Infinite VS Finite Feed**

We thought of building a daily digest of a finite number of products, and refresh the digest once every day. This meant we had to move away from our infinite feed of endless products, which often leaves the user in decision-paralysis.

This meant our recommendation engines had to be re-built from the ground up. Flipkart is a marketplace that has over 30 million products in more than 80 categories. This sheer variety means we need to map these products to users’ interests. This led us to the next challenge: relevance.

2. Relevance

It was evident that personalizing this finite feed with relevant products would be a lifeline for our app’s engagement. Traditional recommendation systems work by crystallizing usage history and finding patterns in it.

But for us, this would only partly solve the problem. So we interviewed a few users to understand when do they shop online, and how. We learned that our users shop in the event of two major themes:

1. Intent: when there’s a strong need, where the user performs a narrow search. This is where we have to make our search a lot more clinical in capturing the intent and serving the need.
2. Interest: On the other end of the spectrum, there’s “window shopping” for products that the user likes. And not just products — there are themes in our lives that make us (sometimes even inspire us) to shop. Maybe you’re fitness-conscious, or you’re a travel enthusiast, or you like the brand Nautica, or you recently became a parent, or your friend’s wedding is coming up. This is where we had to gather user’s interest thoroughly.

3. Network of Things

When we reduce many millions of products into a digestible feed of a handful products, we need to think through how we could make products from various categories accessible to the user. At Flipkart, our competitive advantage is our vast and deep inventory of products.

When we profiled users, we saw that shopping happens in themes (again, intent and interest). We decided we could assign a set of meta-tags to each product, and each tag would be a node in a cloud of thematically related product sets.

Instead of grouping and dividing by categories, we turned the tables. We grouped the products in various themes and stories.

This network can be a combination organic and inorganic nodes. This means to pushing interesting event-based content to the user. And it grows differently for each user. Below is one of such network we designed for Travel.

Design

After some whiteboarding and sketching various components, I worked on creating interactive prototypes on Pixate while putting the mocks together on Sketch.

Here’s a short video that showcases the design solution:

Presentation

• There are a lot of ways to present the UX of an app, but I personally feel that a short video centered around a user story is the most convenient yet comprehensive form of explaining.
• Write a script that’s an amalgamation of the set of user stories. Spend decent amount of time refining it. Run it by the other stakeholders to make sure that the backbone of the video is well in place.
• Once the script is ready, start putting the interactive prototypes together, into the right sequence. It’s recommended to record the same on a device to reflect the life-like experience.
• Next is the voice-over. I like the tone of the voice to be a bit more candid compared to the traditional advertising voice-overs. Y hire a ou can hire a voice-over artist from Fiverr

Sketches

UI

Prototypes

**Mocks**

All this led to...

We shared this thought process among various teams at Flipkart to get feedback, and slowly, we saw many buying into the idea of productizing e-commerce. We soon officiated these efforts by creating a team of 4 designers to exclusively work on such moonshot projects at Flipkart.

Skunkworks

Thanks for reading.

Bilal is a product designer based out of Bangalore, India. He deeply values process-driven approach to design solutions. He has been practicing design as a full-stack executionist and prototyping is one of his strengths. Bilal’s engineering academia in Computer Science helps him design pragmatically and have effective collaborations with the developers.