Category

Design

Key Takeaways from Baltimore Innovation Week’s Session on Lean Product Design for Startups

By Design, MVP, Product Design, TestingNo Comments

Bytelion was thrilled to partner in Baltimore Innovation Week 2019 (BIW19), hosting a session titled, “Lean Product Design for Startups”. Since inception, over seven years ago, Bytelion has been a proud supporter of startups in the Greater Baltimore area and beyond. As an everyday practitioner of agile methodology for software development, the team at Bytelion has spent countless hours taking a “lean” approach to designing and developing software and applications for both startups and well-established businesses.

Baltimore Innovation Week 2019 logo

Last night, Bytelion’s Head of User Experience, Marc Hausle, led the session for a large group of BIW19 attendees at Clark Burger in Harbor East. If you were unable to attend the event, here are some of the key takeaways from the session.

What is Lean Product Design?

Clark Burger with people

Founders and entrepreneurs commonly will fall in love with an idea or a “unicorn vision” they have for the business, which is usually based on their untested assumptions. When they build based on these unvalidated assumptions they are more likely to waste valuable time and resources building something nobody wants. The goal of lean product design is to avoid this waste by focusing efforts on only building what you can validate as required based on reliable data and/or customer feedback. Lean product design recommends building something fast so you can begin to test hypotheses against real user feedback.  

Move Fast and Iterate

Once you start gathering feedback and performing other research it is critical to document everything as well as clearly defining how to measure success for both the business and the users. By building what is commonly referred to as an MVP, you can test your hypotheses, validate your assumption or pivot if necessary. Don’t try to be perfect in the beginning and be ok with being wrong as it will allow you to make necessary iterations early before you go too far down the wrong path.

The Design Process

When you are in the design process, you’ll want to create a prioritized list of potential features. Focus on first building the things that you know will have the biggest impact on delivering your product’s value proposition.  “Fall in love with the problem you are trying to solve as opposed to particular features or solutions you are building”. You’ll be more successful if you stay focused on the problem and are willing to iterate towards the developing features that will best solve it and avoiding those that don’t.  Marc also introduced the concept of time-boxing for certain design activities so that you don’t waste any unnecessary time or energy trying to perfect something before you test it.

When taking the lean approach there are a number of practices you can incorporate into building the best user experience for your product. For example, Marc discusses user personas and user journeys, red routes, information architecture, user flows, hand-drawn sketches, wireframes, and prototypes. These practices are all ways to gather and incorporate data garnered from real user interactions and testing. Each exercise also builds off of the other and makes the next step in the process easier. It is also easier to go back and improve and iterate on past versions of what you have done.

Lastly, he discussed design sprints which are a unique five-day process for validating ideas and solving big challenges through prototyping and testing ideas with customers.

Feedback is critical!

If you were able to attend the event we thank you and would love to get your feedback. 

Or if you didn’t make and you are interested in learning more about Lean Product Design please feel free to contact us for a free consultation to see if it makes sense for you. Contact Marc directly via email at marc@bytelion.com. 

Enterprise UX Gone Wrong

By Design, Leadership, OrganizationsNo Comments

There are many things that can go wrong when building a web-based platform or application, but the most tragic of offenses comes from a poor UX plan stemming from the very beginning of the development process. A great UX process, accompanied by a team of highly qualified individuals will make a world of difference, from your wallet to the face of the product. The following are symptoms of a poor UX process and how it impacts your product.

 

Your Bottomline Is Suffering

You may not be sinking, but you’re losing money. Perhaps you aren’t hitting your quarterly goals or are starting to see negative trends. It may be a surprise, but design can help solve this problem.

Strategy and Discovery

There is a good chance your business is heading downhill because of poor planning. As in a lot of things, business needs planning, not just financially, but with all that you do. The design is not an exception. The first step to a great User Experience (UX) is to review and understand your business requirements. You could potentially be focusing on one or more of the following business strategic priorities:

  • Reduce costs
  • Increase revenue
  • Increase new business
  • Increase existing business

Having the team and stakeholders on the same page as to what the goals of the company are can pave a clear path for the design and development team for the next steps. No more asking “why are we doing this?”. With business and user requirements determined and explained up front, everyone will know why each aspect of the product is the way it is and more importantly, how to better accomplish the goals of the product. Additionally, planning in advance allows for you and your team to be more knowledgeable and make informed decisions about your product resulting in higher user engagement.

 

Business Strategy is the foundation of the UX process, without this,
you can expect your product to come crashing down.

 

Late Deliveries and ‘Never-ending’ features

Your project is behind schedule, priorities change on a whim, features never seem to get pushed.

 

Defining Scope

Why is this happening? Simple: Your project scope is out of whack. Either you never defined the project scope with the team, or your scope is starting to go off the designated path, leading to unfinished, late work. Scope definition benefits the team and product in many ways. It allows everyone to be on the same page about what can be done in a specific time frame and how it will be done. It is best to know your user and business requirements before trying to define your project scope. Once you know your goals you can begin to prioritize the next steps based on the requirements set in place, Prioritizing can be, and in many cases is, the leading problem in most production. A lack of prioritization is largely caused by stakeholder disputes which in turn cause uncertainty among the team and ultimately leads to nothing ever getting completed in a timely fashion, if at all. Stakeholders will be able to see, with abundant transparency, the project timeline, and feature prioritization. This also saves the development team from stakeholders who want to start changing and adapting the project scope mid-project. Defining the scope allows you to build products that are useful for your users and meets their needs.

 

Your project scope should not be defined by opinions and ideas, but rather on the user and business needs and requirements.

 

Engagement is down

You’re losing users, they aren’t spending much time using the site or app, customer purchases are low, or you can’t get users to onboard. Users don’t seem to be catching on to your product, so what gives?

Structure and Ideation

Users like pretty, fun, unique things, but they also like what they know. They don’t want to think, guess, or wonder while they’re using your product. In order to successfully build a product that users will not only enjoy using but keep coming back to, you need to know what your users want out of your product. Engagement is 100% related to your business and user requirements. If you have not written out and made it clear what your purpose as a business is, as well as what your users need from your product, you cannot successfully build a product that is created for your users. Understanding what your customers need and want is key to providing a service or product that meets those needs.

 

For example, imagine a user has just ordered an item from your website and wants to know about your return policy, but can’t find any information regarding this on the purchase confirmation page, they will have to start searching the site to see if they can find the information they need. Not giving the user the information they need when and where they want it or expect it can lead to frustration and an overall bad experience. Users will have a better experience when they have to think less, and know more.

 

Your users are the core of your product. Understanding how they think and why they use your product will help you build the right structure.

 

Massive Project overhauls

You’ve had re-designs, feature recall, structure changes, the list goes on. You thought you got it right from the start, but things keep needing to be adapted, changed or removed altogether.

 

Skeleton and Prototyping Phase

Lots of changes and modifications to a site either prior to or shortly after launch can most usually be linked back to the failure to draw out, wireframe, and iterate on the initial design layout. This step is crucial to the future of the product as it allows you to identify holes in the plan, points of user error, and feature issues. By foregoing this creative and iterative process you go straight from a features list to finalized design without much thought in-between. Iteration is crucial to the success of a design, but not less or more important than asking the right questions and listening to your users. A major player in project overhauls is a team’s inability to read user data correctly, interpreting what the data says to meet their needs or opinions. Cross-vertical collaboration needs to occur when discussing user input to make sure discussions involving technical capabilities, financial constraints, and design aspects are considered when solving issues or implementing new features. A product’s ease-of-use is directly related to your team’s ability to collaborate, understand user data, and adapt and iterate when given new information.

 

Iterative design produces the best result. Your first is never your best.

 

Brand Experience isn’t right

The colors are off, the logo is confusing, the imagery is tacky, it looks dated. Maybe your site looks nice but isn’t a good representation of your brand. Whatever it is, you know it’s got to change.

Surface and design

Your product’s look and feel isn’t matching the look and feel you had in mind or isn’t looking good at all. This is all due to the UI (User Interface) design. The UI is the ‘surface’ of a product and conveys to users the meaning, use, and connotation associated with the business and product itself. The UI covers everything from colors and fonts to animation and transitions. A good UI will take into account who your users are, how they should feel using your product,  and your business’ brand. A common occurrence that can cause the UI to not have the right feel is when the design does not line up with the target market. This can happen for a number of reasons, possibly because you do not know your target market, you are making assumptions about your target market, your team has not spent the time to get to know your target market, or most commonly someone on the team, typically the product manager or a stakeholder views the product as their baby and does not want to listen to any views other than their own even when those views are backed up by data. You can help to avoid these types of mistakes by clearly laying out who this is for and why the choices being made make sense for that groups of persons. The overall feeling about the brand/product should be good or your Brand Experience is NOT good.

 

You think you’re ‘Done’

It doesn’t matter what your business delivers, you are never Done. Your user’s wants, needs, and goals are ever-changing and you need to adjust to make sure you continue to bring a useful, functional, pleasing product.

 

Testing and Evaluation

Design is a key aspect of updates and adjustments to your product since using a UX process can help you determine the best options for your business moving forward. Whether it’s interviewing users or doing A/B testing, the most impactful tool you can utilize is testing. Testing your product through various means will give your team insights into the way your users’ think and how they feel when interacting with your product. Through the evaluation process, unknowns are discovered that allow your company to pivot and adapt quickly and more purposefully, providing greater meaning to your product. An issue you can and most likely will run into through testing and attempting to make changes to the product will be a stakeholder coming forward and disagreeing with decisions because they feel the product is better one way than another purely based off their own opinion. This is referred to as Pride of Authorship. They believe since they started the project that they should have it the way they want it, which you could argue is correct and fair, however, this thinking can damage the product, user engagement, leading to a poor team environment and a hurting the bottom line. Keeping stakeholders aware of the core users’ needs and goals and how new feedback benefits the company and product can allow them to see their version may not be the best holistic option.  

“Usability testing shows you if something is usable. Beta testing shows you if people will actually use it.”
Rachel Decker

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!

wireframes_keep_current_v2

 

Never, Ever Invest in Specs

By Design, Innovators, Leadership, Software Lifecycle, StartupNo Comments

So, here is a scenario… you want to develop a new software product, but you aren’t sure who to hire or how much it will cost. What should you do?

Don’t Do This


Before I tell you what you should do, lets talk about what you should not do… pay a development team to break your application down into user stories or worse yet, a requirements document.  The amount of waste that you will spend on this is enormous with little value for a potentially large investment.

Common myth:  Once you have the specification, you can hand it to other developers who can create estimates for your application, right?  Wrong.  Developers cannot possibly pick up a cold specification and accurately estimate the project.  They still need to walk through the application, visualize it and ask questions about the features.  Even if a developer understands the application after investing an enormous amount of time, they still might not be able to accurately estimate it.   Why?  Read this. https://blog.codinghorror.com/how-good-an-estimator-are-you/

Specs are Boring and Painful to Read

specs_vs_ui_mockup

If you aren’t going to spend money on specs, what should you do?

Steps To Preparing Yourself


Step 1.  Become a hermit 

Roll up your sleeves and invest in learning a simple mockup tool like, https://moqups.com. Lock yourself in during a weekend and mock out what you want your application to do.  In a weekend, a founder can reasonably figure out how to build the critical 5 or 6 pages of their application.  Then, they can provide this to a development team to get their concept across and produce a well engineered prototype.

Step 2 . Pick up the check… the lunch check that is.

Use the money you saved by not paying someone to do your specification and take a few people out to lunch that are friendly to you AND understand your market very well.  Use this time to shore up your thoughts and produce another version of your application based on what you have learned.

Step 3. Deliver a working Prototype

Select your team using this simple outsource process.   Not sure how do this? Check out our “10 Minute Guide To Hiring Outsourced Team

Summary


At the end of the day, you are accountable for every dime you spend.  You are the only one.  You can blame a team delivering poorly after a few sprints, but that it is.  As an entrepreneur, you are responsible for selecting people to work for you and firing them.  If you blame your development team, then you are weak sauce and not ready to run a startup.  Be prepared to fire.