When you think about using an app, you tend to envision things you do, and things happening in response to what you do.
Like, say, a ‘sharing’ feature:
After reading an online article, I can share it with a ‘friend’ user on my social networking app, after which they get notified, and can also view and open that article.
One of the joys, and challenges, of building an app end to end from scratch, is reasoning through, designing and building everything that leads up to making such flows possible.
I’ve come to realize there is a certain hierarchy to this: concepts are the foundation of features, which in turn are the foundation of (user) flows.
So let’s say I want to make the above social media flow possible in my app. Where to start?
The full-stack dance
I tend to start with a very low-fidelity idea of the user flow and its UI components.
Near the bottom of an article there is some kind of ‘Share…’ button, which brings up a list of my friends. Each of them has a ‘send icon’ button next to them, and pressing it sends the article to that friend.
And then go all the way to concepts.
Core concepts: Article. App User. Friendship between Users. Share.
And then a back-and-forth dance starts, ever higher fidelity, adding and adjusting DB Schemas as UIs and flows reveal what will be needed.
‘Full-stack’ is a bit of a buzzword by now, but there’s honestly something incredibly satisfying about sculpting the ‘whole’ in a back-and-forth like that, even if only in your mind, after choosing a certain UI flow and thinking through what it would take to achieve it.
‘aha, I can click to reject an incoming friendship request? Guess we’ll need some kind of Status property on our Friendship concept then to model this. Wait, how would a user flow look if I change my mind and want to accept after all?’ etc.’
Any app or piece of software is typically comprised of a number of features, that are delivered to the user as a bunch of flows. I’ve found it instructive to consider these separately in my mind.
Yes, this happens to coincide pretty closely with that famous Product Management venn diagram. Except that all this is about a one-man project, so there are no other ‘roles’ here :)
Different approaches by discipline
Typical Product Management centers around features
aka ‘here is a user/customer problem it’s valuable to solve through our product.’
Typical UX Design centers around (user) flows
aka ‘how to achieve a certain job to be done as a user with delight and least friction’.
Typical engineering centers around concepts
aka ‘how to model all this in data and app logic’. Because that modeling will almost always be closely aligned to the core concepts at play. At some point, usually early on, gotta name and define that table or API schema! So yes, these ‘concepts’ suspiciously look like SQL tables or API endpoints for a reason, though I think they have explicit ‘product value’ beyond that.
So what
Yay, I invented A Framework!
Anything actionable to take away from all this?
I guess as so often, ‘consider all sides’?
When leaning towards an engineering mindset (as I tend to do): once you have your concepts defined and data-modelled and coded your way up from there all the way to a functioning feature, take a step back: did you deliver it through the best flow? The only flow?
Would I only want to share when I reached the END of an article? Might this flow start from a friend screen instead? How often would I want to share immediately with MULTIPLE friends? Etc.
When coming from a product mindset: it pays to invest in defining and understanding your core concepts deeply beyond ‘just’ how they are surfaced in the UI, even though they are ‘implementation detail’ in a way: getting them right in your head makes the 2 ‘sides’ of a feature flow either easy or hard.
For instance, if a new feature can be conceptualized by naturally extending an already existing concept in your app, it’s often easier to both engineer and design for it. Operative word is Naturally! A common ‘tech debt’ shortcut is unnaturally extending an existing concept to ‘hack in’ support for a feature.
Why now: connecting with fellow People Calendar users
People Calendar is intended explicitly to be useful even if using entirely on your own. However powerful it is to achieve a succesful network effect, current strategy is not to require one to be succesful.
Fine and dandy, so it’s like a Calendar app and/or a CRM. Concepts WELL understood.
The thing is…
I actually DO wanna layer some ‘network’ type functionality in the app. My app is all about facilitating plans with your friends and loved ones more easily, so naturally it would be nice if you can entirely arrange things through the app — a super smooth ‘mini doodle’ or ‘auto doodle’ flow has been part of the vision of this project from day 1.
Whoops.
Suddenly the ‘concepts’ are getting a lot murkier here. I have a ‘network’ comprised of ‘people’ that can either be single people or groups. And now somehow I also want to tie that in to social-network-style ‘friends’ somehow. Better get it right with the concepts! I’m sure I won’t :)
Can a single ‘person’ be tied to multiple ‘friends’? How do I offer flows to ‘connect’ to people, but don’t give up on the flow where you create and view people entirely added yourself? Etc etc. Tricky stuff. But I’m having a blast trying to figure it out :)