Prototype 2 Pc Requirements
Heartbreak Writhe
LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.
One of the things I emphasize in my book How To Understand Almost Anything is the validation of your understanding. As long as you just keep the thoughts in your brain, trying to think hard about it, it's very easy to overlook inconsistencies or incompleteness. Trying to get a whole group of people to get to a common understanding this way is almost impossible. Writing things downis a great first step to improve the situation: writing uncovers some inconsistencies, at least if you're really trying to be precise. But prose will only ever go so far, as we all know, especially if you are trying to build a whole set of concepts over weeks or months.
A better way to check a bunch of concepts for consistency and completeness is to express them with some kind of formal framework. Science has been doing this forever, usually using math. What is the formalism that we can use as we try to understand requirements about a software system? How do we effectively validate the construct of ideas we're assembling in our heads over time?
However, there is big catch. In typical corporate settings, it takes too long. You're going to write stories/epics/whatever about whatever needs implementing, plan it into a subsequent sprint, and then eventually implement it. That's perfectly fine when you are implementing a software system in an agile context. But if you're trying to use this to validate your understanding (for example, as part of some kind of analysis of business logic) then this is too slow. The way I like to work is to spend the morning with the stakeholders discussing requirements, and then, in the afternoon, implement them in order to have a solid, formal baseline for validation in the next morning's session with the stakeholders.
What you need, therefore, is an environment in which you can very quickly implement and then play with and test the particular aspect of the software system that you're trying to understand. My experience is with the domain logic (subject matter, application logic, business logic, use whatever term you prefer). So I need a "domain logic prototyping environment".
I use MPS for that. MPS is a tool for building domain-specific languages, and I have been using it for over a decade now to build DSLs. However, even if the goal of a project is not to build a DSL with MPS, it is a great approach to reaching the goal of discussing in the morning and implementing the morning's insights in the afternoon as absolutely attainable (assuming you are reasonably proficient with MPS).
The nice thing with MPS is that you cannot just express structure (data, forms, simple validations) but arbitrarily intricate behaviors. And you can decide if you want to design custom abstractions for the problem at hand or reuse existing ones (for example, expressions). And you can add semantics too, both static (checking, typing) or dynamic (through an interpreter).
But I assume there are other technologies as well. How about a Javascript implementation in the browser (without any other infrastructure)? Has anybody ever worked with Naked Objects? I suspect there are some low code platforms that can be used to this end? I'd love to read your experiences.
Is it typical that a Product Owner (or even a BA) creates a high-level prototype/wireframe of a system based on the requirements document to ensure that the requirements are clear enough to start working on user stories for the UX & development teams?
I am currently being 'promoted' from a developer to UX designer and tasked with creating mock-ups direct from a requirements document, but the document is unclear on several aspects and have spent most of my time thus far doing what I would consider more PO/BA work of clarifying basic things in the requirements document. I am aware that this process is iterative and the UX/dev teams will probably need to discuss/clarify items during design & development, but is there some sort of 'minimum viable requirements' stage the PO is expected to deliver before this happens and how is this determined?
Edit for clarification: prototype here refers to a high-level visual aid created in something like Sketch, rather than a first revision implementation in code. In addition, in my example, no user stories exist, only a raw, incomplete requirements document.
I would say no.Considering that the PO should focus on defining business value.Having the PO creating prototypes kind of influences the teams development in technical terms. I think it is important that the business value is well defined, so that the team can implement it.Also, the act of creating a prototype is a learning experience, to figure out how to implement the business value, maybe even what the business value is.It would be a missed opportunity for the team not to do the prototyping.The interface between the team and the PO is the user story and the defined business value. Having the PO do the prototyping kind of softens that up.
It is my believe as a scrum master, that the PO should NOT develop. Focusing on defining business value and maintaining a backlog is the product owners way of communicating with the team. (of course verbally all the time too, after all we are using agile principles)
The PO should do whatever is necessary to ensure that the story is clear enough and well-defined so that the team can work on it. If that means screenshots of similar products, wireframes, doodles drawn on the back of a napkin, a wall of text, or whatever, so be it.
This will depend quite heavily on the complexity of the product / feature, as well as the experience of the team. The PO's vision of how the feature will look / work will also play into this. A way for the user to input a Yes/No choice can be implemented dozens of ways, so if the PO has a specific idea in mind, a wireframe or mockup can aid in that clarity.
And, it will almost certainly be an iterative process (at least to start). The first go around at the story may be completely unclear to the team, so some details are added or clarified. The second go around is still a bit unclear, so the PO adds a mockup, and then it becomes clear enough for the team to score and work on.
All that said, what matters in the end is the acceptance criteria. Mockups and screenshots can help guide development, but the team may use a different approach to satisfy the acceptance criteria than what the PO had in mind.
User interfaces often have a lot of business aspects as well as technical design aspects - that is why there is the word interface in UI. Since it is the role of the project owner to communicate business requirements to the team and since communication often works best by examples, sketching ideas for the UI or ideas to change the existing UI for adding a new feature - by using whatever tools are available - can be a valuable instrument for the PO.
The PO should not be expected to work out all the gory technical details, and he/she should not expect the team to build his/her suggestions all literally. Ideally, for design of complex UI requirements, you have some UX experts and someone from the "user's" side in the same room for a discussion. For certain types of software, the PO here can take the role of a "representative user".
However, in a really agile team, the team should work out the form of communication which works best for the given product and/or environment. If letting the PO sketch the UI works for the team, fine. If that is not necessary or turns out to be less efficient than verbal descriptions, then they should use the latter.
You can ask him to draw lines on a board (or into something like Visio), but asking him to do any technical work doesn't make sense. However, you could develop 'paper prototypes' together on a board with you drawing what you understand and him correcting you according to what he meant or his preferences.
Creating an optimal design involves multiple cycles of understanding the problem, identifying and understanding users, articulating requirements, devising solutions, evaluating those solutions, and then refining both the problem itself and the candidate solutions. Ultimately, the appropriate decision makers can select a solution that appears to solve the correct problem through the optimum balance of features, properties, cost, and constraints.
Figure 1 illustrates a process flow for an iterative design process. Customer representatives work with an analyst to develop an initial set of requirements. These initial requirements likely will be on the right track, but incomplete and not entirely accurate. You need to accumulate enough information about functionality, quality attributes, and constraints so that a user experience (UX) designer can conceive one or more possible solutions. Then, the UX designer works with the development team to create one or more prototypes to further the conversation with the customers.
After customers evaluate the prototype and provide feedback, all participants now have more information. They can refine their understanding of both the problem and the product requirements. That knowledge then feeds into another cycle of solution conception, creation, and assessment.
This article is adapted from The Thoughtless Design of Everyday Things by Karl Wiegers. Karl is the author of numerous books on software development, design, project management, consulting, and other topics. During the past 50 years, he has designed chemistry experiments, software applications and user interfaces, software development processes, books, games, songs, and training courses.
Designers and developers use prototypes in the product development process to gather information about the final product and its behavior as early as possible as well as to lower the risk of developing failing products. Literature describes prototyping as needed in general, but does not offer methodical approaches to the development of those prototypes themselves with the aim of gaining a maximum of knowledge. Prototyping is therefore primarily intuitive and iterative which often leads to an inefficient process. In most cases, no particular requirements to the prototype other than the requirements for the final product are specified. This paper therefore discusses the differences in requirements for different types of prototypes (e.g. functional, design and packaging) in different stages of the product and process development chain. The first part consists of the differentiation of types of prototypes, their relation to different stages of the product development process and accompanying requirements. Those types come in different forms and manifestations, for example virtual or real and focused or comprehensive. For each form and manifestation of the prototype, the developer has to specify different requirements. Those requirements depend mostly on the functions and phenomena the developer aims to investigate and the stage of the product development process. Nevertheless, the developer has to take into account that the manufacturing process of the prototype may differ from the process of the final product, which also leads to different requirements for the prototype. Another major difference between the final product and the prototype is the group of users or testers respectively. Depending on the group of testers, ranging from the developer himself over the management to the customer or even the end user, the developer has to anticipate the behavior of those testers and has to consider that behavior when specifying requirements. For example, a colleague, who also works on the product, may interact with the prototype in a different way than a randomized tester, who never saw the product before. Each prototype and subsequently each prototype testing phase then creates new information for the developer who is then able to transform the received information into new requirements for the next iteration of a prototype or the final product. Following these first results regarding requirements for prototypes, the paper discusses a holistic approach to the prototype and process development. The model is based on the holistic product and process development and visualizes the different influences and connections between the prototype development process and the prototype life cycle. The postulated model adapts the existing model and defines the prototype as a product itself, which then takes the place of the product in the product lifecycle chain. In addition, the prototype testing phase replaces the product use phase. This new model also includes the gained information from earlier versions of the prototype that the developer may respect in further iterations. The goal of this visualization is to provide an overview over the holistic prototyping process and the different requirements the developer has to take into account
ff7609af8f