Product architecture, a step-by-step real-life example

(The article was written at the end of 2017 but was never published until now).

I will guide you through the process of creating a website/app prototype that is approved by stakeholder(s) and ready to be handed over to your team for the final designs and development.

Spoiler

ToC:

• Project history and description
• Structure, specification, estimation
• Pages, layouts, building blocks
• Components decomposition
• Content and putting the emphasis
• The result

TL;DR:

1. Write a vision statement. Create a mind map and write user stories. Compartmentalize.
2. Wireframe a low-fidelity prototype with properly named and arranged artboards. Add simple building block aka components aka symbols. Utilize auto-layout.
3. Identify all necessary component states and create symbols for them. From scratch. Be both lazy and smart.
4. Craft good enough copy for all components.
5. PROFIT

Before diving into this article, I recommend reading the previous one: How to evaluate an incoming project. This will provide you with essential context and tools that will complement the content presented here.

0. Inception

In early 2017, a friend of my ex-colleague, approached me with his idea of creating a marketplace where children from orphanages could sell their handicrafts. Given my recent experience managing the creation of a similar marketplace, lmbd.ru (“Russian etsy.com”), I was able to immediatelly offer him lessons learned, rough estimates, and various options to turn his vision into reality.

Later that year, he revisited and modified his idea: a crowdfunding service for charitable projects that would provide compensation to teachers working in orphanages.

Initially, there were three roles and three different interfaces:

1. Agents: Responsible for creating fundraising campaigns and earning money from them.
2. Teachers: Involved in the campaigns and earning money from their participation.
3. Donors: Individuals who contribute to the campaigns, making the world a better place by believing in the idea and trusting the agents and teachers.

We agreed to meet and discuss how to proceed with the project. As luck would have it, I had a few available developers and a designer with whom I had collaborated on previous projects (the marketplace that I’ve mentioned above).

After the meeting, we made the decision to omit the role of teachers. It became apparent that having a separate role for teachers might not be necessary, considering that crowdfunding campaigns often rely on personal agreements between the service, agents, and teachers.

As a result, we concluded that creating a typical “Kickstarter” model was the way to go, and the primary focus became how to position the service effectively. It wasn’t surprising to realize that the business didn’t need to be innovative in every single aspect. In fact, opting for familiar and user-friendly models would likely be better, as it would allow users to grasp the concept easily and concentrate on the primary theme of the platform.

We also simplified the transactional model by opting to distribute the raised funds manually after a successful campaign. Given the uncertainty regarding the technical aspects of how Agents would fund local teachers in the African countryside at that moment, this approach seemed more feasible.

Furthermore, to prioritize transparency, trustworthiness, and generate excitement, the founder made the decision (for the first version) to accept donations exclusively in cryptocurrency and leverage the benefits of blockchain technology (sweet 2017, prior to the market crash of 2018).

With the idea in place and a dedicated development team at our disposal, it was time to roll up our sleeves and get to work.

1. Specification

To gain a clear understanding of what and how to design, my approach always begins with creating a concise document that outlines the project’s vision and form. Vision statement reflects the direction we need to take, and mind map outlines the possible implementation.

We operate as a “kickstarter.” The key difference: our approach to ensuring transparency and accountability.
Once a campaign reaches its funding goal, we take the extra step of verifying the recipients of the funds to ensure they align with the project’s objectives.
By doing so, we want to show donors that their contributions have a direct and meaningful impact.
In the initial version of the platform, the process would work as follows: blahblahblah.

A part of the mind map

Having gained this understanding, it becomes much easier to estimate the project’s labor intensity and identify its major milestones.

A part of the estimation spreadsheet

Having these artifacts ensured synchronization between me, the client, and the team. They helped us assess whether we were on the right track and if we were progressing in the right direction. That was the case, so the next step was to write the specification.

I always write a spec in three stages:

1. During the project estimation stage, we’ve already figured out the main spec sections, grouped by key functions. (Mind maps don’t work well for this because different pages might have the same functionality.)
2. Next, I write all the user stories. (I skip the draft and write the “clean” version right away. If you don’t have much experience, you may have to write numerous stories, discover patterns among them, and decide which features help implement these patterns).
3. Each story is then filled with details. Usually, I don’t include a lot of details, just a list of the necessary data and various notes, sometimes for my own reference. Any missing data usually comes up during conversations and is added to the spec as we progress.

A part of the specification

Each format of work leaves a mark on the way I think about the task. Writing the spec enables me to figure out the structure and the order of feature implementation. I try to compartmentalize them by version and by the order of their development. For instance, when a low-fidelity prototype is drawn later, I often discover holes in the spec that need to be addressed.

2. Low-fidelity UX prototype

This part mentions Sketch.app, which was very popular before the age of Figma. But concepts are relevant to this day.

Everything should be built top-down, except the first time.
© Alan J. Perlis

Since it’s not my first rodeo, I optimize the prototype right from the start.

The first step it to prepare the Sketch App. The most crucial plugin that radically simplifies the designer’s life is Auto-Layout, especially its Stacks feature, which brings the advantages of Flexbox.

Next, I create separate Pages in Sketch, corresponding to the sections outlined in the mind map and specification, making necessary adjustments along the way.

Low-fidelity prototype — pages

I use mobile artboards as they are the most convenient and simplify decision-making. These artboards allow me to lay out all the screens that will be on the website, including different states of the same screen. Properly naming and arranging them logically is crucial for clarity.

I prefer a logical arrangement from left to right, with deviations downward when necessary. For naming, if the logic is straightforward, simple names are usually sufficient. However, if the logic becomes complicated, I add more descriptive numbering to ensure clarity.

Low-fidelity prototype — artboards

Now, we create a base symbol from which we build everything else. For example, the base symbol might be structured as follows:

• Background: 320x100, fixed width.
• Text: 300x80, fixed width with resizing enabled for top and bottom.
• All elements together: Fixed width with resizing enabled for top and left.

Low-fidelity prototype — base symbol

This is the first building block, which we will later turn into other blocks as we go along until it disappears. The absence of the base block signals that we’ve gone through all possible components of the website.

We add blocks to all artboards, marking each of them with a name or a short description of their function.

Then comes the time for Auto-Layout with Stacks: we select all the blocks and apply stacks to them, as shown in the picture — and we’re good to go. From this point on, we can easily add, drag, and modify blocks, as they will automatically line up one after another, saving us a great amount of time on alignment and adjustments.

Low-fidelity prototype — auto-layout

As we progress, we create new symbols along the way, such as header, footer, input, info, action, etc., and we assign different colors to them for convenience and clarity.

After a while, our prototype begins to take shape, and we end up with something like this:

Low-fidelity prototype — result

3. UI components decomposition

During this stage, I decompose each UI component into its various states. For instance, the header may appear differently for a logged-in and an unlogged-in user, resulting in multiple states for this component.

In the layouts, whenever possible, I use only one basic variant of each component and showcase the entire variety of states separately. To achieve this, I prefer to allocate a separate page and elegantly organize everything, avoiding reliance on automatically created “symbols” pages.

This is the outcome of low-fidelity prototyping phase:

layout
 header
 footer
 pagination
letter
 header
 footer
newsfeed
 feed
 post
comments
 feed
 entry
 reply
dashboard
 donation preview
catalogue
 campaign preview
 navigation
campaign
 description
 creator
 funding status
* (should be separated)
 input (all inputs)
 action (all buttons and CTAs)
 info (all custom blocks)
 block (undecided)

By examining it, we can identify any missing elements and determine all the other necessary states.

Here is the finalized list (along with notes to myself on new components to be added and any required corrections for existing components):

layout
 header
!  not signed in
~  signed in
 footer
! loader
campaign
 description
 creator
 funding status
~  active
!  funded active
!  funded finished
!  failed
!  canceled
catalogue
 campaign preview
  regular
  donated
!  for creator
 navigation
  regular
  search active
newsfeed
? feed
! post peview
~ post full
comments
? feed
 comment
 reply
! post comment
! post reply
! deleted comment
letter
 header
 footer

I also need to create controls, which are often part of larger components, but are inherently universal:

controls
 buttons
  primary
   normal
   hover
   pressed
   disabled
   loading
  secondary
   normal
   hover
   pressed
   disabled
   loading
 inputs
  text field
   normal
   focused
   error
   disabled
  text area
   normal
   focused
   error
   disabled
  checkbox
   unchecked
   checked
   disabled uncheckedd
   disabled checked
  radio button
   unchecked
   checked
   disabled uncheckedd
   disabled checked
  dropdown
   normal
   pressed
   disabled

And several other essential components:

wysiwyg
 normal
 selected
pagination
 first page
 pressed
 page in the middle
image upload
 empty
 loading
 error
 loaded
social share
 normal
 pressed
 loading
system messages
 info
 warning
 error

The remaining non-decomposed components can remain unchanged for the time being:

inputs - these blocks are arranged from the controls.
action - it's not only a button but also a CTA that designer should work on.
info - each of these blocks is individual, but generally, it's a piece of content, including typography, images, etc.
block (undecided) - I use this block when it's not obvious which block to use, allowing me to think about choosing or creating a new one later.

I mark them with an asterisk to remember that they will most likely be dissected later.

This is what my Components page looks like at the end of this stage.

Low-fidelity components page

For controls and common elements, you can and should use ready-made libraries like this one. However, for the first time, I recommend creating everything from scratch. The advantage of building components from scratch is that it forces you to think about what you truly need.

4. UI content

When writing the previous parts, I found myself criticizing the lack of novelty and the fact that I was essentially prototyping a “kickstarter”. However, my stance is that for common use cases, it’s often best to utilize approaches that people are already familiar with. There’s no need to reinvent the wheel; instead, the focus should be on making the right emphasis.

The emphasis should be aligned with the goal of the platform. That’s why, before transforming the low-fidelity prototype into a high-fidelity version, I carefully craft all the copy that will be used. While simple and concise, this copy is likely to be appropriate for the final version.

Low-fidelity prototype — content example

Additionally, for screens where content is crucial, such as “How to start a campaign,” I write an outline of what should be included. Even at this early stage, crafting text for sections like “How we work” proves to be invaluable in crystallizing the product’s features and refining its interface.

Low-fidelity prototype — page content description

5. Handing over to the team

At that moment, I knew my team really well, and we had already discussed how we would approach this project from step 0. Therefore, it was relatively easy to have a “demo day” for both the client and the team. We gathered to discuss the UX prototype, made some necessary fixes, and then I proceeded to set up a working environment for the team to begin the design and development process.

Final result

Unfortunately, the project was never completed as the client was unable to secure funds. However, I can share some of the final designs with you. Thank you for taking the time to read this article.

Create and View campaign interfaces. Design by Anton Nesterov