Principle: Get In The Browser

Designed for collaboration in the keyspace.

When to use this Principle

This is a Principle, so is considered as part of the overall approach to making something, rather than a single ceremony or process. Typically, it is agreed to use this principle at the Internal Kick-Off meeting and executed when development starts in the Production phase. But this decision needs to be made according to the project.

Why use this Principle

Working directly in the browser as early as possible means deferring some decisions about design and functionality until all the pieces are in place to build that feature, and then doing it collaboratively. This has several effects:

Collaboration

Collaboration is important because getting more eyes and more brains on things should make better things. Working in the browser fosters a collaborative culture because:

• It helps communication between disciplines since everyone can see things as they are for users
• Being together on the journey helps disciplines make joint decisions about the tradeoffs required for delivery
• It helps everyone work through issues that come up together since the whole team is involved as they come up rather than part of the team feeling like they’ve already finished work
• It helps create more space for developers to make suggestions and improvements, as designs are not ‘signed off’ and locked down by the time developers are thinking about the features
• It helps the development process as designers are creating asset packs

Visibility

It makes sense to work on something as a user would see it. Being able to see a build in the browser is preferable to overseeing it anywhere else because:

• It helps manage everyone’s expectations (the team and the leadership especially): being in the browser together, early, helps people align over the relative importance of features and go on the journey to delivery together, empathising better with the trade-offs required in the delivery
• It helps the client feel more involved and become an advocate since they see and take part in the evolution of the deliverable

Efficiency

Every bit of work that’s done by any discipline is either to experiment, to clarify thinking, or towards the final project deliverable. No more editing copy is huge design packs containing every state of every page.

Examples Of Good Decisions To Make In The Browser:

• Whether user journeys are working as well as they should
• The flow of the page works; instructions, natural travel goes the right way
• Legibility
• Anything with movement or transition
• Accessibility and Usability
• Responsiveness — what happens at different viewports
• Complex features or effects (these usually have technical considerations, i.e. browser support)

Step 1 — Get Aligned

If this approach is going to work, then it needs everyone to be aligned. That includes senior management. So, to do that we need to make that decision as a team during the Internal Kick-Off session. It may be that a Producer asks senior management the question before that session, to get an alignment as we go into it. But no person should leave that Internal Kick-Off being confused as to whether we are executing this approach, or not.

Step 2 — Plan What You Need To Hit It

During the Production Planning play, you will need to define what activities ‘get you into the browser’. At a minimum, you will need a functional build and global styling implemented, as shown above. You may well need more specific features or integrations depending on the complexity of the build.

It’s also still important to do as much user journey and UX work as possible before getting into the browser. Skipping this step and getting into the browser too soon will cause costly changes further down the line. You may also not be able to ‘get into the browser’ in Sprint 2. It all needs to be worked out and planned as a team during the Build Planning.

Step 3 — Include The Time It Needs

If you’re making some decisions in the browser, then the team need time to iterate. It isn’t the same as a basic build process; estimate tasks, build, test, deploy. We need to add in time for refining the build. This can happen:

a) at the end of each Sprint e.g. add 1 day for ‘refinement’ where the designer and developer work together

b) It could be 1 day of time but spread over a sprint and have a designer and developer checking in over the period sporadically

c) it could be an entire Sprint focused on ‘refinement’

This decision needs to be made by the team during the Sprint Planning ceremonies