Every now and then there comes a rare opportunity to act as your own client. To experience your own practices, undergo your own process and transcend the border between team member and emptor.
It was this exact experience we underwent when planning the next phase of work on the Arch website - from brief to launch, we followed the path of a client, working across all the usual teams, with the same processes as we would any other project.
In this blog, we’ll explore the first part of our process, scoping and design to give you an idea of how our design process affected the end product.
Part 1: In the beginning
In the beginning, there was just a list, a list that had been slowly growing since we last updated our website. These lists are often where the best ideas start, think of it as a Christmas list… or if you’re like me, your Amazon shopping basket. Full of crazy, fun ideas you feel could improve UX, or better demonstrate our development skills, but haven’t quite had the chance to put into JIRA yet.
Around October 2021, our list had finally reached critical mass, and it became an appropriate time to generate a brief against the development of a new website.
Part 2: Posing the right questions
When undertaking any round of development, it’s important to ask the right questions, to be critical of your ideas and drill down to the core of what it is you’re trying to achieve, and how best to get there.
Upon completion of a few rounds of critical feedback, we arrived at an answer to our initial question, “do we actually need a new website?” - the answer to which was a unanimous “no”. After a few rounds of MOSCOW and coordination with the design and development teams - we distilled our scope down to a couple of high impact style sheet changes, and the creation of a series of new components that would elevate our ability to show off our work.
Part 3: The right amount of flair
Defining a scope that’s based on a strong mix of functionality with a good bit of flare can be a challenge. It’s an element of design practice that is constantly evolving with trends and best practices that can ultimately be the make or break between a website or app that people like to use, and one they love to use.
Based on our newly defined scope, we decided on picking 3 key features that were designed purely to add flair to our website. These were:
Our homepage case study feature listings; by default, they’re required to be eye-catching in order to demonstrate our work, but also an element we’d seen done a myriad of ways by other agencies with a similar offering.
We noticed a trend of making this element of a website a more collective component, designed to be viewed amongst a larger array of featured work. This was the approach we had previously taken, using a component styling based on basic logos/app artwork that was reminiscent of a static, mockup based view.
While this view offered a user a comprehensive understanding of our work in one view on the homepage, it didn’t give us the opportunity to display key functionality in a holistic sense. As such, our design motive for this was to separate out the case studies utilising a featured/not featured function in the CMS.
Taking creative licence from the static mockups we utilise in our case studies, we worked on developing an animated feature component that would present the case studies directly in their appropriate mockup screen (phone or laptop). This allowed us to maximise the realism of our featured work.
Design at wireframe stage
Using Adobe XD, our preferred design programme, we developed a series of mockups, starting with a minimal greyed screen, progressing with the design phase to a final, precise view of the component design.
Featured case study element as live on the Arch website
Our second key component was derived as a follow on from the featured case study component.
We wanted to ensure our case study pages provided a realistic view of how the applications functioned. To do this, we looked directly at how we could best provide the illusion of having downloaded the app, while negating the issues of paywalls. To do this, we developed a component that would come to be internally coined The Slider.
This view, designed to take advantage of mobile views (as proposed to be a key source of website users following a review of our Google Analytics) - sought to emphasise the key skills of our teams in both frontend and backend development.
Mocked up view of the case study slider
As with all of our designs, this progressed into a high fidelity prototype that multiple members of the Arch team could test.
High fidelity prototype in Adobe XD
Once the design of the component had been confirmed by the stakeholding parties at Arch, we moved into the frontend and backend development of it. You can see this in use here: SKIN case study
Part 4: A homogeneous evolution
Once we’d picked out our flare elements, it was time to explore how they could be taken advantage of in a new, homogeneous design. One that obeyed the brand guidelines set out and evidenced in the work of the previous year, but that provided a fresh take on our brand.
One of the key elements we wanted to bring in was a diversified range of colours. Provision for a wider array of colours had been presented in our external documentation sometime beforehand but had not yet made it onto the site.
During a design workshop, the team discussed how we could use a colouring system to define and segment information on the site. To us, one of the best ways this could be implemented was the colour coding of our services. We had previously used iconography to delineate our offering, but the core navy, teal and white colours of the brand we’re always heavily present on the site.
In the new website design, we implemented 6 new colours to differentiate between our service categories to be displayed in a new ‘tile’ format.
Service tiles at mockup stage
Service tiles in the final XD document before being sent to development
The service tiles became a great example of why design processes should be adaptable and malleable from the outset. We discovered from the initial mockups that the page, when shown with linear tile style, left the page feeling slightly prescribed as opposed to one which encouraged scrolling.
We made the decision to offset the order of the tiles, ensuring that our design presented a sense of discovery and exploration as a user continued their scroll. We carried the design language through to the services landing page, utilising the same colour schemes and shapes to provide containerised mini menus of content.
The design language developed in the early stages allowed us to develop a coherent design for the wider site, ensuring each page of the design took credence from the last, creating a user experience that feels fun to use, but maintains order when explored en masse.
This blog is part of a wider series on developing the Arch website, check back in 2 weeks for our next instalment which focuses on the front and back end development phases.