Why we Redesigned Meddy?

Haris Aghadi
Meddy Blog
Published in
10 min readFeb 14, 2016

Last month we launched the new design of Meddy. We briefly stated why we did the redesign. Let’s go into more details about the rationale behind it.

Technical Debt

Most of the product was built and launched within 6 weeks. We followed the lean startup methodology and strongly believed in getting the product out in the market in the hands of the customers ASAP. So you can imagine we just hacked most of the product without adhering to DRY code or standard design guidelines. Not to mention my co-founder and I learned Django within those 6 weeks and launched it. You can’t even imagine the level of Noobines to the code. Our programming course professors would literally revoke our degrees had they seen our code 😜

We thought after launching we’ll get feedback from real users and will refactor the code, but you know that never happened. We were picked up by a major local news publisher within 1 week of the launch 🎉We didn’t have any experience building a production app before. Our prior experience building software was for class projects, not to mention barely functional prototypes that we could demo in front our professors to get a good grade 😉

So we had no clue how to handle massive uptake in traffic. Only after giving the interview to the journalist we had our *Holy shit* realization that the website might not be able to handle the surge in traffic. Surprisingly, the journalist put out the story within 1 hour of the interview not giving us enough time to scale up our infrastructure. I remember how scared 🙀I was looking under Real time in GA and seeing thousands of users on the website at the same time. Meanwhile, my co-founder quickly going through AWS and figuring out how to change the size of the instances to manage the traffic. He also had the terminal open with the restart server command typed in, waiting to hit enter, in case we have a 503. I was looking at the signups and patient reviews and this was the first time I got to see real user data! I had never seen real user email addresses and their full names before. This was an extremely fulfilling moment — that a idea we had few weeks ago has now formed into a product and is being used by real users and is helping them solve a problem. Thankfully, we did’t crash and was a really good day🙂

Since then we added more features from the feedback we got from users, got more press, built up the database with the most comprehensive network of doctors in the country — all on that crappy code. We kept doing that for almost 18 months. We never took time away from building something new to taking care of our infrastructure. So as expected, it finally started biting us in the ass. It started taking a really long time to make any changes to the front end without ruining the entire layout, conflicting packages and libraries, responsiveness issues, page load time etc. We had all kinds of technical issues known to startups. I guess, the 6 week hack was no longer sustainable 😅 Honestly, I still can’t believe that 6 week hack lasted us this long.

Cleaning up technical debt was one of the primary reasons behind the new launch. We finally refactored the entire front-end and to great extent the backend as well.

New Content

We started with minimal information on doctors such as their name, specialization, patient reviews and the clinic they worked at.

We then evolved into providing more comprehensive information such as their sub-specialization, scope of practice, medical credentials, treatments, clinic hours etc. All these factors were suggested by our users that they considered before going to a doctor. We collected all that information to help people decide which doctor they want to go to so they don’t have a bad experience.

Unfortunately, we had to fight too much with the current CSS to add any new piece of information on Doctor Profiles. We also didn’t have enough resources to constantly deal with it. As a result, we stopped showing new content but kept collecting the data in the database. We couldn’t keep doing this because from a user perspective we were not adding anything new, more importantly, not giving them what they constantly been asking for. It became imperative for us to give them the information they want on doctors to help them make an informed health decision.

Localized Product

Most of the users on the website thought we are a company based in SF or Dubai and are running it from there and just have a Qatari version of the website. We use Chatra for live chat and we’d constantly get this questions “Are you based in Doha?”This was both good and a bad thing.

Good thing: People thinking we are a startup from SF and Dubai kind of implies that we are that good that this thing cannot be from Qatar. But I kind of get that because we didn’t do the traditional stuff that most websites in Qatar do: overuse of national flag color throughout the website to give a localized feeling, cluttered design with confusing navigation, not responsive, bad support etc. I’m not trying to diss every single website in Qatar, but having been living in Qatar for most of my life I’ve seen and experienced a fare share of them. The other reason behind people thinking we are not from Qatar is also that we don’t have an About us page where we give more background on founders and team for users to know that we are in Qatar.

Bad thing: Thinking we are not from Qatar also implies that they don’t trust the product that much. Because in the past there has been several products who have expanded to Qatar from other countries. Most of them have failed to localize the product properly for people to trust them and get value out of them. So they have developed this reputation of not being that useful and become dormant over time.

So the redesign was a good opportunity for us to localize the product in such a way that it builds trust and compels people to use the product. We did this in few ways and are still working on it:

We created this beautiful illustration of Qatar’s landscape and decided to put that on the homepage, along with using the word “Qatar” in the copy to reiterate this thing is in Qatar! We wanted this to be the first thing people look at it when they land on the homepage.

Meddy Homepage

We also decided to do some traditional press like newspapers to build this mentality that this thing is local. Since most international products expanding to Qatar rarely appear on newspapers. Fortunately, we were featured on the Front Page of a local newspaper that drove a massive brand awareness and lot of doctor leads to the website.

Front page of Qatar Tribune

We are also working on an Arabic version of the website due to the constant demand from a local audience who prefers Arabic. Also, most clinics want the website in Arabic so they can reach the massive Arabic speaking audience. We are also hoping to launch a healthcare blog that features content from doctors within the country. So that we can have local content that is relevant to our audience.

Designing for Flexibility

This needs a post of its own. Designing for flexibility was our biggest challenge. We aggregate information on doctors and create individual profiles for them. We ended up have some doctors with lot of information, some with not so much and some with nothing but their name, specialization and clinic name. Due to this consistency in information, doctor profiles with lot of content looked drastically different compared to the ones with little content. They kind of looked incomplete because of the sheer amount of white space on the profile.

Left to right: Doctor with No reviews & Doctor with Reviews

So we redesigned the doctor profiles in such a way that doctors with less content on the profiles don’t look incomplete.

Left to right: Doctor with lot of reviews and Doctor with no reviews.

Card Layout

We decided to go with card layout for multiple reasons. One of them would be how pervasive them have become. Every good product that I use is using cards. Cards are the future of the web. Every card is a new piece of content that can easily be added and manipulated with. It aligns well with designing for flexibility. Because we have lot of different kinds of content on doctors and cards would easily allow us to show/hide a card if the information is available or not, without ruining the layout or giving it a feel as if something is missing. This was the biggest reason why we loved the cards so much. They are so flexible and seamlessly blend in with the layout.

Cross Browser & Responsive Issues

Based on customer development with did in the early days, most of the customers expressed that they would prefer to use the website on desktop computer because they like to throughly research on doctors, as compared to doing it on their phone. We thought this makes sense because we are targeting a relatively older demographic, age 30+. But we knew mobile was the trend but at the same time we didn’t have the expertise, time or the resources to build a native app and a web app. We only had some basic background building web apps on Rails. So we decided to only build the responsive web app and eventually build a native app in future when we see a strong growth in mobile web traffic. As you can imagine building responsive web apps is a huge pain in the ass due to different browsers, OS and screen sizes. Although, we used Bootstrap’s grid but you always have some screen sizes or browsers where everything goes south. So in those 6 weeks we didn’t get enough time to thoroughly test different screen sizes and browsers. Among our team members we had iPhone 4s and Samsung Android. We tested on both of those devices and it worked fine and on Chrome. We didn’t pay much attention to other browsers and devices.

We were targeting the relatively old demographic. Turned out most of them were browsing the website at work on their office computers. Not to mention those office computers had Windows xp or 7 with IE on it. Yes, IE! I had like a mini heart attack when I saw the usage numbers from IE in GA. They were a considerable number of users coming to the website from IE for us to ignore them.

Key Takeaways

  • It’s more important to get real feedback from users and quickly iterate over the product, rather than spending months perfecting it.
  • Don’t design for now, design for the future. Think about how your product will evolve over time. Anticipate user needs and market trends.
  • Products don’t just need to be functional and beautiful. They also need to entail trust for people to see value in them and make them part of their lives.

This is how the old design looked:

This is how the new design looks:

Doctor Profile & Home Page
Clinic Profile & Doctor Listing

It’s still work in progress. We have a long way to go, we still haven’t fixed all the issues yet.

Soon I’ll be releasing another post on how the new design did.

If you enjoyed this article, please hit recommend. That would be incredible.

You can also read this. It’s an article about what all tools we use at Meddy

Tap the💚 below then follow me on Twitter if you liked this.

--

--

Haris Aghadi
Meddy Blog

Co-founder @ www.meddy.com, obsessed with Healthcare, Product, UX & SEO. @CarnegieMellon Alum. Tweets about VC, Online Marketing & Startups.