After getting through our first sprint we have now completed our second and last sprint of the prototype design phase of our full redesign of Piccalilli.
A reminder of the Set Studio process we are following in this series View full size
We’ve done the first sprint, so it’s time to move on to the next one. This is where we get into a lot more detail with the design and expand on what we’ve already got, mostly in the browser.
We had good page concepts but we need a home pagepermalink
Designing a homepage after other stuff? It’ll never catch on. Sure in a lot of projects, starting with the homepage spiders the rest of the design process really well, but in this context, the reading experience is the core of our design, so it makes sense to focus our early — and generally higher — energy levels on that.
With us nailing that (trust me, wait until you see it), we can confidently tackle the beast and the milestone at the most risk of stakeholder inference: the home page.
After deciding on the priority of content in the first design sprint, along with already getting a design system — of sorts — in place, we can get into — and back out of — Figma pretty damn quickly.
There’s two concepts here. One is a future homepage (left) and a version of the homepage that we’re going to ship in this initial iteration of the redesign. We’re not shooting for perfection at this point, more, we want to get ideas on to a page composition to see how it flows at a macro level.
The only discernible difference between the two concepts is that the future homepage will have a more expressive hero unit, which we will commission a trusted illustrator to work on, along with a primary action to see our courses. The first of which launches later in the year.
As you can see, a lot of the existing affordances, well, navigation is the same as the current homepage. That’s what homepages are at the end of the day: navigation pages.
What we have added though is the latest three articles, a tab panel for the popular content so you can see what’s currently popular and what articles have been the most popular over time. The hope is that if someone who has never read a Piccalilli article will be able to get a good vibe of the content that has resonated with readers. Later down the page, we’ve added a sign up section to encourage folks to either get new articles in their inbox or subscribe with the favourite RSS reader.
Looking pretty snazzy huh? That’s the prototype by the way because of course, we smashed that out with junk CSS, just like we did with the rest of the prototypes in the first sprint.
Iterating based on how things feel in the browserpermalink
In the first design sprint, the aritcle page template looked as follows:
In this version we had the information about the author in a left-hand column and the prose of the article in the right-hand column. In a more macro view in Figma, this worked really quite well because the overall grid system felt balanced. The problem with websites is you never see the whole page in your viewport. In fact, we have no idea what viewport we’re going to be met with.
When we got the post page layout in the browser, it became pretty clear that the reading experience wasn’t up the the standard we were aiming for.
Having the content pushed out to the right looks really awkward when there’s nothing else in the sidebar. We definitely don’t want to be distracting readers with docked elements either!
It’s at this point where you have to step back and really work out what the problem is and start to play with ideas. The idea that stuck for us was both, putting the sidebar on the right-hand side and also, increasing the font size of the prose. Again, the typography felt balanced in Figma, but once we got it into the browser, we were less confident of that.
The updated prototype made us much happier. Sure we’re working with pretty junk content here — it’s just an excerpt from an existing article. We’re going to get into the details of the prose design implementation during production because there are thousands of content combinations in the website’s content, so we’ll be much more efficient working with real content than faked content at that point.
The main thing is that iteration transformed the reading experience which is what we needed to get done at this point.
Finding issues and iterate on thempermalink
The benefit of junk CSS is we can find fragilities that we need to account for in production code. We can also find potential accessibility issues and oh boy, we found one of those 😅
Let’s zoom in on the full-blooded version of the website header for sec:
The header looks good, but it’s pretty complex in its nature. There’s a lot of layout going on and yep, we opted for CSS Grid to give us the level of control we needed — especially responsively.
The problem we found — and as the video shows — was because of the ordering of content at a HTML level conflicting with the visual layout, we accidentally broke visual tab ordering which is an absolute no for us.
In this situation, it makes sense to completely rip the header apart, find what it is about our initial design that is causing problems then prototype a solution. That’s exactly what we did.
The problem at hand was we were grouping buttons on smaller viewports and visually separating them on larger viewports. We had to ditch that idea and maintain the grouping on all viewports instead which in hindsight was a better idea anyway. That’s the thing with approaching design in an iterative manner: you find these issues and are already in the right mindset to deal with them efficiently and effectively.
Analysing how the design will work in the real world and tightening things uppermalink
The last issue we faced to wrap up this sprint was elements that break out of the post layout’s column system. For example we have a component called a Preview Frame. This is an <iframe> that shows a real web page. It also has an affordance for you to resize the frame to see the page’s responsive adjustments. We use them a lot in topics like Reality Check.
Looks pretty good already, right? Sure does! But one of the downsides of writing junk code for prototypes is you tend to follow the happier path, as it were. In important part of these design sprints is to go back through the prototypes and make sure everything is going to work with the real life website.
The way we’d built the post layout didn’t quite match what the real production environment would get us. Essentially, we’d closed one sidebar layout, rendered the preview frame and then opened another sidebar layout with the content that followed. Again, this feels totally doable, but we don’t want to be introducing complex platform code in Astro to handle that situation. Complexity brings fragility with it, which we don’t want.
See the Pen The super rough layout test we put together by piccalilli (@piccalilli) on CodePen.
We needed to account for the break out element — our Preview Frame — to be a part of the content that resides in the left hand column. A really efficient way of working that out is to get away from the prototype and spin up an even simpler prototype like the CodePen above. Sure that thing looks like absolute garbage, but what it did do is help us calculate the simplest possible to the solution at hand.
We opted to keep using the Every Layout Sidebar, but enhanced its usage in the post layout with container units, z-index and container queries to both apply the border to the correct side, based on whether the sidebar had stacked or not, and also use the container units now available to us to size and stack the breakout elements efficiently. I’ll write up about that some more in another post.
We would have had to deal with this problem in production without our approach to design which would have caused a massive, rather stressful disruption. Designing actual web pages rather than pictures of them is hella useful.
Getting ready for production and wrapping up this sprintpermalink
With the prototypes wrapped up, the design sprint is now complete. We’ve got all the assets ready like premium fonts and also got our design documentation tightened up.
It’s all about planning at this point. We break the implementation of the design into two distinct parts. One part is a HTML-only build and the other is UI development. I’ll cover this in the next part of this article series
For us, it’s all about building a backlog of tasks in Notion and distributing them. With the backlog ready, we are now ready to build a real website!
If you like what you see already about this process and are looking for an agency partner, get in touch. We’d love to speak to you.
