Hapyn Part 2: First Things First
Okay engineers and process junkies, question for you:
Have you ever built an app in the order the user experiences it, i.e. starting with the login instead of core functionality?
I’m asking because nGen is, right now. And things are going well. Either we’re lucky or crazy or both. The unconventional development approach has sparked some interesting conversation. We want you to get in on it. Comment below and tell us what you think.
App development is far too scattered and messy to hope for a plan like that to go smoothly.
“I never have done it that way…It’s an interesting idea though. I would think what is likely to come out of a process like that is a great ‘first impression’ experience for users, since so much thought is put into those first few seconds with the app.
A blocker might be smart allocation of time. For instance, login is a fairly straightforward process. Your design and UX people might spend ages making it sexy and welcoming and intuitive and whatnot, but your backend devs will likely recycle some tried-and-true login system already out there. If you’re insisting the entire team stay on login until that’s done, those backend devs might be twiddling their thumbs when they could be planning the more complex data structures the rest of the app will require.
I’m not sure how much value there is in planning the very first creation cycle for an app. I think there is more value in ensuring your ongoing process is healthy. Does everyone have a strong shared vision? Are you staying quick and iterative? Are you doing proper testing to make sure code doesn’t deteriorate? Are you really listening to the people that are using it? That kind of thing.”
If the login / entry experience blows…the app blows.
“I think the answer from my side would be yes, but my approach is usually to nail the biggest, gnarliest design challenge first. Then, the rest should fall into line behind it. Normally, the most complex bit wouldn’t be the login, but I do know we’ve worked on gigs where the login was challenging based on whether or not it would be a custom social network type deal or using facebook / twitter / email for that purpose.
I would absolutely recommend at least storyboarding out the totality of the experience early (including the login) to marry the concept with the business goals and user needs. I’ve seen apps that we’ve had to save, where the original developer shit the bed on the simple first phases of the app and killed the rest of the concept because they didn’t spend the time to get the simple things right. That’s probably your bigger danger to avoid – don’t glaze over the simple things. The opinion of the experience will be set early whether it is good or bad with the user.”
The Why Behind Hapyn’s How
No one on our team has built an app this way before. Typically we start with core functionality and build backwards and forwards. The decision to begin with login stems from several factors:
- We want to use Hapyn to build Hapyn. We’re creating the path to a “minimum usable product” (MUP) so we can use Hapyn ourselves to see how collective action works best. Once we get to the MUP, we’ll have something tangible to make really great.
- We’re not starting at ground zero. We’re pulling in a large amount of code from another app we’re building for the same client. The team has already sorted through many of Hapyn’s features.
- The client trusts us to do what’s best. We’re fortunate to have latitude to do things differently. Some really great things are emerging from this grand experiment.
So what do you think? Comment below and let us know.