Where to start when joining a startup as first Product Designer

over 1 year ago from , Product Designer

Hey Designers,

I've recently joined a -quite new- startup. There is another (apparently more visual if I listen to the management) Designer who has been working there for quite a while.

They hired me as their first real Product Designer, during the interview process they suggested I could do whatever is needed to improve the product, process etc.

I thought they had some basis but apparently no, the product has evolved without really thinking at the bigger picture and now I'm in a situation where the management wants me to work on new features but I think with the current product it would be quite tricky as it would create something really complicated UX-wise.

I never encountered the case of joining a company and not having even a simple user flow defined. I don't really know what direction to take as I don't want to make the other designer feel like there is something wrong, and I don't want the management to feel like I'm not doing anything or not doing what they want me to do.

Any suggestions? Cheers


  • Account deleted over 1 year ago

    Take it slow. don't go in trying to change everything from day one. Nobody likes that guy. Also, as its a startup, a lot of early decisions were probably made when they had little or no information about what their goals were or their audience. Just do what they tell you for a few months until they trust you and then start suggesting how and why you can improve things.

    30 points
    • lucas terralucas terra, over 1 year ago

      ☝️this! Also I'd just like to add that during this time one of the best things you can do to help is help the company to better define the vision for the product. Once you have this it's easier for everyone to be at the same page and understand the decisions you're taking. It will help you a lot prioritising work too, as I believe there's a plenty of ideas on the backlog at this stage.

      Product managers are your biggest allies. Bring them (and the whole team) together to define your product vision. Afterwards you can define the strategy to get there along with you PM. Oh, and make sure you prioritise user problems to solve and not ideas of solutions ;)

      4 points
  • Andy Dent, over 1 year ago

    Firstly, is there a QA or support department and/or issue tracking system?

    Those people can be your lifesavers and champions. In most companies they are under-respected and often not heard. Support in particular will have the best feel for what confuses users in the current product. Start with their stories.

    As a startup, they may not have an organised support department, so ask who has been doing support?

    8 points
  • Jan SemlerJan Semler, over 1 year ago

    I think before we can help you we need more informations.

    • How many people are working there?
    • Agile development?
    • What is there (Design System, Use Cases, Personas, UX-Research, etc.)?
    • How is the design process currently?
    • Are their Personas, Target Group researches, etc.
    • Just tell us more. In terms of whats there and whats missing...

    In the end you will need structure for a design/conception process and as an output an design system which will play back in future. If you start right with your system it will help a lot down the road.

    There are several aspects to look on, for example:

    • How to approve flows/stories by You, Devs, Stakeholders
    • Who has the last word?
    • Research: Why we need this feature?
    • Writing Stories for the development
    • How does the hand off work
    • What is the current state, where we want to go
    • How is the current product visualised in terms of flows, use case and stories

    Give your bosses an overview on the current state and tell them what can be done (New features) in a short time and why others cannot be done because of "insert soemthing here*

    They should decide what you should do next. Take on new features or build it right. I think you can do that in parallel. Push new features so you will learn how they did it now. After some new features, establish your processes and system.

    hop i could help.

    5 points
  • Suganth SSuganth S, over 1 year ago

    Research is your friend. As product designers, we might have more powerful tools at our disposal which could communicate big things even in a small timeframe if you do it right - Qualitative and Quantitative data

    You don't necessarily need to change the product much or define the journey, but just talk to the product's users and you might discover valuable insights which you can feed it back to the management.

    Present the insights that showcase what you are up to. In fact the management might get more confident when you share these insights with them early on.

    While the company might be small, you will always have one person who might be on your side as an ally. Could be an engineer, could be a data analyst, could be a product manager. Find that person and reach out to her/him and get their help to understand the product better.

    If this is too much for you to try it out, take out a problem that you currently have or the management is having and do a design sprint and bring in stakeholders together. You might be able to get the goals, direction, constraints and data that you need to support the solution, all in a week time.

    All the best, and if you do try out any of the suggestions in the comment section, create another thread in a few months and share us what worked :)

    3 points
  • Mattan IngramMattan Ingram, over 1 year ago

    There is a lot of good feedback here, and I have found myself in similar situations a few times now. In terms of just what you should spend time on designing, in those first few weeks I usually split my time 75% working on the upcoming roadmap so I'm not a roadblock for development, and 25% working on converting the existing product into reusable components in your design tools. Once you have that it's a lot easier to start documenting processes and creating matching components in code.

    3 points
  • Emir BukvaEmir Bukva, over 1 year ago

    I pretty much second Todd’s advice but would add another to it.

    My best advice is to consider if what you’re describing needs to be a binary ("either-or") type of situation right now. Sure a decision about whether to rework an existing thing or build a new feature becomes either-or at some point but maybe it needs not be that right now.

    Would it be possible at all for you, while not compromising the delivery of what teammates expect of you right now (sounds like that’s building out features on top of what you consider an ill-formed core), to design in parallel a minimum showable flow (or whatever artifact is best) of the core that you think should have been? That would allow you to show and demonstrate why taking time to redesign the core would put the product in a better position. Hopefully, the work itself will inspire teammates because they can compare and contrast the current state with this imagined alternate reality. It will surely provide an opportunity for conversation: At worst, you might find that others actually think your redesign is inferior! You might discover that they tried a similar approach but ran into a non-obvious show stopper which you had missed. Or, hopefully, you might be relieved to hear that they never before had anybody who had the skills and was in charge or tying it all together in a way that a product designer is uniquely qualified to do and OMG, this would work so much better!

    The most difficult thing about it squeezing time to do both. The process might help you get even better and prioritizing and time management.

    1 point
  • Andrew C, over 1 year ago

    Suganth hit the nail on the head: your answer is in proving your usability concerns w research.

    Get 3-5 existing users to perform the key tasks of your app (ideally survey or pull data ahead of time so you know what tasks to ask about). Record them with Zoom or Silver back. Time how long it takes them to complete, how many interaction errors they have, and how many fail to complete. You can ask them to try a prototype of the new features your team is exploring as well. This may help illuminate how a new feature may impact existing users. Keep that separate from the initial task though.

    You can make a flowchart based on each step you see them take (hopefully you discover steps even before users start your service).

    Next get 3-5 prospects who reasonably simulate your users but have no experience with your UI. Run the same test as above.

    If new users are able to successfully navigate your app then you don't need to fix it. But the new feature probably won't be as valuable if your core tasks aren't great. Companies get more bang for their buck fixing existing issues in well established flows than adding new flows altogether.

    Show the results with a few videos SHOWING how painful using the app is. The video artifacts are key.

    Make the changes and see how much better your new designs perform. Set an objective. Aim for 100% task completion and an 80% error-free. You can even try and get the time to complete tasks down if you're really ahead of the game (be careful though, not all tasks are improved by going quicker).

    Hope this helps. I started at a startup as designer 2 and had a similar challenge. You shouldn't have to measure every decision you make but if you need to align your product team showing user pain is much better than nagging to deaf ears.

    Good luck!

    1 point