Examples of artefacts sitting on the scale of symbolic to practical.
Additionally, artefacts can be divided into two main categories; personal artefacts and shared artefacts.
As creators, we are in a constant cycle of materialising our thoughts – this means getting ideas out of our heads and onto paper. Artefacts provide our thinking with a medium, allowing us to mull over and iterate on an idea, pushing and pulling on it until it becomes something with enough form to share with others.
We also create artefacts to clarify and explain concepts to others, covering everything from project timelines to the technical feasibility of a feature. They serve as communication tools between peers to present our point of view and the trade-offs we are grappling with. Most importantly, they contribute to the shared understanding of the team, which grows as more shared artefacts are created.
Throughout the lifetime of a project, many artefacts are created and shared as part of the product development process. A wireframe is utilised to get consensus on how a user would move through a product, or a component is published on Storybook to get feedback on an animation.
Artefacts are created throughout the lifetime of a project.
Together these artefacts contribute to the team’s overall understanding of the final product, until it reaches its peak at the end of a project. Naturally, this means that artefacts created later will have been created with a greater level of understanding than earlier ones.
Understanding increases over the lifetime of a project.
Later artefacts are created with a greater understanding than earlier ones.
Though an artefact may have represented an accurate view of things when it was created, as the project and the team’s understanding progresses, the accuracy of that artefact diminishes over time until it eventually becomes stale. For some artefacts like project plans, it’s practical to keep them updated, but for others they may have served their purpose as a communication tool and can be left to retire. These retired artefacts still serve as a reference point to an earlier stage of the project.
The accuracy of artefacts diminishes over time.
The above graph reveals a critical limitation of artefacts which is often overlooked. Artefacts can only contain the level of understanding that the creator/s possess at that point in time. This is completely OK but is something to be aware of as sometimes too much weight can be placed on an artefact that has been created at a time when the team had less understanding.
Let’s look at an example. A head of product asks a developer to create a timeline to show how long each stage of the project will take to complete. Based on the current requirements, the developer maps out a 6 month timeline. However, as the project progresses, a new requirement is added and it becomes clear that one of the chosen technologies can’t support this additional feature. The developer tries to pivot to a new technology but the 6 month deadline arrives and the project is not complete. The head of product gets frustrated that the timeline was incorrect.
Let’s take another example. A company has an active design system that is used across their products. A designer uses it to create UI specifications for a new feature, but there’s no available development resource and the UI specifications are put on hold for a few months. Once a developer is ready to pick up the designs, the design system has evolved and some components used in the UI specification are now out of date. The developer gets frustrated that the designs are incorrect.
In both examples there is no wrongdoing by anyone involved. The frustration stems from the belief that artefacts remain as accurate as on the day they were created. However because the accuracy of artefacts diminishes over time, these and similar scenarios are bound to occur if the team isn’t aware of this limitation. An artefact created today will be different to a artefact created tomorrow, simply because we gain more information as time goes on.
Artefacts can sometimes be a seemingly strong foothold in the midst of the unknown nature of product development. However, to avoid frustration we should be wary of putting too much weight on artefacts which are best consumed in the context of evolving understanding. Here are a few strategies to try.
Unlike artefacts, the codebase of the product is being actively worked on throughout its life. Once a product or service starts to be realised in code, shifting the reference point here is a great way to ensure you’re always looking at what’s most up-to-date. This is just one of the many reasons to start building things in code as soon as possible, as it gives the team a great early reference point to see how the product is progressing.
However, code is often not accessible by everyone on the team. Tools like Storybook and TestFlight, can reduce the barrier to entry for non-technical people, and give them a way to interact with the codebase.
From our experience, the less a team stays in-sync, the more artefacts are relied on as a form of communication. Because of this, increasing real-time collaboration and focussing attention on a few key shared artefacts, will help to prevent the creation of too many artefacts that fall out of relevance and become stale.
Additionally, by having representation from different domains engaged and contributing throughout the development of the product, the blind spots in artefacts can be addressed early making them more resistant to diminishing accuracy.
An example of statuses used to communicate the state of a Figma page.
Creating a system that communicates the lifecycle of an artefact is not just useful for collaboration, it’s also useful to warn others when an artefact may have gone stale. This is important because stale artefacts can have unintended consequences if picked up by someone who doesn’t have the current context. By communicating the condition of artefacts with something like a status or creation date, other team members will have an indication on the accuracy level of the information they are looking at.
In this article we’ve explored what an artefact is as well as how understanding its purpose can maximise engagement from an audience. We’ve also looked at the lifecycle of an artefact and how its accuracy naturally diminishes over time unless its maintained. We’ve discussed the key shortcoming of artefacts which is that they can only contain the level of understanding that the creator(s) possess at that point in time and worked through some scenarios where this limitation can result in frustration from team members. Finally, we’ve looked at some strategies to reduce the reliance on artefacts as well as ideas for communicating the diminishing accuracy and reduce the likelihood of these frustrations occurring.
Hopefully this article has provided a renewed respect for the role that artefacts play and how they can be utilised in projects today and in the future.
* The idea for the symbolic to practical artefact categorisation came from the article The Importance Of An Artifact In The Software Development Process by GN. It was remixed and turned into a scale for this article.
talk
article
· 7 min readarticle
· 1 min readarticle
· 4 min readarticle
· 3 min readarticle
· 8 min readHave a chat with one of our co-founders, Jed or Boris, about how Thinkmill can support your organisation’s software ambitions.
Contact us