Techniques : User Research , Rapid Prototype , Sketching ,Usability testing
Date March 2018
I was drafted in to help consult on the ORS group with their up and coming ICO webpage. ORS GROUP are a leading Artificial Intelligence software company which is connecting A.I. and Blockchain through their new product, the Hypersmart Contracts (“HSC”) provides access to more than 1,000 proprietary algorithms and hundreds of software solutions to the Crypto Community and to established businesses.
They envision a planetary network of entrepreneurs and independent companies empowered by the new digital alphabet:
ABC – Artificial Intelligence, Blockchain and Cryptocurrency.
The concept for any ICO, is to sell their product in the most effective manner possible. The ICO website is a marketing and sales tool for their product which is the main function of this page within the ICO. The token sale however, to get to the point of sale every ICO page must contain the following information elements to attract their investors.
- Detailed information on the product
- Enhance the advertising effect of the project
- Create interest and an urge for learning and seeking more information about the concept of the project.
The landing page can be divided into two key parts;
The first screen should be designed to attract the interest of any newcomer.
The second section of the site is dedicated to providing the user with all the relevant information on the project as a potential investor.
I was asked to sit in on a meeting with the ORS CEO, the CEO explained that his developer had been struggling with building of the ICO webpage. Also, to make the situation more critical the project would be entering in to the second phase, which is a public sales phase of the token.
Therefore, the ICO side needed to be fully tested and functional within an extremely short amount of time.
- I needed to understand where the site was from a development stage
- Get an understanding of where the developer is struggling
- Review the landing page and see what issues are forthcoming
- Time limitations
One of the biggest obstacles we had to overcome was that the developer and ourselves had a language barrier to overcome. Which made conveying ideas on occasion extremely hard.
The CEO decided, to replace the original developer and bring in a fresh pair of eyes.
Furthermore, the landing page was in the beta phase. I was instructed that I would have three weeks to offer my recommendations.
There would be no budget for any exterior user testing.
I wanted to familiarise myself with the ICO page, this enabled me to investigate any problematic areas of the site. I noticed that there was lots of functionality regarding buttons, on the landing page I think I counted 19 in all, this gave the user an exceptional amount of choice to make.
Also, the White Paper button didn’t really stand out and just seemed to blend into the background of the landing page.
Furthermore, the site’s content was designed to be in multiple languages, I struggled to find a button to facilitate changing of language if needed.
As there was no room in the budget for any outsourcing of user testing, to facilitate a quick turnaround, I enlisted some in-house senior UX designers to conduct reviews on the landing page.
Focus and prioritize
To further expedite the start of the evaluation, I decided that it would be a prudent idea to focus and prioritise certain areas of the landing page. My reasoning for this is you should prioritise all the issues that you will present to the client. Making a note of all the small usability issues can add up and influence how a user feels about the product in a negative way and can cause a reverse of the halo effect. However, it is also an extremely bad idea to supply the client with an extensively long list of issues that they need to overcome
Upon the conclusion of the expert review of the landing page, my team and I collated the data from my individual tasks and discussed our findings.
The next step was to prioritise all the issues we had come across. My main concern was that I did not want to overwhelm the development team with long ambiguous lists.
The simplest solution to this problem, was to create a ranking system. Each issue will have a number that will correlate with the table you see below. Prior to this report being sent to the developer we will have had a discussion and already apprised them of how the ranking system works its extremely straightforward and it gives the developer the freedom to pick and choose the severity or urgency of the issues at hand that need to be addressed.
- 0 = Not a usability problem at all
- 1 = Cosmetic problem only—Such an issue need not be fixed unless sufficient time is available on a project.
- 2 = Minor usability problem—This is a low-priority issue that is less important to fix.
- 3 = Major usability problem—This is a high-priority issue that it is important to fix.
- 4 = Usability catastrophe—It is imperative to fix such an issue before releasing a product.
Rapid Prototype and Sketches Mocks up
To combat the time issue, I employed the methodology of rapid prototyping as this was a quick and efficient method of helping the developer visualise our solutions. By doing this process we will get instant feedback and make appropriate changes. As time was of the essence, I started with rudimentary sketches and then I made some basic prototypes.
Access to my prototype
The team’s recommendations for the ICO site, the first recommendation was based on the amount of information that the user had been confronted with. As soon as they entered the landing page, the user was overloaded with images and information.
To combat this issue, I applied the concept of Hick’s law, Hick’s Law (or the Hick-Hyman Law) is named after a British and an American psychologist team of William Edmund Hick and Ray Hyman. In 1952, this pair set out to examine the relationship between the number of stimuli present and an individual’s reaction time to any given stimulus. As you would expect, the more stimuli to choose from, the longer it takes the user to make a decision on which one to interact with. Users bombarded with choices have to take time to interpret and decide, giving them work they don’t want.
Due to the fact, that the ideology behind the ICO website was to attract clients to purchase tokens, if the user is overwhelmed with information is highly unlikely that they would carry on with this process. The overall sinking was to simplify, the amount of information that was on the home page. My thinking at the time was to move all the media taps into a simple media drop-down on the right-hand side.
The second recommendation was to the fact that the most important piece of information on ICO webpages is the White Paper. As the White Paper contains, all the relevant information that the user will require to understand the product they were going to invest in. From our extensive use of the landing page the White Paper button simply blended in to the background of the landing page. Therefore,
Any user would likely ignore the button and move on without retrieving the right amount of information. Thus, in turn could cause a failed sale of tokens, due to lack of information. To rectify this issue, I simply would emphasise the White Paper button in a different colour and make it larger, so it would attract the user.
The third recommendation, most ICO webpages are generally a carbon copy of one another. The fundamental problem I found with the ORS group, was the fact that they were missing a countdown timer. This mechanism is used to entice potential investors in the token. Therefore, I put my recommendation for the entire match should be installed onto the homepage.
From what I understand, the client ran some basic usability testing in-house, which I was not involved in therefore I cannot really comment on the outcome.
I was very pleased that we managed to supply our clients with recommendations in such a short period of time. The overall results of the ICO, were a financial success and the company reached their financial goal required for this specific project.
One of the biggest challenges, I had to face was trying to convince certain members on the client side to use some of our recommendations. Also overcoming the language barrier which on occasion caused a few glitches here and there.
What would I do differently next time
Unfortunately, due to budget restrictions the client was not really in a position to spend money on UX research beyond the evaluation stage. I felt that if I had more time with the client maybe I could convince them that there could have been better solutions to individual problems
If I was to do the project over again, knowing what I know now. I would have focused on more communication with the developer and try and have more conference calls and give them better support.
Furthermore, I would have liked to have come into the project before the beta version was developed, this I think would have circumvented some of the issues that were presented.