PICCL WEBSITE

Picsolve International

 

November 2015 - September 2016

Desktop website

PROJECT OVERVIEW AND MY ROLE

After investigating Google Analytics on our current released app and website, it was clear that the majority of our user base opted to use the website instead of our old app from 2013 (70%). Therefore we decided to create a new website that reflected the experience of the new Piccl App. This was the first project at Picsolve International that wasn't inherited and I was included in from the start. My role was primarily as a UX Designer with some analyst tasks at the end of the project. The tasks that were given to the digital team, and the design team were as follows:

  • Generate requirements and KPI specification: What was the site to be?

  • Initial sketching of website: Developing a selection of solutions

  • Paper prototyping: This included paper and Axure prototyping after iteration and testing

  • High-fidelity mock ups: This was carried out by our UI Designer, Elena Walton 

  • Google Analytics: I created the specification for the developers 

GENERATING REQUIREMENTS AND KPIS 

Management gave us signficant control over the shaping of the website, and which functions it should include. We didn't want just one or two of us developing the requirements in isolation, so we called a requirement generation workshop with the team. The first take was simple, everyone had post it notes and each person would write a function or concept they believed should be a part of the website. They then stuck these on a tree on the whiteboard, the further out, the less important.

The second half of the workshop consisted of another activity whereby the most important features and concepts were ranked by everyone collectively, and then people gave suggestions on how each feature would be measured, and have a KPI attached to it. It's important to keep in mind that this whole workshop was based on suggestions, making it clear to everyone that the Design team would talk about the results and make an informed decision after the workshop, ensuring we avoided design by committee. 

Image 1.1 Requirements tree created with the whole team

INITIAL SKETCHING

We had the list of requirements we needed, including the ability to view photos, retrieve photos, and make an account. The next stage was to develop some sketches. I always start with sketches on paper or on a whiteboard. I had to do this section alone due to the teams other dedications, so I locked myself in one of the meetings rooms and got to work (see images below) I spent a whole evening coming up with ideas. I then invited the team in to discuss the pros and cons of each of the ideas.

 

About half way through this project two things happened, Firstly Elena Walton, our UI designer, started at the company (thank god!), and secondly, a new emergency requirement come in from management. The company landed a contract with Dubai Parks and Reports (see here) at the start of the year. This contract had now been signed and included a piece of criteria which meant we had to allow payment of photos through our website for Dubai. This wasn't part of the original requirements meeting due to miscommunication from management, down to the digital and design teams. 

image 1.2.1
image 1.2.3
image 1.2.4
image 1.2.2

USER FLOWS 

But have no fear, we are Agile ,which means we adapt to the situation and take control of it. We started sketching again for website payments and how this would fit into the current design. It was at this stage that the UI Designer and myself had taken some General Assembly Classes; one of the small takeaways from this class was that using sharpies over pencils really brings your low-level sketches out more. It seems like a small thing but it really started working and helped us convey ideas much more smoothly to stakeholders, see below for examples. 

We wanted to involve the whole team at this stage of the project so I started on creating a workshop agenda in collaboration with Elena our UI Designer. The concept was simple. We would assemble the team, and sketch what we though the solution for Web Payments should be, as well as general website design. This would be done individually, then critiqued by each person with the team.

The workshop worked well, and even got people talking and opening up with ideas more than usual. It helped us identify issues associated with the logic of the flows, in regards to the payment plan deals management wanted to offer. More importantly it meant that the solution was owned by everyone, and not just the design team. See below for some images of the teams concepts and designs.

image 1.3.5
image 1.3.1
image 1.3.3
image 1.3.4
image 1.3.2

PAPER PROTOTYPING AND USABILITY TESTING (ROUND 1)

From testing the below paper-prototype with people who weren't familiar with the website project , and running the design workshop we were able to identify the following issues:

  • Users were frustrated with the infinite scroll gallery page view we designed

  • Users constantly stressed and vocalised the need to see the price of each plan before it was selected

  • The "My Day" view didn't make sense to users, and most talked about expecting a more traditional album view

1.5.4
1.5.3
1.5.2
1.5.1

AXURE PROTOTYPING

Once we were happy with the pain points identified, we sketched out some solutions and moved onto the next stage, which was an Axure prototype. We chose this as the next stage as we would be hitting two birds with one stone, testing with a higher-fidelity prototype, and having a good platform and document to show to developers which they could use as a reference. Sketches as reference are open to interpretation and could mean the end result is not close to what we imagined it would be.

A clickable web payments buying prototype can be found here: 

http://u5puii.axshare.com/#c=2

image 1.6.1
image 1.6.3
image 1.6.2

USABILITY TESTING (ROUND TWO)

Once we had developed the prototype and decided on a selection of scenarios and "activities" for the trials we were ready to test. We tested seven people as per Jakob Nielsens "Sweet spot" for user testing. In this range (5-8) we can capture 80% of issues, anymore than that and chances are we wouldn't have found more issues. Are main findings from the trials were:

  • Users were satisfied with the design of the gallery, using a album approach was clearly more expected over infinite scroll.

  • Users felt safer as they knew where they were in the process of buying an item.

  • We hadn't accounted for lank state screens, for example when users didn't have any photos what would they see if they viewed the gallery? 

We discussed the above and made sure to make the very small tweaks needed during the next stage, high-fidelity.

HIGH-FIDELITY DESIGNS AND BLANK STATES

Now that we were ready as a UX Design team, our UI Designer Elena Walton took the lead and started to translate the sketched and Axure prototype into a high-fidelity mock up. Meanwhile I met with our developers and showed them the final Axure prototype (which I had tweaked after the final usability trials) to discuss any issues they thought they might have when building it. The few issues that arose were communicated to the UI Designer who tweaked the designs again to accommodate for this. Below you can see a selection of images from this stage of the project.

image 1.7.2
image 1.7.3
image 1.7.4
image 1.7.1

GOOGLE ANALYTICS AND FUTURE OF PROJECT 

Currently I am working on the Google Analytics specification for the website design. I have learnt a lot from doing the spec for the Piccl app. I plan to run a workshop to discuss the website and the tagging with the developers, as a more collaborative approach is needed here. After this we plan to launch in October 2016