What we can learn from a broken UX Design Process

julia warmuth
Nov 5 · 7 min read

Since I switched positions in my company from a Business Development department to our first very own in house UX Team I went through a rollercoaster of emotions and stumbling blocks round almost every corner. But the good thing about that: As UX is a continuous process everything sounds less dramatic when you just take the project “implementing a working design process in a former waterfall driven company” as a problem that need to be solved.

This means that every thing not working just not passed your prototype and you need to iterate, and some ideas can only be tested live.

That’s how it actually feel sometime: You know it will end in a crash but you need to test it.

Taking the whole setting up a UX Team as a project makes it easier to take frustrating meetings, time that felt wasted and first design projects which went completely wrong as a learning and or a prototype that will be improved before the next test. And hey that’s the cool thing about being a UX Designer:

You toggle problems, come up with a first solution as prototype and if it’s not working you just go back to research and adapt your learnings.

The task

Coming back to my story: As you may have noticed in the beginning of my post our UX Team is quite fresh and its only members are me, Business Development Background always interested in problems behind and coming fresh from my half year UX/UI-Training, and my colleague our former UI-Designer who decided to transit to UX. Ah, and last but not least our CEO who wanted to be part of the UX Team as well, since he set it up. You already have the feeling something is could go wrong here? You won’t be disappointed, I promise you!

So the task it self seemed pretty easy: evaluate the current sign-up process of our platform and come up with a new one. Why? Because many we have lot of users coming once and never coming back. Is it really because of the sign-up? We don’t know but we assume this to be set. Part of the task was implicit to perform the first UX Process. Who ever defined what the UX in this company means.

Yes the shifters beyond starting probably to get nervous. Starting the Design process with a solution not with a question!??! AUTSCH. But hey you remember: Someone need to make mistakes that you can learn from (and then do the same by yourself).

First part: Research, Ideating, Prototyping

Let’s start! I was just super exited to try everything I learned at school at a “real project” and see the process working in a working environment and not just in the sheltered class room.

But.. stop! Do you remember our Team constellation? Didn’t you thought that might be going wrong. Let me tell you: It did. So what basically happened was that our CEO presented us as he was used from the waterfall principle his idea, instead of a problem.

And what did we? Of course we brainstormed on this solution. Ignoring the whispering voice in my head, which was saying: Julia! Something is goooing to the wroooooong direction! Of course we had some output of this ideation many variations of the actual solution not more and not less. But we were happy, we felt like we did the first part of the Design Circle.

But hey! At least the next step for us was to prototype. Ok, since we had a UI designer in our team we definitely over performed and used quite realistic designs instead of just wireframes as prototype.

Afterwards we went out asked users to do our click-dummies and here stuff lost control again. We presented our results to the stakeholder who said what he liked to have and we just adapted his assumptions and suggestions to our prototype and presented it quite proud to our Product Managers.

That’s how the meeting with our Product Managers felt like.

Dev Feedback, Business Goal and Sprint Requirements

As you probably already can imaging they weren’t really happy to get presented a complete super complex idea, which was according to us super necessary, needed, want and approved by our users and research.

Result of this meeting was that they asked us why we actually want to change that and what problem we want to toggle with. Now I remembered, you shouldn’t start with the solution, always start with the problem (I just saying HMW questions!). Yeah I know all this stuff but believe me actually sticking to that even if everyone else tells you “we don’t need this, we’ve never did it” is kinda hard.

After this meeting our team sit together and surprise, surprise the next mistake happened: We just saw all the effort we put into this solution, we had our team member who really believed that this is how we can make our users happy and we were already stuck in our process muddle. So without further ado we just came up with a tailor made business goal that toggles exactly our problem and hey how lucky are we, that we already asked the users so we just needed to pick exactly the stuff what was fitting to our assumption.

Basically we were forging our own data just to justify our prototype.

With that in mind we broke our concept down in smaller pieces which were so our thoughts easier doable for the devs in there 2 week sprints. And presented it to the Product Managers again. Probably they hated us latest at this point but they knew that we had the team members with the heaviest vote on our side so they just let us do.

So happy with apparent success we went over to polish the final design and handed the tickets over to the product managers. Who would have guest that there came of course some concerning from the developer side regarding the doability of the UI and we needed a couple more feedback sessions and adjustments.

Now I’m skipping a bit of our weird and never ending process which took us more than two month and was everything else than agile. To be honest in the end neither me nor anyone else really knows why we did what and how.

In the following graphic I tried to show you how the optimal Design Process should work and how our chaotic process went. You see ours is nowhere near to a smooth and round process.

Design Thinking Process vs. Our chaotic process

Launch, more Assumptions and Happy End

For those of you who made it till here and wondering when we tested all the adjustments we made. I didn’t tell you because we didn’t test it. So basically we launched the first requirements without any testing and just assuming that the smaller pieces of our solution will also work without the whole thing.

Launchday! And boooooom! Stakeholder complainings! Fear that that what have been launched could decrease our conversion rate rapidly. STOP. UNDO!

Somewhere we got lost and didn’t get back on the process track and the result was a launch who no one really knew who was responsible for what and a new assumption from stakeholders, with a new presented idea what will solve this.

And sometimes you need to test on live.

So at this point we had to options: We could start another chaotic process like we did before or we could sit together, figure out what went wrong and get everyone finally back on track to the Design Thinking process. And luckily we decided for option two and agreed on that everyone was part of this process, everyone did mistakes and this time we will do it better: We will observe and if there’s a problem with our conversion rate, we will figure out how to solve it — Happy End ( no one got fired) —

Learnings from the broken process

Glad you made it till here (or skipped everything before and just scrolled to the learnings), now you finally get my key learnings from this very broken process:

  1. Trust the process!
  2. Start with a problem, never with the solution
  3. Include the devs from the beginning in your discovery team (they will be happy and you will be happy!)
  4. Don’t forget the user testing after the adjustments, the changes may be no big deal for you but for the users.
  5. Don’t try to come up with a complete project, define your MVP, prototype that and than add stuff after the first launch and iteration
  6. Of course you can forging your own survey results but if you define first a goal, than figure out the problem which holds you back from reaching it and than find a solution, you don’t need to tailor your goals
  7. Don’t fall in love with your idea
  8. The stakeholder should not decide about the final solution, the user and the product team should

Thanks a lot for reading! I can tell you that it’s super hard do make the transition from school to a real company. But hey, even here it’s working for sure if you trust the process! And I’m happy to be in a team I have the option to do exactly this right now. If you wanna follow me on my journey just follow me here on medium. And now im curious: Did you also made similar experiences? Let me know in the comments below.

Disclaimer: Of course that’s just my point of view on this story, since more people wer involved I can’t tell you how they felt during or after this project, so I’m already sorry if any of my team members reading this and is feeling sad about I described his/her actions. I love you all guys ;)

Credits for the Icons in my Graphic (all from thenounproject.com):

julia warmuth

Written by

UX Designerin, glitter fairy, adventurer and always trying hard to keep my head in the clouds — Favourite answer: WHY?

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade