Keep your project objectives visible
Projects often go off target. Teams are so intrenched in the current iteration that they forget to refer back to the objectives. Forget to make sure that what is being designed meets the goals/direction that was originally set. Keeping objectives visible and referring back to them regularly is a key component for a successful delivery.
the kick off
It’s the kick off meeting, all parties join together to discuss the upcoming project, there’s excitement, enthusiasm, energy. Powerful statements get thrown around like “we want to be bold”, “Fresh” and be “seen as one of the leaders in our industry”. And who doesn’t? When developing a new product or refreshing an existing one, it’s important to set the bar high and reach for the skies. It provides essential fuel to the beginning of a project and rallies everyone involved to go and create something brilliant.
As time goes on and the project continues, challenges arise, ideas get pushed into “Phase two” and all these little issues start chipping away at the great vision we had at the beginning. Without perhaps noticing, the bar gets set lower and lower until the final outcome, however good, is not bold or fresh and certainly doesn’t lead.
Stephen Anderson gave an inspiring talk at UX London 2015 about the dangers of the development process sacrificing quality or design. He describes setting the bar to what is “good enough” and what does it look like. With each passing year, new techniques and technologies are allowing us to create better experiences on the web and with each year that bar is raised.
So what does “good enough” look like today? How can we have a clear and shared understanding of where the bar is set and how do we make sure that we don’t loose the details that made the project great?
How can we get a shared understanding of the bar?
Through collaboration, agreement and visibility.
So let’s go back to the beginning, back to that time of excitement and aspirations. This is when everyone involved needs to identify and agree what the “good enough” benchmark is and whether we’re aiming to merely reach it or smash through it?
Does this benchmark align with the project objectives? Ideally this would have been done prior to creating any objectives, however in my experience this is not always the case, so at this point it’s worth comparing them together and make sure they align, if not it’s worth updating the objectives.
Once everyone is in agreement, we need examples of existing products or sites currently leading in this space. Get them and our objectives printed out, placed on a wall, visible to all stakeholders and practitioners. This will allow us to compare any decisions made against our objectives and aspirations, furthermore they act as a reminder of the quality space that we’re aiming for.
It is also important to replay the project objectives at every playback or sprint review meeting and check that everyone is still in agreement that they are true. This is important for two reasons:
- It frames the meeting well, getting all involved thinking about the project and it’s outcomes.
- If conversations happen outside of the project which affect the objectives, we need to know about them asap and this offers the client the opportunity to surface them.
How do we make sure that we don’t loose details and let the bar slip?
Repeating and surfacing objectives is great at a project level but how does this relate to detail work? To me, the designer, when I’m focussed on small complex interactions? Actually the same technique can be and should be applied at every level of the design. All you have to do is create section or page specific objectives for each level of detail or “detailed objectives”.
I know this sounds a little like inception but trust me it’s actually quite simple.
High level objectives set the scene and can guide a general direction, but this can leave the design open and subject to interpretation. And it’s this that can cause conflict and gaps in understanding. If we create a set of objectives that are specific to that level of design e.g. a page level, then we get a unified agreement on those objectives prior to any design and hopefully reduce the chance of misunderstandings.
There are many ways to create detailed objectives and choose whatever works for you, in the context of this post I like to frame them around three categories:
- Functional objectives: What are the key tasks the user has to perform for this page to be a success?
- Aspirational objectives: What is the quality or experience we want for our users?
- Brand Objectives: What are the key elements to make this page feel like it’s part of the brand
Let’s get practical and take a product page for example, our functional objectives could be something like:
- Allow related products to be added to the basket directly from this page
- Users must read the guideline text, prior to any buying path
- Users must understand that there is a choice in the product and make an appropriate selection
Our Aspirational objectives may look like:
- Hero the imagery, large and high quality photography
- Use animation/show movement where possible
- Focus on activity over the product
And finally our Brand objectives might be:
- Reflect the light and fun nature of the brand
- Web fonts are essential to reflect the typography of the brand
- The brand’s is about helping people make the right choice not about volume of unwanted sales
As designers we should by now have a good understanding of the global aspirations of the project (The Bar), we know the project level objectives and we now have some detailed (page-level) ones. This is hugely powerful as this will frame any future conversations around design.
Back to our playback. We’ve done the project intro, checked our overall objectives and it’s now time to review our product page design. Before showing anyone any visual designs, we should, once more, make the page level objectives visible, even run through them again, explaining that the forthcoming designs should hopefully tick all the objectives listed out.
I used to hate the stupid questions and statements like “there’s not enough umph” or my personal favourite “where is the fold?”, sentences which would make me tense up ready to do a Tasmanian Devil-like tornado through the room. However they are not stupid sentences, they are simply comments made by people who are not design literate and we need to learn to facilitate these conversations and help those people articulate their thoughts.
I must caveat that 1 in 500 is probably stupid, doesn't know what they're talking about and there’s not much you can do about it.
So when we get a “stupid question” around the design, which doesn’t offer any value, we can try and identify where the problem lies by reviewing our page-level objectives:
- Aspirations: Does the design meet the quality we are aiming for?
- Objectives: Does the design meet the objectives set?
- Brand: Does the design reflect the brand correctly (colour, tone of voice etc)?
Providing that we haven’t got it totally wrong we can quickly identify what area of the design is lacking and amend it appropriately. Moreover as these categories were created with the client it also places the onus on them. If we’re confident that the designs meets all the criteria outlined, and there is still something wrong, then it is time to question the objectives and places the discussion in their court. This is great as it allows us to back up our design decisions based on their objectives, demonstrates the value you bring to the project and it also means that both parties take ownership of the design.
Wrapping it up
We’ve set the bar and have a unified understanding what we’re aspiring to create. We have visibility of the project objectives and have created any detailed objectives required.
By constantly replaying these objectives at every playback, you can ensure that gaps in thinking aren’t created and everyone is working towards the same goal. Constant visibility of the bar establishes the quality that we’re aiming for. The detailed objectives help to frame difficult questions and allow you to help people articulate their concerns, giving you actionable feedback to move the design forward.