Monthly Archives

September 2016

Wireframing for Startups and Corporations

By Design, Development, Estimation, MVP, Software Lifecycle, Testing, Tips & Tutorials

It’s Cheaper!

If you are interested in building bad software with bugs and lots of mistakes, then this article isn’t’ for you.  If you are interested in moving your development team along faster, saving money and building a better product for your user, please read on.  When Bytelion wireframes, it allows us to see the application.  The final wireframe summarizes all of the thoughts held in people’s minds and ensures that everyone not only understands how the application solves your problem but more importantly, it quickly and easily helps others understand what you are thinking.  Wireframing is critical to all lean departments and especially technology start-ups.

How does wireframing save you money?  Simple, it ensures that you have the right workflows up front. In this hypothetical, imagine if you omitted an essential feature on a page that was pushed to production.  To find the bug  for this feature, you have paid for:

  • UI Design (8 hours)
  • UI Implementation (8 hours)
  • Backend Implementation (12 hours)
  • Quality Assurance  (4 hours)
  • Total=32 hours

If you had wireframe the issue, the bug would have cost you

  • Wireframe (2 hours)
  • Total=2 hours

Stealing off of NASA’s slides and making some slight modifications, the blue arrow indicates where wireframing is in the bug detection value stack.  Used early, it is an awesome tool.


Value of catching bugs in wireframes.

NASA value of catching bugs in wireframes.

If you are a startup, every dollar you is extremely expensive and must be spent wisely.  Why focus on fixing bugs in production when you can solve most of your problem in the first two weeks?

To read more about NASA and bugs, check out.

Too Many Wireframe Tools… Which One Should I use?

There are many tools on the market. We have used all of them. I could write pages upon pages of why some systems are better, but here (in no particular order) are some of the tools that are best.

MyBalsamiq – The desktop was by far the best user experience, but its ability to not sync with an online version make this not as usable because customers and team members email different versions of the application. Because we work in a distributed environment, this didn’t work for Bytelion.

Gliffy’s integration with Atlassian’s JIRA + Confluence suite makes this tool amazing.  However, it is so inflexible that maintaining a working wireframe falls apart.   Sorry Atlassian, I still love you.

Azure – Bytelion loved the framework, and it was our primary for years, but found the product confining regarding our on online integration needs.  It slowly came out of favor and was replaced by…. our new go to.

Pidoco – Yes, this is the wireframe company that you probably didn’t hear of.  We didn’t either until we scoured the internet and tested everything we could.  This tool is our new standard.  There are three simple reasons by we love it:

  • Single Page App (SPA) is super fast and responsive.
  • Extremely flexible Workflow System…. THIS IS THE BIG ONE….  If you want to change a workflow, you can configure a workflow in a few minutes and keep different versions of the workflow.  This is ideal for rapidly testing different UX interactions.
  • Pages can be templated.  If a designer changed the header in one location, the header modified for the entire app.

Note, we have no association with the Pidoco company at all.  They did, however, chose to engineer their product well and didn’t take shortcuts.  We respect that and think that they will come out on top of they can build enough market share.

Selecting Red Routes First

Now that you know what tool you are going to use after testing them all :- ) you have to build your wireframes.  For an application, you have different use cases for what a user needs to do.  For example, if you are creating a recipe app, you would need a user to do the following:

  • A user needs to create an online profile
  • The user needs to buy other recipes from other people.
  • User needs to be able to generate their custom avatar online
  • The user needs to be able to post recipes to their Facebook account.

Of these use cases, you only want to select the most critical to making the application work. We call these red routes. In our scenario, we would only want to use these:

  • The user needs to be able to post to their Facebook account.
  • The user needs to buy ABC product.
  • A user needs to create an online profile
  • User needs to be able to generate their custom avatar online

We keep it simple and only wireframe the stuff we need.

Don’t be Lazy – Keep Your  Wireframes Current!

Once you create a set of wireframes that accurately reflect what you are trying to do, it is critical to keep it.  These wireframes will come up over and over. For example, if you are designing an aspect of a project that you have not touched in 6 months, having your wireframes current with the design make this is a snap.  Thankfully, Pidoco makes this easy to do.    It takes discipline to do this… keep up the discipline.   It is cheaper, better, and more fulfilling for you in the long run!



I Quit Full Stack Development

By Development, MVP, Tips & Tutorials

I quit full stack development because, in many senses, it never seems to work out.   In spite of this, the mythical promise of a full stack developer solving the world’s software development problems is alive and well.  Why shouldn’t you become (or use) a full stack developer in most cases? The best analogy that I can think of is in the medical field.

Imagine you want surgery… would you go to a specialist or a general practitioner?  I don’t believe that you need me to answer that question for you.  Why would you want to do the same thing with your software development needs?   If you want to develop code, for example, a mobile app, where do you go?  Software development has many different disciplines, tools and experience requirements.  You need to understand the difference between someone who knows Objective C and Visual Basic.  Hiring a full stack developer is like saying “I want to hire a general doctor and have him learn about heart surgery one week and then brain surgery the next.”  Can they hire a doctor to do that?  Yes, they could, but the results would most likely be unpleasant.

MVP – Full Stack  = Win!

One size doesn’t fit all.  For prototypes of MVPs, full stack developers are the best!  They execute quickly and get the product in front of users in record time.  If you need to scale out a real product, peccadilloes of an MVP tend to be noticed more often and require more attention to detail.  This is something that a full stack developer will typically run out of time to do.

Product – Full Stack =  Loss!

We have utilized full stack development many times, but as professionals, we strongly advocate bifurcating these efforts into full-time backend, full-time front-end development. This allocation allows each developer to focus exclusively on their area and work quickly and efficiently.  It also forces users of the API (for example, the front end team) to develop to well-documented standards.  Writing UI code is hard.  Writing backend code is hard.  Let people focus instead of thrashing due to rapid context switching. When initially rolling a product out, developing to standards slows development considerably.  Once a product is in use, however, developing to standards that actually move your development along faster and decreases errors.

What do developers think?

If the project is large enough, most developers will quickly agree. While everyone wants to be an expert across all disciplines, the tools aren’t there yet to allow for it.  Let the backenders be backenders and leave the front end up to the UI guys/gals!