Blockchain Ticketing Solution
Blockchain UX, DevX, Enterprise Software and B2C Apps
I joined the company when it was in it's infancy, under a year old, and took the exciting opportunity to be the UX Designer in a team of 15 developers. Artos is a blockchain startup that is the commercial arm of Aventus,
which raised a large amount of funding through an ICO with the mission to make ticketing fair for the attendees who are often forced to pay extortionate inflated prices for sold out tickets.
The company's core product is the Aventus protocol, which is a blockchain platform for creating events and tickets. The protocol gives event organisers more control over their tickets through the supply chain and valuable Business Intelligence. On top of the protocol, Artos is building SDKs, Enterprise Software and Apps for clients and third parties.
As a designer, the blockchain posed a fascinating problem space. How do users feel about blockchain? To what extent should we expose the blockchain to the user? What benefits can the blockchain bring?
How Might We deliver a B2B ticketing solution to ticket operators? How Might We send these tickets to the end user? What would that experience feel like?
Design Systems, Interaction Design, DevX, Git Workflow, Scrum, Stakeholder Management
Project Duration: 1 year
Designing for Emerging Technologies
Ticket Wallet App
Access Control App
At the start of my employment, the startup wasn't even one year old. There were still a lot of questions about the direction of the company and what the product would be. At the time, the UX of Blockchain was a topic of a lot of discussion. Users were complaining about the difficulty in navigating exchanges and purchasing cryptocurrency, and the steep learning curve regarding private keys and wallets.
The question we kept on asking was, to what extent should the blockchain be visible to the user? To what extent do we discuss and mention it?
Due to the nature of the new technology, it was difficult to conduct primary research. There weren't many products in the space to analyse, and few people who used the blockchain. My initial research was based on DevCon IV in Prague, an Ethereum Foundation conference, and various community forums with other designers.
The result was a large amount of secondary research as the basis for the first iteration of product development.
Designing for Emerging Technologies
conducted as part of a talk I gave sums up the attitude towards blockchain as of mid 2018. There was a lot of frustration around the usability issues of the new technology, and lots of clever people trying to abstract away all of the unnecessary technological jargon.
One of the problems we identified was a lack of understanding around blockchain. In order to address this, we prototyped a block explorer
that would allow users to visualise the data going through the protocol and explain how it works.
The purpose of the usability test was to meet the following two goals:
To empathise with users about their understanding of the technology and the extent to which they will want or need to understand it.
To find the most effective way to explain the technology in order to impart the desired message most effectively (confidence in our services as clever, stable and reliable).
It's really cool - It would be cool to have a visual aspect. People say blockchain but it's all code and scary for the user. Having this conveys where your ticket sits in the grand scheme of things. It's quite cool to see.
Ahhh, ok that is cool, they're like little leaves. I like being able to see the ticket-ID, I'm not sure what that means but it seems unique to me.
It was interesting, I don’t understand it but I have a glimpse into how it works.
It would be better if it had a banner that said 'Learn more about blockchain here'
The results showed that all users really enjoyed the interactivity of the tree as a concept. Users like the idea of having a ticket that is unique to them and being able to verify it via the Ticket Wallet app.
Users wanted to learn more about ‘blockchain’ in general, but did not understand the explanation provided.
In the end an executive level decision was made to abstract away the blockchain from the entire user experience. This is because the research showed that while people were interested in blockchain and wanted to know more, there was simply too much to explain for it to provide any benefit for the user.
One poignant analogy sums it up perfectly.
"If you went to a website and it tried to explain to you how the internet worked, you would not be happy".
In the same way, a service built on blockchain does not need to explain blockchain for it to deliver the desired value to the user.
As the core product of the company is the SDK, the Developer Experience became an important topic for the company. For developers to know how to navigate the API, there needed to be effective documentation. A large body of work I conducted revolved around how developers perceived documentation and what their needs, wants and pain points were. I interviewed 6 developers about their experiences with API docs in order to understand their needs, wants and frustrations. The resulting artefacts were then used to inform the next iteration of the documentation, which featured many of the opportunities identified in the Empathy Map below.
User Persona & Empathy Map
The ongoing DevX work continues to surprise me with how interesting it is, and I can see this developing to become a more important field in the future as technologies become more complex and require additional APIs.
Manage Events Tickets and Links - METaL
METaL is one of the core front end UIs for Artos. It is a B2B enterprise software for creating events on the blockchain, creating tickets to those events and sending them to customers. It also needed to be able to scale to be able to handle various other facets of event management, such as engagement, add-ons, vouchers, seating and an amazing number of edge cases I had never considered.
It started life as an extremely basic UI
for interacting with the protocol. As it's use became apparent, there was a need to expand its functionality and design.
The final build based on this design
is ongoing, and is being built using React.
In it's first instance, the UI required very few features. As Enterprise Software, though, the design of METaL needed to be able to scale and be flexible for future features and requirements as the company develops.
To achieve this, the design was first considered at great length to reduce the number of components required to a minimum and in a way that creates space for the product to grow into the UI.
I wanted to create a design system that would result in intuitive enterprise software that is scalable and uses simple, reusable components.
It was really beneficial to work through the details of the design system with developers. Through a back and forth between Sketch and React, we were able to create a system that established a common language between Design and Development.
Once the design system was in place, it enabled really effective communication with developers. User stories could be broken down into 'Recipe Cards', seen below, which dissect the required work using the design system and atomic theory:
METaL distributes tickets to users via ticket wallet apps. the Ticket Wallet app has gone through many iterations for many different use cases, starting life as a simple user flow, then becoming a white-label app, and then running through several designs for clients that I cannot disclose here.
The Ticket Wallet was an ideal case for me to explore interaction design, as it's scope is very clearly defined and narrow enough to allow a lot of exploration into different ways of presenting the QR code to the user.
Below are some of the wireframes completed when considering the Ticket Wallet. Initial designs were skeuomorphic, with ticket shapes being used and stacked on top of each other to indicate the quantity of tickets (see right image). While ticket SVG shapes are intuitive, they require a lot of padding in the UI and can be really frustrating to implement as a developer. After many iterations, I came to the conclusion that the best solution was one that was digitally native and made the best use of the available space.
Below is a recording of a prototype created in Principle. For this design I was focusing on the idea of continuity between screens, which brings context and value to the User Experience. At no point do you need to explain to the user where they are, because via the interaction they can see where they have come from.
The above prototype formed the basis for the development work. It was fascinating working with developers on this, specifically because of the constraints of the code. The below build was made using the React Native Animation library and required some compromises in the design. For example, when you first enter the event page, we found it difficult to scroll to the QR code and scale the event image without a serious drop in performance.
The solution was to put the QR code behind a 'Tickets' button and make the event image become the header of the screen. Not only does this provide the desired continuity, but it also feels cleaner.
The Access Control app
would be implemented at the door of the venue for scanning tickets and required a simple feedback system to the operator to tell them whether the ticket was valid or not.
Outcome & Reflection
The biggest challenge of the role has been selling the value of design in a company where I am the only designer. For every product I had to push really hard to get any usability testing done, and even then it required a lot of compromise. It's difficult to assess the quality of your work when you have nobody to critique it.
On the other hand, I've learnt so much from the team of developers I am with. I've been able to dive into React, Typescript, Styled Components and so much more. I've learnt how to use their suite of tools and am now capable of contributing Pull Requests to the code base for any UI tweaks such as copy, colour and basic layout. I've learnt the value of the Scrum methodology and have a healthy appreciation for retrospectives and physical scrumboards.
It's also been amazing to see my designs come to life in code. The process of solving problems as they arise has given me a new appreciation for designs that are not only beautiful but also easy to implement and I will take that forward in all my work in the future.