Integrate product design with product development at a startup?

Hey guys! Would love some advice on the following:

Problem: As we have to move and build extremely quickly, our engineering team has to do short, fast sprints so most of the work that the product designer does get ignored. The engineers find it faster to build something directly without it going through a product design process. This has been working fine for now but I have a feeling that we’re going to end up with clunky, incoherent products soon. How would you recommend integrating a Product Design Process (User Research / Prototyping / Testing) before Product Development in a way that does not make us compromise on speed? Any thoughts would be appreciated. Thanks a lot!

1 Like

Here are my views.
Your design need not have to be super good before you go live. You need to decide what is the right quality of design that makes sense with respect to the product, stage, competition etc… If the value for the user is super high, you would want to move quickly to capture the market and compromise on design is okay.

Here are a few suggestions to manage it better.

  1. Identify core workflows which are kind of non-negotiable to have gone through proper design process.
  2. Focus energies on building component libraries/templates which can be effectively re-used by engineers to move fast.
  3. As a common practice, go live with good enough design and quick iterations post the release has been made.

Hope this makes sense.


Speedy inquiry - What does your architect who is right now in your group saying?

Because they would have most context on the product itself and what might need to improve.

This depends on what you are delivering and whether you need to test and iterate on something to validate that you are solving the problem correctly, or that the outcome you expected occurs.

For example, if you have a question like “How can we get more people to click on this widget? Can we try out something simple and then gauge impact, then A/B test changes?” - That can just take the barest of designs and get it out there to test what works.

However, if you are building a more basic product or feature like “I need a user to fill in a registration form in order to access our product”, then I firmly believe that the feature should be delivered according to the design. I prefer to ship a polished product that is better by design than to ship something that looks half done just in the sake of Agile.

I find a lot of teams use Agile methodology and sprints to deliver below MVP level products rather than iterate to the “right” solution.


Thanks, @rossjayp1 we have learned the hard way that basic functionality without good design consideration does not go far. We are a B2B product so we assumed that companies won’t care about UI and other design considerations early on and kept on shipping.

Now we have realized that the bar is very high when some is buying something from us and people do judge a book by its cover. I am working to change some processes to make clean and clear design table stakes in our design process.

Gotcha, I certainly believe in “better by design” and that even something as simple as a data entry form can be designed in a way to not only be easier to use, but also satisfying to the user. At my company we recently redesigned the look and feel of one of our B2B components, and our daily users talk about how much they love the “new app”, and it is “so much easier to use”… even though the functionality is the same, and it mostly just has some design changes.

People like a polished look (look at how popular all things Apple are).


That made me chuckle a bit :slight_smile: People do care about how things look and feel. Thanks for sharing.

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.