How to do Agile Redesign Or How to avoid becoming Iran Talent
Last year Iran Talent (Iranian’s Glassdoor) website changed its user interface after so many years. The new website is not as good as the old version as in technical aspects or user experience. I’m about to discuss the process that Iran Talent has probably been through. I will also suggest some approaches for similar cases.
TL; DR: Avoid redesigning the whole product. Find the weakest part that can be fixed with the least effort, fix it and repeat this process. Repeat it until end of the world.
What you were
You are a company which your product has been pioneer in the market in recent years and have had no other competitors. Since the products website was first built in the Web 2.0 era, its design elements are clearly very basic. You gather a big user base over the years and user interactions on your website have provided you with lots of user information (such as their resumes, preferences and so on). Given that all these years there hasn’t been any significant or major change in your user experience, your technical team (or product team) is probably not working on your product. The current product has no major issues (probable due to the number of the users), meanwhile the website possibly lacks the ability of implementing its managers ideas. While the user has no better choice other than your website, why would you change anything?
What you want to be
Your company has gotten accustomed to having users all the time. Though User Testing is not your choice, you are more comfortable with third-party companies for market research. But little by little the online business market grows and therefore you are faced with some serious competition, some of them have even gotten the better of you. You are getting concerned; your brilliant ideas are not being implied and they just go to waste. Your technical team is far behind other competitors. That’s where you decide redesigning the whole website is the answer. In other words let’s throw the whole thing away and replace it with a over the edge technology website.
What you became
You have two choices: your team does the redesign or outsource the project. If you’ve outsourced the project, then stop now and think about that even after ten years you are not capable of working on your own product. If you choose the first way, then you’ll probably start it with UI design. Then you’ll try to adjust the user data that you’ve gained through the user flow of the old website with the design. Also your technical team wants to implement the whole thing with some new SPA framework, React maybe?.
Months after starting the project, the only result you have seen as a manager are few pictures and sketches of some pages of the website. Probably due to the difficulties of importing the old data to the new website, the project has been delayed several times. Finally after a lot of delays and with expectations getting higher, the first version is presented. No one other than the technical team is pleased but since you have invested a lot on this project, you decide that the website is ready to be launched, after fixing obvious UI issues. Company expectations for the new website are so high that launching the project becomes the number one priority for your company. Finally you launch and you receive nothing but unpleasing feedbacks from users.
what to do now?
You’ve launched a website with a lot of technical and UI issues, you’ve spent a lot on the project and the team, and thus you have no other choice. You add a questionnaire to the website and ask the users to share their ideas about the problems they are experiencing on the website. On the other hand you are obliged to hire more nontechnical personnel to support your users.
Flash forward 3 years in the future, you are right where you started. The only difference is that you have far less users than before and you are definitely thinking of another redesign.
Suggestions for similar cases
What is the best solution for the case described before? Let’s assume redesigning is your best chance (which I strongly disagree). The codes from the previous version cannot be developed, your head developers who had the technical knowledge of the product are no longer with you. Or else your product was supported by a third-party company which no longer exists.
- Form a team with at least three members: First, the one who knows the business needs of the next 6 months or even a year. Second, the one who knows your current clients and monitors user activity on daily basis and is comfortable with interviewing users. The other one has to be familiar with the technical issues of your business over the years and knows your setbacks in the past.
- The mission of these three will be creating a mutual image of the product you are going to create. Needs and abilities help build this image, not the conversations between CEO and a member of this team. Even if at the end the decision is to create the exact same product with the same UX but different technology, then be it.
- After creating the image, a deadline for the first launch has to be set. It’s better it doesn’t take more than 4 weeks. The first outcome is expected to be launched within 4 weeks, not the new product (see the next point). After that all the teams have to be informed about the new picture, the reason behind creating the new product and the first deadline.
- In this period two things had to be done: A. Developing the infrastructures and creating a team for the new product. B. Choosing the first feature or part of the new product that can be launched and work simultaneous with the old product or even replace a part of it. It can be as easy as updating the font.
The deliverable here is not important yet, the important part is to form the team and have the first changes on the production.
- During these sprints (2/3/4 four weeks periods) some criteria for measuring the rate of success have to be chosen and the team has to review them. For example if you are monitoring the bonus rate in old website and the new one, you must know how the new change will affect these criteria as well.
- This is where you fall into a loop that could last forever: Find another part of the old product that can be replaced, replaced it, check if this replacement has been successful. When the change works then you’ll choose another part for replacing. You repeat this process until the old website is completely replaced with the new one.
- Repeat this process for the new product several times: Find the worst part of the user experience that can be fixed and wouldn’t cost you much. Update it and check if the changed has worked.
- The new product is guaranteed, even more than the previous one, since it has been tested, monitored and improved with live users.
- The team will get use to constant changes and no one would be looking for any major or unknown steps anymore.
- The managers and the company will see changes and constant improvements as the solution from now on and will be aware of the cost of adding each feature.
- Measure for success would be the success of the user experience, you have the number, you know how to change it.
I have no information on the internal process and the situations that led to Iran Talents redesign. I tried to guess; therefore it’s possible that another chain of events had caused this redesign. I hope this post is helpful to Iran Talent or any other similar company.
PS.1: I wrote this article one year ago. Since then they’ve updated their product regularly. Well done on that.
PS.2: Some of my friends mentioned that this solution is not going to work for complex situations. While they might be right, here I try to draw a path on how to be an agile organization by emphasizing on teams, deliverables, using real data and getting feedback in a short time. It doesn’t matter what path you choose, as long as you have the feedback loop with autonomous teams to learn and build, you are on the right path.