A query from the NSW Design Community:
My leader says I need to start delivering, but we’re still in the early stages of the project.
How can I “deliver” when we haven’t built anything yet?
Part of the concern here is that you don’t want to manufacture delivery for the sake of appeasing a leader.
Simply creating some type of artefact for the sake of it, (eg. a slide deck) can feel like an unnecessary step and ultimately slow down delivery.
This is all to say… dayum, good question. I don’t really know!
My only thought is around trying to find things that give shared value, (to the team and the leader)
2 Likes
Great question! I recently attended a showcase where a senior leader asked what the end solution would look like, but the team were just nearing the end of the Discovery phase. The team referred back to the ‘process’ (in this case, the double diamond) to align on what could be expected and when.
I think it’s important for teams and their stakeholders to have conversations about what delivering looks like at different stages of the service design process really early on… ‘delivering’ isn’t just about the shiny thing. It also encompasses developing and maintaining a deep understanding of who we’re designing for, and why.
1 Like
The reality of doing any digital work well in government is that you’ll have to advocate for your methodology throughout the project.
Our organisation are big supporters of the NSW Delivery Manual. Something we’ve found helpful with non-delivery stakeholders is starting with alignment on how the deliverables for each phase will feed into the next one, then walking them through both methodology and findings every sprint so they’re more confident in talking about progress with folks outside the team.
2 Likes
Great topic Rich,
I have come across this scenario many times throughout my design career. When you are still in discovery, you’re not in a position to show finished UI, but there are some deliverables you can show to give senior stakeholders confidence. You can do some UI concepts - these will of course be flawed in terms of UX, but sometimes stakeholders want to see something visual - many won’t understand or have the patience for low-fi wireframes. UI concepts are helpful for setting the visual style and tone and design direction for the project.
Another important piece you can show is a User Journey or any research you have done on Personas, helping them understand the problems the project is trying to solve and who the project will help. Good luck Rich!
1 Like
An excellent question! One that continually comes up in Service Design since a lot of what we do is intangible until it needs to be communicated. From my perspective, this is a question of expectation management. I think as designers we forget a couple of key things as we embed ourselves into teams.
-
Not everyone understands what the outputs of design are outside of the key ones like journey maps or wireframes, and it’s up to us to bridge that knowledge gap. Helping the team understand the process but also what smaller things we need to work on to reach those key milestones is a really worthwhile exercise. The reality is, we’re constantly delivering! It’s just that we do it over a series of smaller less defined activities that ultimately inform the big ticket items.
-
Particularly in the early stages of an engagement (like discovery) the design function should be in the driver’s seat. It can be easy to lose sight of the fact that being strategic and shaping the scope is our responsibility. Particularly when the team is still in the ‘forming’ phase. Falling into the trap of fitting into the cadence of agile ceremonies and delivery expectations stifles our ability to be proactive. It’s good to remember that we can and should set expectations and boundaries about what we’re doing, and what we need from the team to get it done.
Unsurprisingly, the best way around this expectation is to ask why. What is the outcome of delivery, what is the expectation around what you’re being asked to deliver? Continually bringing the conversation back to the outcome over the output allows you to work backwards from that expectation and clearly communicate the steps you’re going to need to do to get there.
Hopefully, that gives the design team the space to actually create things that matter, and shares the understanding that everything we do as designers is delivery. Delivering stuff for the sake of it only detracts from that goal.
1 Like
You can show what you intend to do, how it will inform the work, and some of the hypotheses you have.
1 Like