Page: Pentacle, at a glance

Baseline assumptions

To get started documenting Pentacle, let’s get some baseline assumptions out of the way.

1. We define each prong in terms of its outcomes, especially which one of these outcomes we might judge to be the most crucial. Really, we have itemized each prong based on each being what is commonly referred to as “UX deliverable”, that is, in line with its outcomes, you can present each phase as work done during the product design.
2. For the sake of moving the discussion on quickly without “or’s” and ”/‘s” (say that out loud), we call everything “product” — namely product, feature, iteration, functionality, project, service, venture, and we could go on…
3. You might encounter the term “product commissioner” and wonder “what now, new role?” We could’ve just spoken of a “product manager”, no? Well, the idea of a commissioner is to not be so specific as to who may have the most emotional tie to the product, and can be anyone who “commissions” it, who’s in charge of it, but not necessarily the traditional role of a product manager. Capisce?

The pentagonal

1. Brainstorm
2. Map
3. Wireflow
4. Prototype
5. Engineer

Brainstorm

Definition

Brainstorm is a coordinated set of activities toward establishing a product charter.

A product charter is a single source of truth of the product, defining its goals and boundaries. While some parts of charter may be updated as the product progresses, most of it, especially its goals should ideally be almost carved in stone. This way, the product team doesn’t stray.

Any change to the product’s goals might actually mean a new direction, that is, a new product, entirely. Any such drastic changes to the charter must be carefully weighed.

A successful product is a testament to a successful charter, a successful Brainstorm.

Outcomes

1. Possible solutions to build
2. High-level concept of product,
3. Creative brief
4. User personas
5. Empathy maps, and
6. Product Charter

Actions

1. Generate constraints-free definitions of idea or ideas from creative brief (if available). Think of this point as “wilding” or mind-mapping of ideas, letting yourself dream them up wild. A creative brief might emerge, which you’ll eventually test against the potential users of product. Really, a Creative Brief should emerge, either as improvement on one from the product commissioner or as deduced from this exercise.

2. Jot a list of features or solutions (or ramifications/implications of feature) to idea or ideas given in creative brief. What might product commissioner be desiring?

3. Access research or conduct new studies into knowing if the problem truly exists for which the creative brief is asking a solution. At this point, assess and answer a few ethical principles that may be applicable to product. Ask and document hard-hitting questions about the process for designing this product, and ethical issues that may arise from designing the product itself.

4. Empathize with potential users of possible solutions from the brainstorm and creative brief. User personas may be created at this point. In creating personas, attempt to address more of the issues raised in the step above. Let your answers begin to prescribe what sort of design choices might resolve such issues if/when they do arise.

5. Has or have these solutions been built already? What about these existing ones? What might we do differently? Why’d they make the obvious decisions?

6. Who’s behind the creative brief? What’s this person/company like? What might delight them? Asking of product commissioner, see?

Map

Definition

Map represents the drafting, drawing, connecting, refining, and finalizing of what will be the scope of what is to be built, the product, based on generating, testing, and validating hypotheses and/or assumptions.

Think of mapping as the final filtering and fine-tuning of everything fed to this prong from brainstorming activities. Where Product Charter gives a bird’s-eye view of the product, Product Roadmap says “here, get to work on this.”

A “Product Roadmap” or scope document should wrap up the map phase and may either fully encapsulate its different outcomes or point to them (where they may be housed in their own separate documents).

Outcomes

1. Validated Product Hypothesis (VPH)
2. Information Architectures (IA’s)
3. User/system (task/work) flows and flowcharts
4. Navigation Design (ND)
5. Brand & Copy, and
6. Product Roadmap (PR)

Actions

1. Take all or most of the constraints-free ideas from Brainstorm and filter them through a set of tests (or validations) that produce a hypothesis or set of hypotheses. We should call this Validated Product Hypothesis (or VPH). If an idea doesn’t make it through or to a VPH, at this point, it’s safe to drop it. Ultimately, be able to build confidence in the product scope (and high-level goals).

2. Define high-level goal(s) (HLG) for product. HLG’s should be clear, succinct, and expressive. Clear — one gets it because it’s free from ambiguity. Succinct — only one idea, feature, or direction per goal or statement, a specific task in the system. And, as expressive — as can be translated immediately into a flow or design (pattern).

3. List product objectives — how do you want to achieve that goal(s) from HLG above? Now try really mock “designing” each of the ideas from Brainstorm filtered through or coalesced into HLG’s. This mock design will help a lot in your importance v. feasibility study coming next because you’ll get some taste for how this whole thing might work and whether it may be worth trying or not. A mock or trial design may be all in literature or involve some rough sketching.

4. Do an importance vs. feasibility map by answering the questions: (a) how important is the product as a whole to the business, to users, and to achieving end goals? and (b) to what degree does each individual feature/function (or requirement) fulfill needs, deliver value?

5. Create user journey maps, having now gained clearer and better understanding of product, the business, users, and end goals. What’s the desired experience for a typical user as they go from A to B of the product or how should they go from A to B?

6. What more can enhance the experience of the user journey? Good copywriting? Compelling brand and expressions? Do we have those? Copies and branding/brand storytelling should be produced now. (Of course, even these exercises can be individually subjected to their own Pentacle) Now, if these already exist, then determine suitability, match with product, and/or propose suitable update/refresh.

7. Assess content. What content is available? Or initiate creation of suitable content. What sort of content might be needed? What frequency of production for the product’s goal(s).

8. Create a suitable architecture for this content. Card-sorting, tree-testing, and site-mapping and other information architecture-type activities come in handy now.

9. Design the navigation that delivers the expected user experience and business (or the product’s) goals.

10. Collate the results of all activities in a Product Roadmap that spells out precise details of what is to be built (say of an immediately following phase). While PR specs out product, it doesn’t necessarily concern itself with timelines, design or product development modalities that may be the prerogative of product management, where a product team can involve the role.

Wireflow

Definition

Wireflow further tests the product hypotheses, that is, what has been roadmapped, bringing the outcomes as close to the final prototype as possible but in a very low-effort, low-cost manner, as if merely sketching by hand.

Pentacle introduces the concept of wireflows (a combination of wireframes + task/user flows) as a way to present the wireframes/skeletal diagramming of the product in the context of documented (user) goals. It’s easier to consume and appreciate structure when you can easily visualize how it interoperates.

There may be a world where Map and Wireflow phases overlap finely. However, if the former is thorough enough, the latter may really be the first “hand-drawing” of the product itself, with minimal validating needed. Wireflow already makes a number of conclusions, just ahead of the prototype.

Nonetheless, should any tests of user flows from Map require such stretch as needing actual wireflows (overlap) to reach validation, same way certain wireflows may need actual prototypes (overlap) to validate fully, then you have understandable overlaps to document in some outlier threads while still keeping the individual activities from these overlapping prongs as distinct as possible. Pentacle as a tool should shine in such scenario.

Outcomes

1. Sketches or drawings to depict the structure and functionality of product.
2. Wireframes, and
3. Wireflows (flowcharts + wireframes)

Actions

Prototype

Engineer

References

1. The Graphic Design Process, Baseline Education Ltd. Accessed Apr. 8, 2024
2. Product charter: What’s included and how to create one (with examples), Bart Krawczyk, Log Rocket. Accessed Apr. 10, 2024
3. 3 elements every project charter needs, Julia Martins, Asana.com. Accessed Apr. 10, 2024
4. How to Generate and Validate Product Hypotheses, Leonie Lacey, Railsware Solutions FZ-LLC. Accessed Jun 01, 2024
5. How to Generate and Validate Product Hypotheses, Maria Arinkina, Upsilon LLC. Accessed Jun 02, 2024
6. Wireflows: A UX Deliverable for Workflows and Apps, Page Laubheimer, Nielsen Norman Group. Accessed Jun 03, 2024
7. 14 UX Deliverables: What will I be making as a UX designer?, Kasturika , Daniel Skrok and Christian Briggs, Interaction Design Foundation. Accessed Jun 04, 2024
8. Wireframing User Flow with Wireflows, Mike Angeles, Balsamiq. Accessed Jun 05, 2024
9. The Role Of Storyboarding In UX Design, Nick Babich, Smashing Magazine. Accessed Jun 05, 2024