0

My question is a bit unique. Here's some background:

My team started off with designs that were dropped into our lap. We didn't get any journeys, no stories and no annotations on the design. We barely got a working prototype of how the app should flow.

Now, I'm responsible for writing the user stories and journeys. We're halfway through the project - i only got involved a short while ago. A lot has been developed already (from mocks on zeplin).
During planning, there were things that got updated (tech functionalities aren't allowing for some of the design proposals).

My question is, what should the single source of truth for an app be? Should it be the mockups (that are updated to reflect the outcome of these plannings?), or should it be the stories/journeys? Do you still maintain that stories & journeys should be the SSOT even if the stories didn't cover what was already developed?

Additionally, WHEN it is expected that the designs need to be updated? Keep in mind, that the design was dropped into our laps by a designer that left the company.

  • The SSOT should be what the team agrees on. By default these are generally some form of a specifications document, but it really depends on the type of project and process that you apply to deliver the service/product. – Michael Lai Jul 20 '17 at 23:45
2

We solve this problem with a 'Spec'

The Spec, or Specifications Document, is the answer to the question "Where is the one place I should look in order to understand everything about this project?"

We include layout, interaction design, and copy, and the result is a document that anyone - PMs, Engineers, Designers, QAs - can visit and answer questions about how the product should be.

Mockups and Stories are not the same in this example

Specifically because Stories don't end up in the product, and mockups do (or at least have the potential to). For that reason, we consider Journeys, Stories, overview content, and general discussion as being associated with the Spec, but secondary and supplemental to it.

To answer your specific questions

what should the single source of truth for an app be?

If it suits your production process, consider using a Spec as a SSOT.

Should it be the mockups (that are updated to reflect the outcome of these plannings?), or should it be the stories/journeys?

I suggest neither, these both supplement the Spec.

Do you still maintain that stories & journeys should be the SSOT even if the stories didn't cover what was already developed?

Again, I don't think these should be the SSOT, and how much effort you want to want to put into the maintenance and management of your stories depends on your specific process. In our case, we use stories to get from zero to something, and they are eventually superseded with more detailed scenarios for testing and refinement.

Additionally, WHEN it is expected that the designs need to be updated?

If you're using a Spec, the designs (as they are represent via mockups in the spec) should be updated when everyone signs off on the changes that are being made.

This last topic brings us onto the idea of versioning. When using a spec, it needs to be clear which version of the product the Spec is describing. How exactly to deal with this is a bit beyond the scope of an answer like this, but essentially, everyone needs to agree to the aim, scope, and duration of a specific batch of work.

0

Option when there is no time for Specs

I often find myself in this picture, being part of a grown startup in agile environment. Things can get complicated even if there was no change in the designer ;)

To have a Spec as SSOT would be wonderful but not realistic: that is why you as a UX designer are the actual SSOT, and should provide answers supported by all the material you were able to gather or produce for a certain project/epic/feature (competitor analysis, user journeys, use cases) so you can give objective explanation for a design choice when it is asked.

This is very difficult if the material you have does not make sense for you (user story mapping was not effective, use cases are incomplete, some business requirement is not met by the current design). If this is the case, you should go back on that quickly, discuss with a product owner and update stories and mockups asap.

So the answer to your question is: be the SSOT and use documentation to support your truth.

Motivate any design solution not because that was carved in stone in some document but rather because that makes sense for the discussed use cases and stakeholders requirements.

BTW - even if a SSOT is identified - you should always be ready to Plan B solutions in case tech is not supporting the previously approved design (that can happen). Update mockup and stories accordingly. Go get 'em!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.